Hi Kishanthan, On Fri, May 10, 2013 at 11:26 AM, Kishanthan Thangarajah < [email protected]> wrote:
> > > > On Fri, May 10, 2013 at 9:09 AM, Ananda Manoj Kumara <[email protected]>wrote: > >> Hi Supun, >> >> Yes now we can, the design is as Kishanthan mentioned on previously >> >> During CApp deployment, >> >> - Artifacts inside CApp get extracted to temp location >> >> Actually I was in the idea that now we don't extract the CApp. Why we didn't go with that model?. > >> - >> - CApp deployer then call the relevant deployers and deploy the >> artifacts >> >> This is fine. > >> - >> - Finally when the CApp get deployed all its artifacts are up and >> running >> >> We can easily detect the deployment status from the log. >> > > Yes, and you also can query the CApp Admin service (ApplicationAdmin) to > get the deployment status of artifacts in a CApp as-well. > How does the ApplicationAdmin keeps track of the deployment status of each artifact?. This was my initial question. thanks, > > >> >> >> Thanks, >> Manoj >> >> >> Best Regards.. >> >> >> Manoj Kumara >> Software Engineer >> WSO2, Inc.; http://wso2.com >> >> Twitter: http://twitter.com/ManKuma >> Mobile: +94713448188 >> >> >> On Fri, May 10, 2013 at 8:49 AM, Supun Malinga <[email protected]> wrote: >> >>> Hi guys, >>> >>> So now do we have the necessary hooks to detect the deployment status of >>> the capp?. What's the design? >>> Sorry if I have missed something. >>> >>> Thanks, >>> Supun >>> >>> Sent from my phone >>> On Apr 20, 2013 9:51 PM, "Afkham Azeez" <[email protected]> wrote: >>> >>>> Yes, we should not have unnecessary options >>>> >>>> -- >>>> Afkham Azeez >>>> Sent from my phone >>>> On Apr 20, 2013 8:53 PM, "Pradeep Fernando" <[email protected]> wrote: >>>> >>>>> >>>>> >>>>> >>>>> On Sat, Apr 20, 2013 at 8:27 PM, Kishanthan Thangarajah < >>>>> [email protected]> wrote: >>>>> >>>>>> Hi All, >>>>>> >>>>>> I agree with "CApp should be considered as an atomic deployment unit". >>>>>> >>>>>> But based on the above feedback, How about having two options as >>>>>> below? >>>>>> >>>>>> 1. Atomic deployment, i.e. either deploy all artifacts or none (this >>>>>> will be the default option) >>>>>> 2. Skip failing and deploy the rest. >>>>>> >>>>>> The choice we leave it to the user. However, the second option is >>>>>> useful only in a dev environment. The option can be changed via the root >>>>>> artifacts.xml file of CApp. >>>>>> >>>>> >>>>> if possible we should avoid giving options to users. >>>>> >>>>> >>>>> >>>>>> >>>>>> Thanks, >>>>>> Kishanthan. >>>>>> >>>>>> >>>>>> On Fri, Apr 19, 2013 at 8:47 PM, Harshana Martin >>>>>> <[email protected]>wrote: >>>>>> >>>>>>> Hi Pradeep, >>>>>>> >>>>>>> >>>>>>> On Friday, April 19, 2013, Pradeep Fernando wrote: >>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> CApp is the deployment unit. Either it should deploy successfully >>>>>>>> or not at all. >>>>>>>> >>>>>>> >>>>>>> It's just not a deployment unit but a composite deployment unit >>>>>>> something similar to EAR. Thus the behavior of CAR should be analogues >>>>>>> to >>>>>>> behavior of EAR. >>>>>>> >>>>>>> Thanks and Regards, >>>>>>> Harshana >>>>>>> >>>>>>>> --Pradeep >>>>>>>> >>>>>>>> >>>>>>>> On Fri, Apr 19, 2013 at 4:54 PM, Harshana Martin <[email protected] >>>>>>>> > wrote: >>>>>>>> >>>>>>>> Hi Azeez, >>>>>>>> >>>>>>>> >>>>>>>> On Fri, Apr 19, 2013 at 4:37 PM, Afkham Azeez <[email protected]>wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Fri, Apr 19, 2013 at 4:04 PM, Kishanthan Thangarajah < >>>>>>>> [email protected]> wrote: >>>>>>>> >>>>>>>> The following question came up during the review today. >>>>>>>> >>>>>>>> Say that my CApp has 5 artifacts and during the deployment >>>>>>>> of third artifact, an error occurred. Currently when this happens, the >>>>>>>> rest >>>>>>>> of the artifacts deployment is skipped and the CApp will be treated as >>>>>>>> faulty. But the issue is, the first and second artifact got >>>>>>>> deployed successfully and they are ready for operation too. >>>>>>>> >>>>>>>> The question is should we >>>>>>>> also rollback/undeploy these successful artifacts, if an error occurs? >>>>>>>> >>>>>>>> >>>>>>>> Yes, that what means by "a CApp is treated as an atomic deployment >>>>>>>> unit" >>>>>>>> >>>>>>>> >>>>>>>> Well.. We say CAR is the composite unit consists of many sub >>>>>>>> components, C-App artifacts. >>>>>>>> >>>>>>>> There could be dependencies among these C-App artifacts but does it >>>>>>>> matter at the deployment time whether the dependencies are already >>>>>>>> available? >>>>>>>> >>>>>>>> If we are going to consider that at the deployment time, it could >>>>>>>> cause lot more issues in a distributed environment because we cannot >>>>>>>> assume >>>>>>>> about the timing of these artifact deployment. >>>>>>>> >>>>>>>> Thanks and Regards, >>>>>>>> Harshana >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Kishanthan >>>>>>>> >>>>>>>> >>>>>>>> On Fri, Apr 5, 2013 at 12:58 PM, Amila Suriarachchi <[email protected] >>>>>>>> > wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Fri, Apr 5, 2013 at 12:55 PM, Kishanthan Thangarajah < >>>>>>>> [email protected]> wrote: >>>>>>>> >>>>>>>> We could get this work for ESB artifacts :). >>>>>>>> >>>>>>>> This is the flow of CApp deployment. >>>>>>>> >>>>>>>> CApp gets deployed --> CApp artifacts extracted it to temp location >>>>>>>> --> CApp deployer calls the relevant deployers of artifacts to deploy >>>>>>>> >>>>>>>> The problem was, ESB (Synapse) deployers gets registered with the >>>>>>>> axisConfiguration after some time. This is because Synapse >>>>>>>> configuration >>>>>>>> initialization happens after the axisConfig gets initialized. >>>>>>>> >>>>>>>> Since CApp deployer initialization also happens during the >>>>>>>> axisconfig initialization, when it tries to call the relevant synapse >>>>>>>> deployers, it will not find them as none of them are registered with >>>>>>>> axisConfig at that time. >>>>>>>> >>>>>>>> The solution was to delay the CApp Deployer initialization after >>>>>>>> Synapse config is initialized and ready. We have moved this part to >>>>>>>> StartUpFinalizer component. This will not affect any other servers >>>>>>>> (e.g. >>>>>>>> AS), since only the CappDeplyer initialization time is been changed. >>>>>>>> >>>>>>>> I will add these fixes to trunk. Manoj will continue to work on >>>>>>>> other artifacts types. >>>>>>>> >>>>>>>> >>>>>>>> Cool :). Then we add to getting status of caps. >>>>>>>> >>>>>>>> With this model now we can dep-synch caps. >>>>>>>> >>>>>>>> thanks, >>>>>>>> Amila. >>>>>>>> >>>>>>>> *Pradeep Fernando* >>>>>>>> >>>>>>>> Member, Management Committee - Platform & Cloud Technologies >>>>>>>> Senior Software Engineer;WSO2 Inc.; http://wso2.com >>>>>>>> >>>>>>>> blog: http://pradeepfernando.blogspot.com >>>>>>>> m: +94776603662 >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> >>>>>>> Harshana Martin >>>>>>> Senior Software Engineer >>>>>>> Member, Management Committee - Development Technologies >>>>>>> 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 >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> *Kishanthan Thangarajah* >>>>>> Software Engineer, >>>>>> Development Technologies Team, >>>>>> WSO2, Inc. >>>>>> lean.enterprise.middleware >>>>>> >>>>>> Mobile - +94773426635 >>>>>> Blog - *http://kishanthan.wordpress.com* >>>>>> Twitter - *http://twitter.com/kishanthan* >>>>>> >>>>>> _______________________________________________ >>>>>> Architecture mailing list >>>>>> [email protected] >>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> *Pradeep Fernando* >>>>> Member, Management Committee - Platform & Cloud Technologies >>>>> Senior Software Engineer;WSO2 Inc.; http://wso2.com >>>>> >>>>> blog: http://pradeepfernando.blogspot.com >>>>> m: +94776603662 >>>>> >>>>> _______________________________________________ >>>>> 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 >>>> >>>> >>> _______________________________________________ >>> 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 >> >> > > > -- > *Kishanthan Thangarajah* > Software Engineer, > Development Technologies Team, > WSO2, Inc. > lean.enterprise.middleware > > Mobile - +94773426635 > Blog - *http://kishanthan.wordpress.com* > Twitter - *http://twitter.com/kishanthan* > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Supun Malinga, Software Engineer, WSO2 Inc. http://wso2.com http://wso2.org email - [email protected] <[email protected]> mobile - 071 56 91 321
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
