OSGi Remoting over EJB remoting

[pmm]

I wanted to discuss something I have been working on recently. An OSGi Remoting implementation that uses EJB remoting https://github.com/marschall/osgi-remoting-ejb . What does this do and why might you want to use it?

This is intended to be used in an OSGi client application that calls remote EJBs in a Java EE application server. The application server does not have to use OSGi at all. What the code in the project does is it takes the EJB client JARs (provisioned / installed in the OSGi application) and exposes them as OSGi services in the OSGi service registry. This has two advantages. First it decouples the client code from EJB / JNDI. Second it gives out much better integration with OSGi, the client proxies can now easily be used where OSGi services can be used, eg. SCR or injection in Eclipse 4.

There are two places where OSGi Remoting comes into play. First we need to have some information in the EJB client JAR, mainly which interfaces are available under which JNDI name. This information is stored in an XML file that follows the OSGi Remoting XML schema. I worte an annotation process that can automatically generate these files from the source code. Second when the client proxies are registered as OSGi services a property is set that marks them as remote services.

Getting an EJB client to run in OSGi is surprisingly easy, since they all use JNDI you "just" have to set up the TCCL at the right places. What's actually a bigger challenge is having all the required libraries available as OSGi bundles. What why you'll see pull request from me like:

• https://github.com/xnio/xnio/pull/11
• https://github.com/jboss-remoting/jboss-sasl/pull/4

The code is very rough at the moment and more in a proof-of-concept phase. Currently JBoss is the only client I have working, I have plans for GlassFish and TomEE but I'm struggling with their client JARs. Also I'm not sure whether I got all the parts of the OSGi Remoting spec right.

[sys3175]

Hi Philippe,

I have found your project and find it very interesting.

I'm trying a remote EJB client (to an Eclipse application) to connect to an EJB server (JBoss 7 or Wildfly 8).

So, as I understand it, your project can generate the necessary service.xml file from the (remote) interface of the EJB.
In addition, it ensures that the necessary EJB client JARs are available.

This sounds very exciting.

One question I have now: How to use your project?
I think osgi-remoting-ejb-sample contains the (remote) interfaces of the EJB. Is that right?
With custom interfaces I must therefore create your own osgi-remoting-ejb-sample.

And what do I do then? Simply everything to build with maven?

Thank you for an early reply.

Greeting Ronald

PS: translate processing: google :-)

[pmm]

Thank you for your interest. There are several steps involved:

1. You have to generate your EJB client JARs.
   • You have to somehow produce OSGi bundles for your EJB remote client interfaces. These bundles:
     • have to be valid OSGi bundles with (direct) dependencies specified through Require-Bundle or Import-Package
     • must not have dependencies on EJB client libraries specified in the Manifest
     • when running in Equinox the bundle header Bundle-ActivationPolicy: lazy has to be set
     • an OSGi remote service.xml in OSGI-INF/remote-service or a different location specified through the Remote-Service bundle header. The easiest way to do this is through the included annotation processor.
   • We provide an annotation processor that can generate the service.xml for you. The processor needs the following arguments
     • javax.ejb.module.name has to be set to the module name
     • javax.ejb.application.name has to be set to the application name
   • The manifest can be created through maven-bundle-plugin or any other way.
   • sample-ejb uses the processor and maven-bundle-plugin. In addition <generateClient> is used so that EJBs, DAOs and so forth don't end up on the client (they do in the sample). That would be your ejb project.
2. You have to provide several the glue bundles.
   • An equivalent of osgi-remoting-ejb-jboss-client that contains all the EJB client libraries from JBoss (or WildFly) AS that are not already OSGi bundles.
   • An equivalent of osgi-remoting-ejb-jboss that contains an implementation of InitialContextService. The implementation
     • Does authentication (the sample just uses jboss-ejb-client.properties)
     • Provides the initial context
     • Provides the bundle symbolic names of the all the client libraries (the osgi-remoting-ejb-jboss-client equivalent and all the EJB client libraries from JBoss (or WildFly) AS that are already OSGi bundles). It does not provide the bundle symbolic names of your own ejb client JARs from step 1.
3. You have to deploy everything in in your OSGi container.
   • the bundle osgi-remoting-ejb-client has to be started automatically
   • the JBoss (or WildFly) AS EJB client libraries that are already OSGi bundles have to be deployed (eg. org.jboss.spec.javax.transaction.jboss-transaction-api_1.1_spec, org.jboss.spec.javax.ejb.jboss-ejb-api_3.1_spec, javax.xml.jaxrpc-api-osgi, org.jboss.logging.jboss-logging)
   • the implementation of com.github.marschall.osgi.remoting.ejb.api.InitialContextService (the osgi-remoting-ejb-jboss equivalent) has to registered (eg. through Dynamic Services / Service Component Runtime)
   • the equivalent of osgi-remoting-ejb-jboss-client from step 2 has to be deployed unpacked
   • on Equinox the bundles org.eclipse.equinox.ds and org.eclipse.equinox.util have to be deployed.
   • the following VM argument has to be set -Dorg.osgi.framework.system.packages.extra=sun.nio.ch,sun.refelect
   • We recommend to deploy the bundles org.eclipse.equinox.console and org.apache.gogo.shell for debugging bundle issues.

