The Demo-EJB

As a simple example EJB, which will be used in our RCP, we will use a small EJB 3.0 stateless session bean. It's a typical "Hello World" bean:

MyTestStatelessSessionRemote.java

MyTestStatelessSessionBean.java

This Bean will be packaged in a JAR-file called MyTestStatelessSession.jar and needs to be deployed to JBoss. After deployment JBoss should echo something like this:

In the next part I'll show you how to create our simple RCP application.

I got a lot of hits to my article about how to connect an Eclipse Rich Client Project to JBoss and EJB 3. Most of these hits came from people outside of germany and they left right after entering the page. So I think that there is some interest in an english version of this article.

Our goal

We want to create an Eclipse Rich Client Project (RCP for now on) consisting of the RCP-plugin and a second plugin containing the JBoss client JARs. To keep things simple, the EJB-Classes will be hold directly in the RCP-Plugin. In a later article I will show how to extract the business-classes in an extra plugin to ensure better maintainablity.

The problem

The OSGI-Classloader from Eclipse creates an extra Classpath for any plugin it loads. Classes from other plugins are therefore invisible. This behavior is pretty good in generel because it allows Eclipse e.g. to enable or disable plugins at runtime. But sometimes it is necessary to give plugin A access to classes in plugin B. This can be archived by declaring a dependency between A and B.

But for our problem we need access in both directions. Our RCP needs "to see" the JBoss classes and JBoss needs access to our EJBs. And because this is not possible you will get a lot of

Javax.naming.CommunicationException [Root exception is java.lang.ClassNotFoundException: bz.jmc.blog.tutorial.rcp_with_jboss.ejb.MyTestStatelessSessionRemote (no security manager: RMI class loader disabled)]

and other errors.

The solution

As mentioned above, you can't set a dependency in both directions. We need another solution for this particular problem and this solution is called "Buddy Classloading". So it is possible to "open" one plugin for others. Other Plugins can register as a buddy and give access to their classes.

In some upcoming articles I will create a small tutorial project with screenshots, illustrating the buddy classloading solution.

• Part 2
• Part 3
• Part 4
• Part 5

English language version here

Als ich neulich das erste Mal aus einer Eclipse RCP heraus auf JBoss zugreifen wollte, bekam ich gleich die unschönen Seiten des OSGI-Classloading zu spüren. Meine Suche im Web nach einer Lösung förderte eigentlich nur die Fragen von anderen zu diesem Thema zu Tage. Daher nun hier mein Versuch, ein kleines Howto zu schreiben damit andere schneller zu einem funktionierendem Ergebnis kommen.

Das Ziel

Ziel soll sein, ein Eclipse Rich Client Project (ab jetzt nur noch RCP) zu erstellen, dass aus dem eigentlichen RCP-Plugin und einem Plugin mit den JBoss-Client-Bibliotheken besteht. Die EJB-Klassen werden wir in diesem Fall erstmal direkt in das RCP-Plugin integrieren, in einem späteren Beitrag werden sie dann, zwecks besserer Wartbarkeit, in ein eigenes Plugin ausgelagert. Die Anwendung soll dann ihre Daten als Session- und Entity-Beans vom JBoss beziehen.

Das Problem

Der OSGI-Classloader von Eclipse erzeugt für jedes geladene Plugin einen eigenen Classpath. Die Klassen von anderen Plugins sind dadurch unsichtbar. Dieses Vorgehen ist auch sinnvoll, denn es ermöglicht unter anderem das (de-) aktivieren von Plugins zur Laufzeit der Anwendung. Sofern ein Plugin (nennen wir es A) sich als Abhängig von einem anderen Plugin (B) erklärt (unter Dependencies im Plugin-Editor) werden die Klassen von B für A sichtbar.

In unserem Falle benötigen wir aber eine beidseitige Sichtbarkeit. Unser RCP muss die JBoss-Klassen sehen und JBoss muss die im RCP vorhandenen EJB-Klassen sehen können. Ist dies nicht gegeben hagelt es

javax.naming.CommunicationException [Root exception is java.lang.ClassNotFoundException: bz.jmc.blog.tutorial.rcp_with_jboss.ejb.MyTestStatelessSessionRemote (no security manager: RMI class loader disabled)]

und ähnliche Fehler.

Die Lösung

Da nicht beide Plugins sich gegenseitig unter Dependencies angeben können benötigen wir eine andere Lösung. Die heisst für uns "Buddy Classloading". Hiermit wird es möglich, dass sich ein Plugin schon während der Implementierung für die Klassen von anderen Plugins "öffnet". Andere Plugins können sich so als Buddy registrieren und Ihre Klassen dem anderen Plugin zur Verfügung stellen.

Auf den folgenden Seiten habe ich ein kleines, mit Screenshots versehenes Tutorial zusammengestellt, dass die Lösung anhand eines einfachen Beispiels erläutert.

Nun, der Einstieg in die Eclipse IDE kann durchaus anstrengend sein. Es ist ja nicht das Eclipse-Paket allein was benötigt wird, es dürfen ja auch gerne einige Plug-Ins sein bis die ganze Sache anfängt Spass zu machen. Diese dann aber bitte noch in der richtigen Version und mit erfüllten Abhängigkeiten. Viel Arbeit also, die sich interessierte Neulinge vielleicht dann doch nicht aufbürden wollen. Selbst nach gut einem Jahr regelmäßiger Arbeit mit Eclipse würde ich mir nur ein "fundiertes Halbwissen" zusprechen.

Aber Hilfe naht und zwar in Form von EasyEclipse. Dies ist eine (nein, eigentlich mehrere) Eclipse-Distribution(en), die für viele Einsatzzwecke maßgeschneiderte Plugin-Pakete bereithält. Zur Zeit stehen Beta-Versionen für folgende Bereiche zur Verfügung:

• Expert Java
• Desktop Java
• Server Java
• Mobile Java
• Plugin Warrior (für Eclipse-Plugin-Developer)
• LAMP
• PHP
• Ruby On Rails
• Python

Alle Pakete stehen sowohl als reine Plugins für ein schon vorhandes Eclipse bereit oder als Komplettpaket für Linux, Mac OS X und Windows.

Also keine Ausreden mehr