[
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 997965)
> +++
> jbi-bundle/src/main/java/org/apache/ode/jbi/osgi/ServiceUnitActivator.java
> (working copy)
> @@ -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.
