[
https://issues.apache.org/jira/browse/ODE-901?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12978609#action_12978609
]
Hudson commented on ODE-901:
----------------------------
Integrated in ODE-trunk #400 (See
[https://hudson.apache.org/hudson/job/ODE-trunk/400/])
ODE-901: Improved handling of SMX4 BPEL bundles. Big thanks to Kurt
Westerfeld.
> 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
> Assignee: Tammo van Lessen
> Priority: Blocker
> Fix For: 1.3.5
>
> 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.
