Harshana, good point.. Actually I had forgot about the lib artifacts. Anyway as Azeez mentioned, we only allow lib artifacts for super tenant. So it's kind of broken already.
If we want the libs to work with option 2, we can simply add a new deployer for libs as well.. :) Thanks, ~Isuru On Sat, Jul 7, 2012 at 5:55 AM, Afkham Azeez <[email protected]> wrote: > > > On Sat, Jul 7, 2012 at 2:39 AM, Harshana Martin <[email protected]> wrote: > >> Hi Isuru, >> >> Please find my comments inline. >> >> 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. >>> >> >> 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 : [email protected] >>> blog : http://isurues.wordpress.com/ >>> >>> lean . enterprise . middleware >>> >>> >>> _______________________________________________ >>> Dev mailing list >>> [email protected] >>> 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 >> [email protected] >> 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: **[email protected]* <[email protected]>* 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* > > -- 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
