Hi Kishanthan & all, What needs to happen when there's a faulty artifact inside a capp, whether to skip failing and deploy rest or deploy none? Is that configurable via artifact.xml now? Please clarify.
Thanks Thilini 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. > > 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 <http://kishanthan.wordpress.com>* > Twitter - *http://twitter.com/kishanthan <http://twitter.com/kishanthan>* > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Thilini Ishaka Senior Software Engineer Phone: +94 11 214 5345 WSO2 Inc. http://wso2.com blog: thiliniishaka.blogspot.com linkedin: http://lk.linkedin.com/in/thiliniishaka twitter: https://twitter.com/#!/ThiliniIsh
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
