Hi Dimuthu, Yes proxy services scenario is a problem. If we go along that path, we have to version sequences/EPR/etc. I would like get this story working atleast for versioning supported artifacts as a start. eg. axis2 service (hierarchical), apis and webapps.
For proxy services, the current workaround is to create tenants and deploy them. --Pradeep On Mon, May 27, 2013 at 5:08 AM, Dimuthu Leelarathne <[email protected]>wrote: > Hi Pradeep, > > When a CApp is versioned how do we manage the EPRs of the artifacts in the > CApp? > > thanks, > dimuthu > > > On Fri, May 24, 2013 at 4:10 PM, Pradeep Fernando <[email protected]>wrote: > >> Thanks Kishanthan. :) >> Harshana shall we work together and fix this for versioned supported >> artifacts. Kishanthans , response suggest that this is a carbon level fix. >> I would love to see a versioned api + versioned capp working sample. >> Axis2 is a seperate thing. May be we should figure out a way to support >> versioning at the deployer level. We have integrated number of runtimes to >> the platform over the years. We can't add versioning support to each of >> those run times. >> >> --Pradeep >> sent from my phone >> On May 24, 2013 3:20 PM, "Kishanthan Thangarajah" <[email protected]> >> wrote: >> >>> >>> >>> >>> On Fri, May 24, 2013 at 12:37 PM, Pradeep Fernando <[email protected]>wrote: >>> >>>> yes, thats exactly what i'm asking. Forget about axis2 services. Even >>>> multiple versioned .car files (with manually edited axis2 services) are not >>>> working. >>>> >>> >>> >>> Yes, currently there are two issues arising when deploying CApps with >>> different versions. >>> >>> 1. When deploying the second CApp (new) with different version, it is >>> throwing "*Carbon Application : AppServerCAPP already exists. Two >>> applications can't have the same Id. Deployment aborted.*" >>> This is because of a bug in checking the CApp id. It should be checked >>> against the version aswell. I just tried this. This can be fixed. >>> >>> 2. If we manually edit/rename an old CApp and deploy it with different >>> version, it is throwing a different error. >>> >>> [2013-05-24 10:53:16,590] ERROR >>> {org.wso2.carbon.application.deployer.internal.ApplicationManager} - Error >>> occurred while deploying Carbon Application >>> org.wso2.carbon.CarbonException: Error while extracting Carbon >>> Application : AppServerCAPP_2.0.0.car >>> at >>> org.wso2.carbon.application.deployer.AppDeployerUtils.extractCarbonApp(AppDeployerUtils.java:441) >>> at >>> org.wso2.carbon.application.deployer.internal.ApplicationManager.deployCarbonApp(ApplicationManager.java:196) >>> at >>> org.wso2.carbon.application.deployer.CappAxis2Deployer.deploy(CappAxis2Deployer.java:71) >>> at >>> org.apache.axis2.deployment.repository.util.DeploymentFileData.deploy(DeploymentFileData.java:136) >>> at >>> org.apache.axis2.deployment.DeploymentEngine.doDeploy(DeploymentEngine.java:810) >>> at >>> org.apache.axis2.deployment.repository.util.WSInfoList.update(WSInfoList.java:144) >>> at >>> org.apache.axis2.deployment.RepositoryListener.update(RepositoryListener.java:377) >>> at >>> org.apache.axis2.deployment.RepositoryListener.checkServices(RepositoryListener.java:254) >>> at >>> org.apache.axis2.deployment.RepositoryListener.startListener(RepositoryListener.java:371) >>> at >>> org.apache.axis2.deployment.scheduler.SchedulerTask.checkRepository(SchedulerTask.java:59) >>> at >>> org.apache.axis2.deployment.scheduler.SchedulerTask.run(SchedulerTask.java:67) >>> at >>> org.wso2.carbon.core.deployment.CarbonDeploymentSchedulerTask.runAxisDeployment(CarbonDeploymentSchedulerTask.java:67) >>> at >>> org.wso2.carbon.core.deployment.CarbonDeploymentSchedulerTask.run(CarbonDeploymentSchedulerTask.java:112) >>> at >>> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) >>> at >>> java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:317) >>> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:150) >>> at >>> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:98) >>> at >>> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.runPeriodic(ScheduledThreadPoolExecutor.java:180) >>> at >>> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:204) >>> at >>> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) >>> at >>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) >>> at java.lang.Thread.run(Thread.java:662) >>> Caused by: java.io.FileNotFoundException: >>> /home/kicha/checkouts/wso2/carbon/platform/trunk/products/as/modules/distribution/target/wso2as-5.2.0-SNAPSHOT/tmp/carbonapps/1369372899787AppServerCAPP_2.0.0.car/WebAppSample_2.0.0/artifact.xml >>> (No such file or directory) >>> at java.io.FileOutputStream.open(Native Method) >>> at java.io.FileOutputStream.<init>(FileOutputStream.java:194) >>> at java.io.FileOutputStream.<init>(FileOutputStream.java:84) >>> at >>> org.wso2.carbon.application.deployer.AppDeployerUtils.extract(AppDeployerUtils.java:668) >>> at >>> org.wso2.carbon.application.deployer.AppDeployerUtils.extractCarbonApp(AppDeployerUtils.java:439) >>> ... 21 more >>> >>> This is because, even-though we manually edit the CApp, at code level, >>> it is getting treated as the old CApp. When extracting the file, the zip >>> file entries listed >>> in AppDeployerUtils#extract method are the old Capp's entries. This is >>> already reported [1] as-well. >>> >>> Thanks, >>> Kishanthan. >>> [1] https://wso2.org/jira/browse/CARBON-13599 >>> >>> >>> >>> >>>> --Pradeep >>>> >>>> >>>> On Fri, May 24, 2013 at 6:54 AM, Kishanthan Thangarajah < >>>> [email protected]> wrote: >>>> >>>>> We already have the building blocks to support CApp versioning, but >>>>> the thing is, not every artifacts can support versioning as of now. For >>>>> example, we can add version to a webapp by changing its context (this is >>>>> what Dev-Studio does), but for an axis2 service, this is not >>>>> possible unless we change the service name it self with the version. >>>>> >>>>> Thanks, >>>>> Kishanthan >>>>> >>>>> On Fri, May 24, 2013 at 7:35 AM, Pradeep Fernando >>>>> <[email protected]>wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> >>>>>> Adding versioning support to third party hosting artifacts can be >>>>>> tricky (eg: axis2). However, AFAIK, we don't support multiple versioned >>>>>> .car files as well. We sure can support it IMHO. >>>>>> >>>>>> In the future, during an introduction of new hosting engine to the >>>>>> platform, we have to figure out, at least >>>>>> >>>>>> - tenancy model >>>>>> - versioning model >>>>>> >>>>>> >>>>>> thanks, >>>>>> --Pradeep >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Dev mailing list >>>>>> [email protected] >>>>>> http://wso2.org/cgi-bin/mailman/listinfo/dev >>>>>> >>>>>> >>>>> ** >>>>> >>>> >>>> >>>> >>>> -- >>>> *Pradeep Fernando* >>>> Member, Management Committee - Platform & Cloud Technologies >>>> Senior Software Engineer;WSO2 Inc.; http://wso2.com >>>> >>>> blog: http://pradeepfernando.blogspot.com >>>> m: +94776603662 >>>> >>> >>> ** >>> >> >> _______________________________________________ >> Dev mailing list >> [email protected] >> http://wso2.org/cgi-bin/mailman/listinfo/dev >> >> > > > -- > Dimuthu Leelarathne > Architect & Chair of Solution Management Committee > > WSO2, Inc. (http://wso2.com) > email: [email protected] > Mobile : 0773661935 > > Lean . Enterprise . Middleware > -- *Pradeep Fernando* Member, Management Committee - Platform & Cloud Technologies Senior Software Engineer;WSO2 Inc.; http://wso2.com blog: http://pradeepfernando.blogspot.com m: +94776603662
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
