Auto install of Java on Ubuntu

We recently had an issue on our appliances for builds that was causing a problem when it came time to install Java via apt-get on Ubuntu.

Found this gem that should save a lot of time:

sudo sh -c ‘echo sun-java6-jre shared/accepted-sun-dlj-v1-1 select true | /usr/bin/debconf-set-selections’;

sudo apt-get install —yes sun-java6-jre;

http://www.davidpashley.com/blog/debian/java-license

OSGi, JavaMail, and the mailcap issue

When developing some of the components for our application, I have been seeing some issues with ClassLoaders when creating them as OSGi bundles.

One main case that had me curious for a while was using JavaMail inside an OSGi bundle, and having to send a multipart mail.

The issue was - JavaMail relies on JAF (the activation framework), which houses a file (mailcap) in it's META-INF directory. So, if these (the javamail and jaf) are stored in separate bundles, then javamail cannot access the configuration file to determine which MIME types it can handle, and thus throwing an UnsupportedDataTypeException:

javax.activation.UnsupportedDataTypeException: no object DCH for MIME type multipart/alternative; 

An UnsupportedDataTypeException usually occurs because JAF cannot find the DataContentHandler (DCH) for a given MIME type by reading the mailcap.

Glassfish 3 actually bundles these together in one bundle (modules/mail.jar), but I was still having the issue described above.

So I went down the path trying to figure out what in the world I could do to get past this. You can't really export resources like you do packages in the manifest, so importing into my bnd file didn't work, and even trying to manually force new mailcaps (which seemed to work elsewhere) didn't work:

MailcapCommandMap mc = (MailcapCommandMap) CommandMap.getDefaultCommandMap();
mc.addMailcap("text/plain;; x-java-content-handler=com.sun.mail.handlers.text_plain");
mc.addMailcap("text/html;; x-java-content-handler=com.sun.mail.handlers.text_html");
mc.addMailcap("text/xml;; x-java-content-handler=com.sun.mail.handlers.text_xml");
mc.addMailcap("multipart/*;; x-java-content-handler=com.sun.mail.handlers.multipart_mixed; x-java-fallback-entry=true");
mc.addMailcap("message/rfc822;; x-java-content-handler=com.sun.mail.handlers.message_rfc822");
CommandMap.setDefaultCommandMap(mc);

This is basically just pushing through exactly what is in the mailcap file directly. But - this didn't work either. Odd...

I then went as far as create a new instance of the specific handler that is being used, and testing the support for that DataFlavor:

DataContentHandler dhmm = new com.sun.mail.handlers.multipart_mixed();
DataFlavor[] dtf = dhmm.getTransferDataFlavors();
for (DataFlavor tmpdf : dtf) {
 log.debug("   isSupported? " + tmpdf.getMimeType() + ":" + message.getDataHandler().isDataFlavorSupported(tmpdf));
}

And it shows it is supported: isSupported? multipart/mixed:true

Yet - when sending the message, same Exception. Ugh...

Finally, Sahoo (from the Glassfish team) gave me a suggestion of manipulating the ClassLoaders when I needed to to make the calls, saving the current ClassLoader so it can be put back into place.

In our bundle, we create the session and send the message in two different methods, so this had to be implemented twice, but finally - it worked!

// There is an issue in the OSGi framework preventing the MailCap
// from loading correctly. When getting the session here,
// temporarily set the ClassLoader to the loader inside the bundle
// that houses javax.mail. Reset at the end.
ClassLoader tcl = Thread.currentThread().getContextClassLoader();

try {
    // Set the ClassLoader to the javax.mail bundle loader.
    Thread.currentThread().setContextClassLoader(javax.mail.Session.class.getClassLoader());

    ...
} finally {
    // Reset the ClassLoader where it should be.
    Thread.currentThread().setContextClassLoader(tcl);
}

This is now working fine. I was a bit leery about mucking with the ClassLoaders in here - which was an issue with using JRuby code inside OSGi bundles as well, but this seems to be OK in that we are temporarily changing and immediately changing back.

JRuby, JMS, OpenMQ, and Serialization

In working towards getting the current application running entirely within the Glassfish context, one of the issues I had to do was get the current implementation of the communication to the message queues away from ActiveMessaging/ActiveMQ into using JMS/OpenMQ.

There are a lot of fingers that ActiveMessaging has in here, so we will have to do some cleanup, but something that was causing me a few issues we figured out today was with the way the serializing of objects and placing in the queue as TextMessages was getting a bit out of whack when we converted some of the publishing models of ActiveMessaging to the sending of the message via JMS.

