The relevant JIRA - https://wso2.org/jira/browse/CARBON-13078
On Mon, Nov 5, 2012 at 6:51 PM, Amila Suriarachchi <[email protected]> wrote: > hi Srinath, > > On Mon, Jul 9, 2012 at 3:21 PM, Srinath Perera <[email protected]> wrote: > >> Hi Isuru, >> >> In a review we talked about possibility of not deploying artifacts inside >> the CApp back to repo, but deploying them by extracting them into a temp >> directory and invoking the respective deployers directly, without using the >> hot deployment. IMHO, that is the clean way to handle CApp deployments. >> >> I think we agreed for the above. >> >> Can we solve this problem by doing the above? >> > > We (Kasun, KasunG and me) had a chat on this and we will try to implement > an SynchronusCarAppDeployer service (and Admin service) to handle this. The > idea of this service is to deploy all the artefacts before Admin service > sends the response. > > In implementation wise, it will extract the CApp file to a temp location > and call each and every deployer manually. Since all deployers are Axis2 > Deployers this method should work for all those applications. > > This method may not work for things like custom mediators, but this way we > can address this problem for most of the common cases. > > thanks, > Amila. > >> >> --Srinath >> >> On Fri, Jul 6, 2012 at 6:05 PM, Isuru Suriarachchi <[email protected]>wrote: >> >>> Hi all, >>> >>> I'm trying to fix [1]. Here's the root cause for this issue.. >>> >>> Imagine a Carbon cluster with 2 nodes where the svn based deployment >>> synchronizer (DS) is configured. When a C-App is deployed to node1, it is >>> extracted and individual artifacts are copied into respective hot >>> directories. When the DS runs for the first time, it copies the C-App into >>> node2 and it will be deployed there. When the DS runs again in node1, it >>> will try to copy the individual artifacts to node2. But node2 already has >>> those artifacts as the C-App id already deployed in node2. Therefore an svn >>> conflict occurs. >>> >>> To resolve this issue, there are two possible options.. >>> >>> 1. Keeping all artifacts coming from C-Apps out of the repository >>> (repository/deployment/server) >>> 2. Keeping the original C-App out of the repository >>> >>> Initially I tried option 1 above and programetically called the relevant >>> deployers for individual artifacts. But this creates lot of problems with >>> some artifacts (Ex: ESB stuff). Therefore, I'm trying to solve the initial >>> problem using option 2 above. >>> >>> I've taken the carbonapps directory out of repository/deployment/server >>> directory and kept it as repository/carbonapps (we can change this if >>> needed). Still the carbonapps directory has hot deployment capabilities. >>> But it won't be synchronized by the DS. So when a C-App is deployed into >>> node 1, it will be extracted and only the individual artifacts will be >>> copied into the repository. When the DS runs, all needed artifacts will be >>> synced to node 2. Therefore, functionality wise, there won't be any issues >>> on node 2. >>> >>> But if someone logs into the management console of node 2 and go to the >>> C-App list, nothing will be listed. Is this something we have to fix? >>> Because anyway in a RW/RO cluster, user can't use the management console of >>> the slave node. >>> >>> WDYT?? >>> >>> Thanks, >>> ~Isuru >>> >>> [1] https://wso2.org/jira/browse/CARBON-13598 >>> >>> -- >>> Isuru Suriarachchi >>> Senior Technical Lead >>> WSO2 Inc. http://wso2.com >>> email : [email protected] >>> blog : http://isurues.wordpress.com/ >>> >>> lean . enterprise . middleware >>> >>> >>> _______________________________________________ >>> Dev mailing list >>> [email protected] >>> http://wso2.org/cgi-bin/mailman/listinfo/dev >>> >>> >> >> >> -- >> ============================ >> Srinath Perera, Ph.D. >> http://www.cs.indiana.edu/~hperera/ >> http://srinathsview.blogspot.com/ >> >> _______________________________________________ >> Dev mailing list >> [email protected] >> http://wso2.org/cgi-bin/mailman/listinfo/dev >> >> > > > -- > *Amila Suriarachchi* > > Software Architect > WSO2 Inc. ; http://wso2.com > lean . enterprise . middleware > > phone : +94 71 3082805 > > > _______________________________________________ > Dev mailing list > [email protected] > http://wso2.org/cgi-bin/mailman/listinfo/dev > > -- *Kasun Gajasinghe* Software Engineer; Development Technologies Team, WSO2 Inc.; http://wso2.com , *email: **kasung AT spamfree wso2.com** cell: **+94 (77) 678-0813* *linked-in: *http://lk.linkedin.com/in/gajasinghe* * *blog: **http://blog.kasunbg.org* <http://blog.kasunbg.org>* twitter: **http://twitter.com/kasunbg* <http://twitter.com/kasunbg>* *
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
