Just chatted with Sameera and Azeez as well, we have decided before to not support edits/ delete for artifacts deployed via a CApp.
--Srinath On Tue, Aug 6, 2013 at 2:06 PM, Anjana Fernando <[email protected]> wrote: > Hi, > > The only issue is, the user experience is not consistent for the user, > when some artifacts are deployed from the CAR and when otherwise directly > deployed from a wizard or some upload method from the web console. Where > suddenly the edit/delete functionality is not available for some of the > artifacts. Anyways, if that is the policy we are going to stick to, that is > also fine. So now we just need a clear API to get these information into > see, if the deployed artifact we have now came from a CAR or directly > deployed, so we can change the other functionality accordingly. > > Cheers, > Anjana. > > > On Tue, Aug 6, 2013 at 1:54 PM, Srinath Perera <[email protected]> wrote: > >> 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 >> >> > > > -- > *Anjana Fernando* > Technical Lead > WSO2 Inc. | http://wso2.com > lean . enterprise . middleware > -- ============================ 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
