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? 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
