I also prefer not to let user edit artifacts in a car via the admin console .. or at least keep it that way for start.
Lets see what others think. --Srinath On Tue, Aug 6, 2013 at 1:47 PM, Harshana Martin <[email protected]> wrote: > Hi Srinath, > > > On Tuesday, August 6, 2013, Srinath Perera wrote: > >> Hi Ayashkantha, >> >> Yes, you are right. >> >> Harshna, IMO these are the requirements >> >> 1) When someone deploy a car, we directly deploy artifacts in the carbon >> by calling deployers without copying them to file system >> > > Correct! > >> 2) Either we should not let users edit artifacts come via car, or >> update the underline car file when the update is done. >> > > I'm strongly -1 for involving Carbon server for manipulating CAR files in > the runtime since IMO server is trying to do something out side of its > scope and it could lead us to unnecessary complexities in terms of > persistence, application governance,etc. > > If a car file is required o be updated, it is the task of the > developer/Dev ops person to package it using Dev Studio or Maven and > redeploy the new CAR file. > > We have already decided in a previous meeting we do not let users to > manipulate artifacts deployed via CAR. For example delete should be > disabled for artifacts deployed via CAR. > > These UI Level chanes has to be done for Carbon 4,2.0. > >> >> To do this, each artifact has to keep track where it came from (which >> car). >> >> How much of these do we have? I will schedule an review to discuss this. >> > > We already have admin services to do this. Application Admin is performing > it. > > This admin service is used to populate the C-App dashboard. So there is > nothing to implement in terms of tracking the C-App artifacts source. > > Only missing features at this point is the ability to limit/disable the Ui > for certain operations on the artifacts deployed via C-Apps. > > Thanks and Regards, > Harshana > >> >> --Srinath >> >> >> On Tue, Aug 6, 2013 at 11:52 AM, Ayashkantha Ramasinghe < >> [email protected]> wrote: >> >> Hi All, >> >> The problem we have is, even though we can undeploy the artifacts >> deployed by a car using UI, if that is not being removed from the car file, >> the artifact is being redeployed while restarting the server. So, what we >> need to do is to check where the artifact came from and remove it from >> there too. if the artifact is a manually deployed, then we need to remove >> it from the file system, if the artifact is automatically deployed, then we >> need to remove it from car file. >> >> This problem should be there in all products which supports cApp >> deployment(I checked in ESB too) and this is fundamentally wrong, because >> repacking the car manually is not the solution. The artifact being deleted >> by the user from UI and the server being restarted cause to bring back the >> changes, I guess, that is not a good design. >> >> WDYT???? >> >> >> >> Thank you, >> -Ayashkantha Ramasinghe >> -Software Engineer >> -Tel: +94 777 487 669 >> >> >> On Mon, Aug 5, 2013 at 9:13 AM, Anjana Fernando <[email protected]> wrote: >> >> Hi Harshana, >> >> That is not exactly what I asked for. The metadata, we need it to know >> where the target artifact came from, either from a specific CAR file or >> from the deployment directory of its own. We need this information from >> some API, for example, if a data service is edited, where I should save it >> to (actually in BAM toolboxes we wont have that requirement). And also, >> re-packing is basically the action the application has to do when someone >> edits something as I mentioned now, and merging it back to the CAR. And >> also, how the delete action is to be implemented. >> >> Basically, can you show me a place this functionality is already properly >> implemented, so we can use that as a reference. >> >> Cheers, >> Anjana. >> >> >> On Mon, Aug 5, 2013 at 8:48 AM, Harshana Martin <[email protected]>wrote: >> >> Hi Anjana, >> >> >> On Sun, Aug 4, 2013 at 7:27 PM, Anjana Fernando <[email protected]> wrote: >> >> Hi Harshana, >> >> On Fri, Aug 2, 2013 at 10:40 PM, Harshana Martin <[email protected]>wrote: >> >> >> OK, yeah, but the thing is, is this already done by others? .. as in .. >> we have to keep this metadata somewhere to say where it came from, to use >> it when we are editing/updating an artifact, and there needs to be some >> utilities to re-pack the car file and all. >> >> >> Metadata related CAR file and its artifacts are already being maintained >> in the Registry. >> >> >> I see, can you please point to the APIs that can be used to get these >> information and to re-pack the CAR files and so on. And, is there any other >> place we can use as a reference? .. >> >> >> Matadata management in the registry is done by the C-App deployer. As a >> C-App BAM artifact deployer developer you do not need to change anything in >> there. >> >> Re-Packaging of CAR file has to be done by the Person who developed the >> CAR file means if you are the person who want to deploy the Toolbo >> >> > > -- > > Harshana Martin > Associate Technical Lead > WSO2 Inc. : http://wso2.com > > Mobile: +94 775 998 115 > Profile: https://www.google.com/profiles/harshana05 > Blog: http://harshana05.blogspot.com > Twitter: http://twitter.com/harshana05 > > > -- ============================ Srinath Perera, Ph.D. Director, Research, WSO2 Inc. Visiting Faculty, University of Moratuwa Member, Apache Software Foundation Research Scientist, Lanka Software Foundation Blog: http://srinathsview.blogspot.com/ Photos: http://www.flickr.com/photos/hemapani/ Phone: 0772360902
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
