Musings of a Trained Monkey

I am a huge fan of Jetty for Java web application development. Love how fast it loads, reloads, and generally kicks the crap out of Tomcat. The Jetty team seems to follow the JEE specifications that they do implement (not all of them) much more strictly than Tomcat. This makes it a very good testbed for developing applications that will be eventually hosted on WebLogic Server .

Until you need to do something like run Message Driven Beans with WLS special performance enhancing sauce. Jetty has it’s jetty-plus configuration which supports JNDI and some other JEE niceties. If you really want to use the full on BEA JMS/MDB combo though you have a problem.

Including the weblogic.jar in Jetty’s classpath is not the answer. This will cause all sorts of confusion about which implementations of java. * and javax. * packages to use. Within the WebLogic Server distribution’s server/lib directory there is a wlclient.jar. Again this won’t work right in your overall classpath, but it will work if you put the wlclient.jar inside of a webapp’s WEB-INF/lib directory. Your code will just need to make a small accommodation for connecting to WLS JNDI constructing the InitialContext with the WebLogic specific properties:

    Properties props = new Properties();
    props.put(Context.INITIAL_CONTEXT_FACTORY,"weblogic.jndi.WLInitialContextFactory");
    props.put(Context.PROVIDER_URL, "t3://localhost:7001");
    InitialContext ctx = null;
  try{
      InitialContext ctx = new InitialContext(props);
       (...Lookup JMS Queues, place Messages, etc...)
  } catch (Exception e) {
     (do something!)
  } finally {
       try{ ctx.close() } catch (Exception e) { (eek! just have to eat this one!)}
  }

This gives you the flexibility of using Jetty configured JNDI objects as well as leveraging WebLogic JNDI objects without having to eat huge WebLogic redeployment startup times for your web application.