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 Toolbox via >> C-App, when you have updated the Toolboc, you need to recreate the CAR with >> updated Toolbox and redeploy the CAR file. >> >> For that the C-App developer can use either Dev Studio or Maven. >> >> To support BAM Toobox via C-Apps, you need to update the C-App deployer >> component to identify the Toolbox artifact using its artifact type and then >> call the BAM Toolbox deplopyer. >> >> Kishanthan, Please add if I missed something. >> >> Thanks and Regards, >> Harshana >> >>> >>> Cheers, >>> Anjana. >>> >>> >>>> >>>> Thanks and Regards, >>>> Harshana >>>> >>>>> >>>>> Cheers, >>>>> Anjana. >>>>> >>>>> >>>>>> >>>>>> --Srinath >>>>>> >>>>>> >>>>>> On Fri, Aug 2, 2013 at 2:21 PM, Anjana Fernando <[email protected]>wrote: >>>>>> >>>>>>> Hi Srinath, >>>>>>> >>>>>>> On Fri, Aug 2, 2013 at 2:00 PM, Srinath Perera <[email protected]>wrote: >>>>>>> >>>>>>>> We should go with the #2 as Harshana mentioned. >>>>>>>> >>>>>>>> We want to deploy car without exploding to deployment directories, >>>>>>>> otherwise a) delete is hard b) when dep sync get confused. >>>>>>>> >>>>>>> >>>>>>> Well . what about my concerns I mentioned earlier .. there will be >>>>>>> scenarios we need to have the deployment artifacts in the file system, >>>>>>> like >>>>>>> editing/saving it, like how are we going to handle that? .. are we >>>>>>> suppose >>>>>>> to put those changes back into the car file? .. and where we get >>>>>>> problems >>>>>>> like if this artifact came from an original car file or not. >>>>>>> >>>>>>> Cheers, >>>>>>> Anjana. >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> --Srinath >>>>>>>> >>>>>>>> >>>>>>>> On Fri, Aug 2, 2013 at 1:51 PM, Anjana Fernando <[email protected]>wrote: >>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> On Fri, Aug 2, 2013 at 1:34 PM, Harshana Martin <[email protected] >>>>>>>>> > wrote: >>>>>>>>> >>>>>>>>>> Hi Sinthuja, >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Friday, August 2, 2013, Sinthuja Ragendran wrote: >>>>>>>>>> >>>>>>>>>>> Hi Ayashkantha, >>>>>>>>>>> >>>>>>>>>>> You should use the first approach IMO. We don't need duplicate >>>>>>>>>>> the code for deploying the toolboxes. It'll become unmanageable and >>>>>>>>>>> it >>>>>>>>>>> won't be consistent also. >>>>>>>>>>> >>>>>>>>>>> Generally we follow the first method, as cApp will copy the >>>>>>>>>>> artifacts in the respective servers' deployment directory, >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> From Carbon 4.2.0 onward this is going to change. We will no >>>>>>>>>> longer be doing async deployments. >>>>>>>>>> >>>>>>>>> >>>>>>>>> What does that actually mean? .. the CAR deployment itself is >>>>>>>>> async right? .. and also, what about the scenarios where we expect the >>>>>>>>> actual artifact to be in the deployment directory, for example, data >>>>>>>>> services, proxy services and all, because the user will be editing >>>>>>>>> those >>>>>>>>> and deploying again, and those changes will reflect in their >>>>>>>>> deployment >>>>>>>>> directories. >>>>>>>>> >>>>>>>>> Cheers, >>>>>>>>> Anjana. >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Kishanthan will be able to provide more info on these changes. >>>>>>>>>> >>>>>>>>>> Thanks and Regards, >>>>>>>>>> Harshana >>>>>>>>>> >>>>>>>>>>> and the specific deployer will handle the deployment logic for >>>>>>>>>>> that artefact. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Sinthuja. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Fri, Aug 2, 2013 at 1:11 PM, Ayashkantha Ramasinghe < >>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>> >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> The "BAM car file deployer" is created to deploy toolboxes in >>>>>>>>>>>> the server as a cApp. I have two approaches, >>>>>>>>>>>> >>>>>>>>>>>> 1. to copy the toolbox to bam-toolbox directly and let the >>>>>>>>>>>> toolbox deployer run automatically and deploy the toolbox. >>>>>>>>>>>> 2. to deploy the toolbox using the code while deploying cApp >>>>>>>>>>>> without copying the toolbox to bam-toolbox directory directly. >>>>>>>>>>>> >>>>>>>>>>>> In 1st approach, we can go and manually see the toolbox >>>>>>>>>>>> deployed inside the directory, bam-toolbox. But, in the 2nd >>>>>>>>>>>> approach, we >>>>>>>>>>>> can't see or undeploy it manually, only cApp undeployment does the >>>>>>>>>>>> undeployment of the toolbox. >>>>>>>>>>>> >>>>>>>>>>>> I am also thinking that the 1st approach is good, but, for now, >>>>>>>>>>>> the deployer is created based on the 2nd approach. >>>>>>>>>>>> >>>>>>>>>>>> WDYT??? >>>>>>>>>>>> >>>>>>>>>>>> Thank you >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> Ayashkantha Ramasinghe >>>>>>>>>>>> Software Engineer >>>>>>>>>>>> >>>>>>>>>>>> Tel: +94 777 487 669 >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> *Sinthuja Rajendran* >>>>>>>>>>> Software Engineer <http://wso2.com/> >>>>>>>>>>> WSO2, Inc.:http://wso2.com >>>>>>>>>>> >>>>>>>>>>> Blog: http://sinthu-rajan.blogspot.com/ >>>>>>>>>>> Mobile: +94774273955 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> >>>>>>>>>> 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 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> 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 >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Architecture mailing list >>>>>>>>> [email protected] >>>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> ============================ >>>>>>>> Srinath Perera, Ph.D. >>>>>>>> http://people.apache.org/~hemapani/ >>>>>>>> http://srinathsview.blogspot.com/ >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> 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 >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Architecture mailing list >>>>>>> [email protected] >>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> ============================ >>>>>> 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 >>>>> >>>>> _______________________________________________ >>>>> Architecture mailing list >>>>> [email protected] >>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>> >>>>> >>>> >>>> >>>> -- >>>> >>>> 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 >>>> >>>> >>>> _______________________________________________ >>>> 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 >>> >>> _______________________________________________ >>> Architecture mailing list >>> [email protected] >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> >> >> -- >> >> 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 >> >> >> _______________________________________________ >> 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 > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > >
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
