On Sat, Jul 7, 2012 at 11:01 AM, Kasun Gajasinghe <kas...@wso2.com> wrote:
> Hi Isuru, > > I'd like to add a third option to the list for consideration. :) > > How about doing the synchronization between cluster nodes AFTER the > C-App's extracted artifacts are deployed? > This is kind of not possible with the current implementation. That is because, C-App doesn't know when the individual artifacts will get deployed. It just copies the artifacts into hot directories. And also the synchronization will be called for each and every deployment cycle, it doesn't know whether there's a C-App to be deployed.. Thanks, ~Isuru > I'm not sure whether it's possible to do with the current architecture, > but if it is, then I think things will be easier. > But with this option, there could be issues in node 2. That's because node > 2 will also try to deploy the C-App as well in addition to its artifacts! > Hope that can be fixed! > > WDYT? > > Thanks, > --KasunG > > 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. >>>> >>> >>> I see a possible issue with option2. >>> >>> Currently it is possible to deploy 3rd party dependencies to Carbon >>> Servers using JavaLibraryArtifact C-App Artifact type and Carbon Server >>> extensions such as Custom Mediators, Registry Handlers, filters, etc via >>> C-Apps. When the C-App is deployed in a server, those artifacts gets >>> deployed in to the repository/components/dropins location but not the >>> repository. >>> >>> >> Deploying artifacts into dropins is a major issue! It does not work for >> tenants, so is broken anyway. Anything that does not work in multi-tenant >> mode in terms of deployment, can safely be considered to be broken. >> >> >>> If we go ahead with option 2 to avoid C-Apps getting picked by DS, how >>> can we handle the syncing of aforementioned Artifact types across a >>> cluster? >>> >>> Thanks and Regards, >>> Harshana >>> >>>> >>>> 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 : is...@wso2.com >>>> blog : http://isurues.wordpress.com/ >>>> >>>> lean . enterprise . middleware >>>> >>>> >>>> _______________________________________________ >>>> Dev mailing list >>>> Dev@wso2.org >>>> http://wso2.org/cgi-bin/mailman/listinfo/dev >>>> >>>> >>> >>> >>> -- >>> Harshana Martin >>> Senior Software Engineer >>> WSO2 Inc. : http://wso2.com ; http://wso2.org >>> Mobile: +94 716 062 650 >>> Profile: https://www.google.com/profiles/harshana05 >>> Blog: http://harshana05.blogspot.com >>> Twitter: http://twitter.com/harshana05 >>> >>> >>> >>> _______________________________________________ >>> Dev mailing list >>> Dev@wso2.org >>> http://wso2.org/cgi-bin/mailman/listinfo/dev >>> >>> >> >> >> -- >> *Afkham Azeez* >> Director of Architecture; WSO2, Inc.; http://wso2.com >> Member; Apache Software Foundation; http://www.apache.org/ >> * <http://www.apache.org/>** >> email: **az...@wso2.com* <az...@wso2.com>* cell: +94 77 3320919 >> blog: **http://blog.afkham.org* <http://blog.afkham.org>* >> twitter: **http://twitter.com/afkham_azeez*<http://twitter.com/afkham_azeez> >> * >> linked-in: **http://lk.linkedin.com/in/afkhamazeez* >> * >> * >> *Lean . Enterprise . Middleware* >> >> >> _______________________________________________ >> Dev mailing list >> Dev@wso2.org >> 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 > Dev@wso2.org > http://wso2.org/cgi-bin/mailman/listinfo/dev > > -- Isuru Suriarachchi Senior Technical Lead WSO2 Inc. http://wso2.com email : is...@wso2.com blog : http://isurues.wordpress.com/ lean . enterprise . middleware
_______________________________________________ Dev mailing list Dev@wso2.org http://wso2.org/cgi-bin/mailman/listinfo/dev
