ode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kurt Westerfeld (JIRA)" <j...@apache.org>
Subject [jira] Updated: (ODE-901) Cannot Deploy More than One Process on Servicemix 4 Using OSGi Bundling
Date Mon, 13 Dec 2010 15:47:01 GMT

     [ https://issues.apache.org/jira/browse/ODE-901?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Kurt Westerfeld updated ODE-901:

    Attachment: ODE-901.patch

Patch for deployment service running on OSGi container (ODE sub-project "jbi-bundle"):

 - ServiceUnitActivator is deprecated and detected for existing ODE bundles
 - The OdeExtender service detects bundle lifecycle events from OSGi and diverts calls into
the ODE deployment mechanisms
 - Any OSGi bundle that contains a deploy.xml and one or more .bpel files is hijacked by the
OdeExtender and lifecycle managed
 - original fix for deployment of more than one bundle is handled by creating a deployment
directory for the DU which is tied to the bundle symbolic name instead of the directory "bpelData",
which caused the second deployment to fail in all cases.
 - signals for start/stop/install/uninstall/update are handled
 - OSGi asynchronous startup and dependency on ODE component lifecycle (ie. OdeLifeCycle)
is handled properly, which is a problem when starting the OSGi container on a multi-process
box and deployment would fail because ODE was busy starting up and could not accept deploy
 - version upgrade of BPEL bundles is supported for BPEL process upgrade by using the OSGi
version manifest "micro" version, triggering the ODE process upgrade mechanism
 - Added TODO: markers in code where internal state/variables were used in order to work around
asynchronous start and deployment state.  These are slightly unclean and could be made better
by adding bean accessors to OdeLifeCycle and OdeContext

> Cannot Deploy More than One Process on Servicemix 4 Using OSGi Bundling
> -----------------------------------------------------------------------
>                 Key: ODE-901
>                 URL: https://issues.apache.org/jira/browse/ODE-901
>             Project: ODE
>          Issue Type: Bug
>          Components: JBI Integration
>    Affects Versions: 1.3.4
>         Environment: Servicemix 4, Fuse 4.3 distribution
>            Reporter: Kurt Westerfeld
>            Priority: Blocker
>         Attachments: ODE-901.patch
> We have several processes we are porting to servicemix 4 from servicemix 3 JBI bundling.
 Using the "ping pong OSGi" example, we are using the OSGi service activator called "org.apache.ode.jbi.osgi.ServiceUnitActivator".
> When doing so, we are noticing that the process store throws an exception for the second
and subsequent process deployments.  The issue is, that the process deployment is not fed
the bundle symbolic name, which would be similar to how the JBI distribution would distinguish
between two processes.  In this case, the first process is named "bpelData" and so is the
second and following process deployments.  Basically, we cannot use OSGi bundling at all on
servicemix 4, which we need to do for our port.
> I see two ways to fix this.  First, the easiest would be to change the "bpelData" hardcoded
name in ServiceUnitActivator with this patch: 
> Index: jbi-bundle/src/main/java/org/apache/ode/jbi/osgi/ServiceUnitActivator.java
> ===================================================================
> --- jbi-bundle/src/main/java/org/apache/ode/jbi/osgi/ServiceUnitActivator.java  (revision
> +++ jbi-bundle/src/main/java/org/apache/ode/jbi/osgi/ServiceUnitActivator.java  (working
> @@ -45,7 +45,7 @@
>      public void start(BundleContext context) throws Exception {
>          generatedName = context.getBundle().getSymbolicName();
> -        rootDir = context.getDataFile("bpelData");
> +        rootDir = context.getDataFile("bpelData/" + generatedName);
>          rootDir.mkdirs();
>          Enumeration<?> en = context.getBundle().findEntries("/", "*", false);
>          while (en.hasMoreElements()) {
> Perhaps even context.getDataFile(generatedName); would be more appropriate.
> Alternately, the change might be better to do within org.apache.ode.jbi.OdeSUManager.deploy(String,String),
which seems to be fed the generatedName seen above.  In this case, though, it would need to
pass the name along to deploy() which currently takes no args.  I see that that change might
be more potentially disruptive to jbi users.
> The exception shows here:
> 19:53:50,600 | ERROR | l Console Thread | OdeServiceUnit                   | rg.apache.ode.jbi.OdeServiceUnit
  77 | 188 - ode-jbi-bundle - 1.3.4 | Error deploying process described by deployment descriptor
"R:\data\cache\org.eclipse.osgi\bundles\241\data\bpelData" for service unit "provision-reporting-process".
> org.apache.ode.bpel.iapi.ContextException: Deploy failed; Deployment Unit "bpelData"
already deployed!
> 	at org.apache.ode.store.ProcessStoreImpl.deploy(ProcessStoreImpl.java:218)[188:ode-jbi-bundle:1.3.4]
> 	at org.apache.ode.store.ProcessStoreImpl.deploy(ProcessStoreImpl.java:164)[188:ode-jbi-bundle:1.3.4]
> 	at org.apache.ode.jbi.OdeServiceUnit.deploy(OdeServiceUnit.java:74)[188:ode-jbi-bundle:1.3.4]
> 	at org.apache.ode.jbi.OdeSUManager.deploy(OdeSUManager.java:59)[188:ode-jbi-bundle:1.3.4]
> 	at org.apache.ode.jbi.osgi.ServiceUnitActivator.start(ServiceUnitActivator.java:65)[188:ode-jbi-bundle:1.3.4]
> 	at org.eclipse.osgi.framework.internal.core.BundleContextImpl$1.run(BundleContextImpl.java:783)[osgi-3.6.0.v20100517.jar:]
> 	at java.security.AccessController.doPrivileged(Native Method)[:1.6.0_18]
> 	at org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.java:774)[osgi-3.6.0.v20100517.jar:]
> 	at org.eclipse.osgi.framework.internal.core.BundleContextImpl.start(BundleContextImpl.java:755)[osgi-3.6.0.v20100517.jar:]
> 	at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:370)[osgi-3.6.0.v20100517.jar:]
> 	at org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:284)[osgi-3.6.0.v20100517.jar:]
> 	at org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:276)[osgi-3.6.0.v20100517.jar:]
> 	at org.apache.karaf.shell.osgi.InstallBundle.doExecute(InstallBundle.java:54)[10:org.apache.karaf.shell.osgi:2.0.0.fuse-01-00]
> 	at org.apache.karaf.shell.console.OsgiCommandSupport.execute(OsgiCommandSupport.java:41)[16:org.apache.karaf.shell.console:2.0.0.fuse-01-00]
> 	at org.apache.felix.gogo.commands.basic.AbstractCommand.execute(AbstractCommand.java:35)[16:org.apache.karaf.shell.console:2.0.0.fuse-01-00]
> 	at org.apache.felix.gogo.runtime.shell.CommandProxy.execute(CommandProxy.java:50)[21:org.apache.felix.gogo.runtime:0.4.0]
> 	at org.apache.felix.gogo.runtime.shell.Closure.execute(Closure.java:229)[21:org.apache.felix.gogo.runtime:0.4.0]
> 	at org.apache.felix.gogo.runtime.shell.Closure.executeStatement(Closure.java:162)[21:org.apache.felix.gogo.runtime:0.4.0]
> 	at org.apache.felix.gogo.runtime.shell.Pipe.run(Pipe.java:101)[21:org.apache.felix.gogo.runtime:0.4.0]
> 	at org.apache.felix.gogo.runtime.shell.Closure.execute(Closure.java:79)[21:org.apache.felix.gogo.runtime:0.4.0]
> 	at org.apache.felix.gogo.runtime.shell.CommandSessionImpl.execute(CommandSessionImpl.java:71)[21:org.apache.felix.gogo.runtime:0.4.0]
> 	at org.apache.karaf.shell.console.jline.Console.run(Console.java:181)[16:org.apache.karaf.shell.console:2.0.0.fuse-01-00]
> 	at java.lang.Thread.run(Thread.java:619)[:1.6.0_18]

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message