Hi Thilini, With synchronous CApp deployment we consider CApp as a atomic unit. If all artifacts get deployed without an issue we consider that CApp as successful. If not we consider it as a faulty CApp.
If the CApp is faulty that means either one of the artifacts get failed we undeploy any previously deployed artifacts by that CApp and consider that CApp as a faulty CApp. So none of the artifacts from that CApp will be deployed. This is not configurable on carbon.xml as this is the expected behavior. Thanks, Manoj Best Regards.. Manoj Kumara Software Engineer WSO2, Inc.; http://wso2.com Twitter: http://twitter.com/ManKuma Mobile: +94713448188 On Mon, Jan 27, 2014 at 9:01 AM, Thilini Ishaka <[email protected]> wrote: > 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 > >
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
