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 - CApp deployer then call the relevant deployers and deploy the artifacts - Finally when the CApp get deployed all its artifacts are up and running We can easily detect the deployment status from the log. 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