[sys3175]

Hello Philippe,

thank you for your answer.

Is it possible your example on a JBoss 7.1.1 AS to deploy?
I have tried it with the osgi-remoting-ejb-sample-ear, but unfortunately it does not work.

Something with "JBAS014771: Services with missing / unavailable dependencies"

[Edit, 07Aug2014] From the ejb.jar I have the directory OGSI-INF and all bundle information from the MANIFEST.MF deleted.
Now there are no problems during start of JBoss.

Can the remote client (with all dependencies) can be integrated in an Eclipse RCP?
I think that I would have to do the following:
(1) A new RCP projects create (E4-base)
(2) Add dependencies:
(2.1) bundle osgi-remoting-ejb-client with autostart, which level? Is Level 3 ok?
(2.2) bundle osgi-remoting-jboss-ejb with Auto Start (?) and level (?)
(2.3) bundle osgi-remoting-jboss-ejb-client with Auto Start (?) and level (?)
(2.4) the bundles org.eclipse.equinox.ds and org.eclipse.equinox.util should at it (due to the RCP) with Auto Start (?) and level (?)
Is that all?

Thank you for an early reply.
Regards Ronald

[sys3175]

Hello Philippe,

I tried again to get to run your project in Eclipse (Kepler). Did not work. :-(

I have checked out from github (0.3.0) and it just as it is imported into Eclipse.

For the server I have used JBoss 7.1.1. Here I have rolled out the EAR archives.

In the EJB-Jar have to remove all OSGi entries so that JBoss starts the EAR.

Otherwise, there are unmet dependencies.

In Eclipse, I have tried the following bundles in an OSGi framework (Equinox) execute:
(1) com.github.marschall.osgi-remoting-ejb-api
(2) com.github.marschall.osgi-remoting-ejb-client
(3) com.github.marschall.osgi-remoting-jboss-ejb
(4) com.github.marschall.osgi-remoting-jboss-ejb-client
(5) com.github.marschall.osgi-remoting-ejb-sample-client

There are the following problems:
- The package (2) misses the Import-Package com.github.marschall.osgi.remoting.ejb.api
- The package (4) misses the import packages javax.ejb and org.jboss.logging (I have not yet created a bundle for the JBoss client, my mistake)
- Missing the package (5) the Import-Package com.github.marschall.jboss.osgi.remoting.ejb.sample

So I have the console in Eclipse still works included in the following bundles Runtime:
- org.apache.felix.gogo.command (for the console)
- org.apache.felix.gogo.runtime (for the console)
- org.eclipse.osgi.service (for org.eclipse.equinox.ds and org.eclispe.equinox.util)

Now my questions:
1. Why does not find the package (2) and (5) the import packages? Is the fact that the package (4) causes problems?

2. What is the best way to build the missing JBoss client bundle, which the package (4) is needed?

I want to understand how your example works.

And how to build it up best. If possible, also with a building servers such as Hudson.

I think that can be used your example to create an EJB application with both a Web client and a RCP client.

Thank you for an early reply.
Greeting Ronald

PS: English by goo ....:-(

[pmm]

I can not tell you why the packages are missed without further  information. What I usually do debug such issues is.

1. Check the launch configuration. Make sure all bundles I want are selected and then "Validate Bundles/Plugins"
2. In the console find the bundle ids of the plugins (com.github.marschall.osgi.*). Check the state of the plugins. Manually start the plugins that are not started but should be (com.github.marschall.osgi.*). That usually gives you an exception that should help you track the problem down.

You do not need to build the missing JBoss bundles (org.jboss.spec.javax.transaction.jboss-transaction-api_1.1_spec, org.jboss.spec.javax.ejb.jboss-ejb-api_3.1_spec, javax.xml.jaxrpc-api-osgi, org.jboss.logging.jboss-loggng). The JARs themselves are already bundles with a Manifest and everything.

The other option instead of removing the OSGi entries from the EJB-JARs is simply disabling the OSGi subsystem in JBoss AS (it will be gone in WildFly anyway).

The project uses Maven as a build system. Downlad and install Maven and the building the project should be a simple case of

mvn clean package

this should also work on Hudson/Jenkins. Then you can look in the target/ folders and should find the bundles there.