The serialization (which we are using Marshal dump/load for the ruby objects) was becoming an instance of TextMessageImpl (Java::ComSunMessagingJmqJmsclient::TextMessageImpl).

Simply pulling the text out of this on the jruby side fixed for us:
message = deserialize(message.getText())
and the deserialization worked ok.

Deciding on a platform

One of the tasks in this new role was to determine which platform to take this application/appliance to. We knew it was to move towards a Java/JEE platform, but we needed to make sure what we were choosing was right for the long term, and had the most viability for expansion and technology.

I have worked with many app servers/web containers in the past, and definitely had my mind on what I wanted to work with, but used the time to research as many alternatives as I could to make sure the conclusion was the right one.

The way this application works, we are relying on being able to plug in new "interfaces" that the core application can talk to - via JMS messaging, etc. The application is built using RoR (Ruby on Rails) with a Postgresql backing store.

Clustering and HA were of a concern as well, but the type of clustering that this application requires was beyond the scope of the normal web/http traffic type clustering that is solved via mod_jk or mod_cluster type solutions - although this can help for certain aspects of it.

JVM-level clustering - such as Terracotta - was also an option, but that didn't really solve what we were looking for as a turn-key solution either - so the decision here is to create our own custom solution, using what was available as a basis for the types of clustering that was needed for that type of traffic. Creating an observer of our JMS cloud(s) to peer for relevant information (via JMX hooks) such as acceptable load thresholds and speaking to other nodes to open/start new modules as need to offset the load.

This is going to be a challenge, but a welcome one. :)

I definitely wanted to utilize the OSGi concepts in creating the daemon like plugins that we would be using, as well as using the framework for monitoring activity, so having that capability was a big factor in the decision making. I looked at other modularity solutions, such as JPF (Java Plugin Framework) and Impala, as well as what Project Jigsaw would bring to the table, but decided OSGi would do well for what we needed.

There were many containers that were looked at, including:

• Glassfish v2 and v3
• JBoss 5 and JBoss 6 (M2)
• Geronimo
• WebSphere
• Weblogic
• resin

and others. The final decision for me boiled down to Glassfish v3 and JBoss 6, because of the JEE6 specifications and where they were headed.

So going forward, we will be building this platform using Glassfish v3 - which is exciting to me, because I always thought Glassfish was a great platform, and coming from the NAS world of old, it was great to see where this was going.

Clustering is a bit of an issue that will need to be tackled, but in reading Bill Shannon's roadmap for clustering in v3.1 of Glassfish, as well as needing to build our own, this was not as much of a deal breaker as I was worried about.

The current application also uses ActiveMessaging to communicate with an ActiveMQ server, and with Glassfish's embedded OpenMQ based messaging system, I think the ability to have as much as we can under one container is a big win in this situation.

Thanks to the support of the Glassfish community, and people such as Arun, Alexis, the Glassfish team (blog and twitter) and the others involved, I think using this going forward is going to a fun and exciting project!

New Adventures (so long Sun, hello Extension)!

It has been a long time since I blogged about anything, but with new events that have happened recently, I figured now was as good a time as any!

On January 29th, 2010, I was laid off from Sun Microsystems, where I enjoyed an almost 13 year career. Being bought out by Oracle was going to be an exciting time. I thought we (or I) were going to see a resurgence of the Sun of old. It was a great adventure, and I learned quite a lot, as well as worked with a number great of people, so it was sad to leave.

I did a great number of things while in Sun, including working on the installation environment for Solaris 8 and Solaris 9, creating the installation kiosk for CD0, co-founding the BigAdmin portal (which lived in the installation kiosk, and which stayed with me for 10 years, up until my last day), worked on the sysid suite of tools, ereg, iChange jumpstart application, customized CMS applications and more.

But that being said, I am ready for new challenges and to move onto something new.

On February 22, 2010, I started working for a new company, Extension, Inc., which is developing a health-care communication appliance that has a lot of potential. Sounds very challenging, and involves a lot of research and development which will result in a very compelling product in a field that is very open to new technology right now.

Being in Sun for so many years, I am very used to working under pressure, and getting to develop in some of the latest technologies, and that will continue in my new role (as Sr. Software Engineer), which I am very grateful for.

My new role will involve a lot of Java/JEE development, utilizing Glassfish 3 (awesome!) as well as digging into Ruby/JRuby, and building on the Ubuntu platform to begin with.

So, my first entries here will involve the work I have been doing and will be doing on converting an existing Rails application to work inside of a JRuby container inside of Glassfish 3, the trials involved in that, converting ruby components into OSGi compliant Java modules, and building a solid communication platform for many different devices from within a health-care environment.