[
https://issues.apache.org/jira/browse/ODE-901?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12970193#action_12970193
]
Kurt Westerfeld commented on ODE-901:
-------------------------------------
Moving on from my last post on this ticket, related to using the
ServiceActivator from jbi-bundle, we ended up completely scrapping that code,
and ended up with something a lot better, and something I think a lot of the
ODE community could use. Basically, when running on an OSGi container, there
are "signals" or events for bundles that need to be mapped over to ODE
deployment calls. These are events on a bundle involving:
- Starting
- Stopping
- Updating
- Installing
- Uninstalling
What we ended up doing is writing an OSGi bundle tracker, similar to what OSGi
Blueprint does. It lives outside the boundaries of application code, alongside
Apache ODE, and notices new bundles being installed that contain a "deploy.xml"
file, and 1 or more .bpel files. When this occurs, it "adopts" the bundle and
completely manages its lifecycle. This is actually quite an improvement.
Now, regarding a BPEL developer's point-of-view, one simply jars up a bpel
project and creates an OSGi manifest, and deploys the jar to servicemix. The
ODE bundle activator takes care of the rest. The only requirement for a bundle
is to have the "Bundle-SymbolicName" -- which can even be implied by using pax
wrapped jar deployment. The bundle symbolic name is used to name the
deployment unit to ODE.
In addition, we added support for process versioning, tieing the bundle
manifest version to the process deployment version. We needed to support
upgrade in the field of bpel processes, and we were able to accomplish this
completely in the ODE bundle activator with no changes to ODE proper.
At any rate, I think the ODE community should have this code. Is there
interest in this mode of deployment for OSGi?
> 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
>
> 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.
