Hi Isuru, On Sat, Jul 7, 2012 at 9:48 AM, Isuru Suriarachchi <[email protected]> wrote:
> 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.. :) > +1 for a deployer for Libs because currently if there are artifacts which uses 3rd party Libraries and users have a cluster deployment, suggested method to sync the artifacts and the 3rd party jars is to use Lib Artifacts. So it's kind of integral part of the deployments right now. :) Thanks and Regards, Harshana > > 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 > > -- 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
