My First Experiences With Virgo and Eclipse RAP, Part 2
A continuation on how to run a Java application server on three servers, and using Virgo and Eclipse to do so.
Join the DZone community and get the full member experience.Join For Free
It has been a while since my first post on my newbie experiences with Virgo, but this does not mean that it has slowly vanished from sight! On the contrary; I am now running the Java application server on three servers, and I feel that I understand the mechanisms well enough to be at ease with maintaining the Java applications I am running on them. However, this ease did come at a price, for there were a few tough problems for me to chew on before I finally got everything to work the way I wanted.
Before continuing, I must say that I am still very happy with the set up that I described in the first post. Soon after I had shared my experiences, I had to go through all the steps again, because the 3.6.4 Version of the kernel became available, and now it was a matter of hours before I had everything up and running. A quick recap of the situation:
- Debian Squeeze server
- Oracle JAVA 7 installed
- Virgo kernel 3.6.4, with a Jetty server but installed in a different fashion than the Jetty server edition that the Virgo team offers
- RAP 2.3.0 installed
As was mentioned in the previous post, I decided not to go for the standard Virgo Jetty edition, because at the time of writing it was - in my view- a messy and somewhat bloated version, with a lot of double bundles (e.g. the Spring bundles), which made it difficult to debug. My version had a nice balance between the simplicity of the nano-rap version, but with the extensibility of the regular kernel. The only downside is that the styling of the management console disappeared at some point, and I haven't been able to fix that yet.
When I had the 3.6.4 kernel up and running, I did feel that there was some room for improvement, and I ran into a number of tough configuration issues. All in all, the following improvements have been made:
- The kernel supports
javax.cryptopackage is available
- Upgrade to
The required changes are minor, but especially the second feature cost me a lot of headaches. I'll run through the necessary changes to make this work.
The first two modifications require a change in the
java6-server.profile file that is located in the
$SERVER_HOME/configuration folder. The following figure shows the modifications needed to activate support for
Java 7. At the end of the file add the highlighted line:
org.osgi.framework.executionenvironment = \ OSGi/Minimum-1.0,\ OSGi/Minimum-1.1,\ J2SE-1.2,\ J2SE-1.3,\ J2SE-1.4,\ J2SE-1.5,\ JavaSE-1.6,\ JavaSE-1.7 osgi.java.profile.name = Virgo-Java6
With this, it becomes possible to upgrade RAP to version 3.0. But before doing so, I ran into some problems trying to get the
javax.crypto package activated, which I needed to use for twitter4j. In order to make this possible, add the following to the
org.osgi.framework.system.packages = \ ... javax.crypto,\ javax.crypto.interfaces,\ javax.crypto.spec,\ ... org.osgi.framework.bootdelegation = \ org.eclipse.virgo.nano.authentication,\ com.sun.*,\ javax.xml.*,\ javax.crypto.*,\ org.apache.xerces.jaxp.*,\ org.w3c.*,\ org.xml.*,\ sun.*
org.osgi.framework.system.packages basically provides packages from the
JRE for use in the user region, while the
org.osgi.framework.bootdelegation releases packages for Equinox' boot loader. The system packages were already prepared with the 3.6.4 release of the kernel, but the the
crypto packages still needed to be added to the boot delegation.
The bundle that uses twitter4j (or another library that uses javax.crypto) must import the javax.crypto packages in the MANIFEST.MF, even if they are not referenced! If not, you will get a runtime error when the application needs the packages. In my setup, this bundle was activated in a plan, and I have found out the Virgo sandboxing is extremely restricted. Which is not a criticism, by the way.
With these changes, twitter4j worked like a charm.
Last, I wanted to update RAP. This was simple a matter of replacing the four
RAP 2.3.0 bundles with their 3.0 counterparts, and then changing the org.eclipse.rap plan:
<?xml version="1.0" encoding="UTF-8"?> <plan name="org.eclipse.rap" version="3.0.0" scoped="false" atomic="true" xmlns="http://www.eclipse.org/virgo/schema/plan" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation=" http://www.eclipse.org/virgo/schema/plan http://www.eclipse.org/virgo/schema/plan/eclipse-virgo-plan.xsd"> <artifact type="bundle" name="org.eclipse.rap.rwt" version="[3.0.0, 4.0.0)" /> <artifact type="bundle" name="org.eclipse.rap.rwt.osgi" version="[3.0.0, 4.0.0)" /> <artifact type="bundle" name="org.eclipse.rap.jface" version="[3.0.0, 4.0.0)" /> <artifact type="bundle" name="org.eclipse.rap.jface.databinding" version="[3.0.0, 4.0.0)" /> </plan>
With these modifications, the Virgo application server was fully up-to-date!
Opinions expressed by DZone contributors are their own.