On Fri, May 10, 2013 at 12:43 PM, Kishanthan Thangarajah < [email protected]> wrote:
> > > > On Fri, May 10, 2013 at 12:05 PM, Supun Malinga <[email protected]> wrote: > >> 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?. >> > > When calling the relevant deployers to deploy/undeploy, they expect the > individual artifacts to be available in the file system. This cannot > be achieved if we don't extract the CApp. > I see.. > >>>> - >>>> - 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. >> > > There is another thread for this : "Tracking deployment status of > artifacts in CApp". Please refer that for more info. > thanks, will have a look. > > > Thanks, > Kishanthan. > > >> >> 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 >> >> > > > -- > *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
