Hi,

On the discussion held on today we decided to go ahead with the new CApp
atomic implementation.

The CApp extract location is changed to new location at
CARBON_HOME/repository/carbonapps/work directory.

Thanks,


Best Regards..


Manoj Kumara
Software Engineer
WSO2, Inc.; http://wso2.com

Twitter:  http://twitter.com/ManKuma
Mobile: +94713448188


On Tue, Aug 13, 2013 at 11:31 AM, Sagara Gunathunga <[email protected]> wrote:

>
>
>
> On Tue, Aug 13, 2013 at 11:13 AM, Manoj Kumara <[email protected]> wrote:
>
>> Hi,
>>
>> During Jira issues raised relevant to 4.2.0 QA cycle we (myself, sameera,
>> kasung, ajith, shameera) observed that there are some design issues on new
>> CApp atomic deployment and discussed the limitations and problems that it
>> may produce. Since this may affect the all products related to this release
>> its better to decide whether we move on with the new implementation or we
>> keep hold this till we sort out the issues relevant to new implementation.
>>
>> Here I list some issues we found during the process,
>>
>>    - Artifacts get cleaned up during housekeeping process
>>       - During deployment CApp get extracted to CARBON_HOME/tmp
>>       directory. These extracted artifacts will be needed during service and
>>       application invocations so they need to be available during runtime. 
>> But
>>       since this is extracted inside tmp directory during housekeeping 
>> process
>>       this extracted directory may get cleaned.
>>       - As alternative we could use another directory instead of tmp.
>>       But this also need to be cleaned since every time server start-up 
>> available
>>       CApps will be extracted and this folder get filled with temp extracted
>>       CApps.
>>    -  Probability of SVN conflicts during cluster set-up which has
>>    multiple manager nodes
>>    - In new design CApps get depsynced through cluster. So once it get
>>       extracted on a node it will have a separate service.xml file. Once 
>> multiple
>>       managers try to change service properties this may cause svn 
>> conflicts. (QA
>>       team is testing the possibility of this)
>>    - Tomcat support only one extract directory
>>       - Discussion held last week with (Sameera, Azeez, Srinath, Sagara)
>>       it was found that tomcat only support one extract directory and all 
>> webapps
>>       (.war files) need to be placed on repository/webapps directory. The
>>       conclusion of this discussion was to, not support .war files through
>>       webapps. This also a limitation in new design.
>>
>> The problem here is Tomcat support web application (.WAR files)
> deployment from multiple directories but .war file unpacking is supported
> only for one directory, for other directories deployment is supported
> without unpacking. This is one of the Tomcat's fundamental design concept
> and it's very unlike to change or modify this behavior. If a web app author
> want to write something to file system then unpacking is compulsory
> otherwise this is not an issue. The conclusion of above discussion was
> support web application deployment through CApps without unpacking and in
> case .WAR deployment fails users has to deploy it separately out of the
> CApp as a workaround.
>
> Thanks !
>
>
>
>>
>>
>>
>> Appreciate your suggestions on this,
>>
>>
>> Thanks,
>> Best Regards..
>>
>>
>> Manoj Kumara
>> Software Engineer
>> WSO2, Inc.; http://wso2.com
>>
>> Twitter:  http://twitter.com/ManKuma
>> Mobile: +94713448188
>>
>
>
>
> --
> Sagara Gunathunga
>
> Senior Technical Lead; WSO2, Inc.;  http://wso2.com
> V.P Apache Web Services;    http://ws.apache.org/
> Linkedin; http://www.linkedin.com/in/ssagara
> Blog ;  http://ssagara.blogspot.com
>
>
_______________________________________________
Architecture mailing list
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Reply via email to