Over a million developers have joined DZone.

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.

· Java Zone

Check out this 8-step guide to see how you can increase your productivity by skipping slow application redeploys and by implementing application profiling, as you code! Brought to you in partnership with ZeroTurnaround.

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 Java 7.
  • The javax.crypto package is available
  • Upgrade to RAP 3.0

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.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 java6-server.profile file:

org.osgi.framework.system.packages = \

org.osgi.framework.bootdelegation = \

The 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"

    <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)" />

With these modifications, the Virgo application server was fully up-to-date!

The Java Zone is brought to you in partnership with ZeroTurnaround. Check out this 8-step guide to see how you can increase your productivity by skipping slow application redeploys and by implementing application profiling, as you code!

eclipse ,virgo

Opinions expressed by DZone contributors are their own.

The best of DZone straight to your inbox.

Please provide a valid email address.

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}