Author: janb

Jetty now supports annotations on managed beans with Sun’s JSF RI version 1.2_04.

For the curious, the magic happens in the Jetty6InjectionProvider class that is distributed in the RI jars.

However, that’s just an implementation detail. All you need to do is to mark up your jsf beans as usual with annotations (see the annotations supported by jetty, and the jetty/jsf integration will make sure they’re injected and the callbacks called appropriately. Also take a look at how to throw the JSF RI jars into Jetty.

Big thanks to Ryan Lubke from the JSF RI team who worked very closely with us on implementing this! Ryan has also blogged about the jetty integration.

Hightide is a versioned, optimized distro of Jetty, with many J2EE/JavaEE features pre-integrated in a lightweight manner so you can enjoy their benefits but without needing a heavyweight JavaEE Application Server. We’ve also included state-of-the-art, scaleable backend support for Ajax. The idea being to provide a powerful but flexible container for webapp development and deployment. The distro gives you these features already baked in:

• Servlet 2.5 container (Jetty)
• JSP2.1 support
• XA transactions (from Atomikos)
• JNDI
• Annotations (coming in the next release)
• JMS (from ActiveMQ)
• JDBC (from Derby)
• JAAS
• JMX
• Continuations
• Hot deployment
• cometd implementation
• DWR

If you prefer to use a different database, XA manager or messaging fabric you can simply swap them in instead.

You also get a live log viewer accessible from your browser, and integration with JDK logging.

To help you get started quickly, we’ve included a few Ajax-based webapps that demonstrate the features of Hightide. One of them, the Auction Demo is also available live on the Webtide site if you want a sneak preview.

Like Jetty, Hightide is open source and uses the Apache 2.0 licence.Via Webtide we are providing full, long term dev and production support for it.

Having had a couple of emails on the Jetty lists about using EJB3 with Jetty, I’ve been looking at the various embeddable technologies around.

Last week I looked at the JBoss Embeddable EJB3 product and got it working in Jetty.

I briefly also mentioned some work we’re doing with the EasyBeans guys – a blog entry is coming on that soon.

A couple of people have mentioned Pitchfork to me in the space of a week, so I decided I’d better check it out. Turns out that it is a an EJB3 implementation for deployment with Spring. There’s an InfoQ article on it, describing it as the result of collaboration between Spring committers and some of the BEA Weblogic team.

Having checked out Christian Dupuis’s blog about using it with Tomcat, I decided to see how hard it would be to use it with Jetty.

The answer was that it was easy!

I’ve added a couple of simple Spring classes to the extras/spring module in Jetty to hook up a webapp to Pitchfork’s resource and ejb injection facilities.

They’re checked in to jetty svn trunk at the moment, so you’ll need to checkout and build jetty to get them. Then:

1. make a new directory $jetty.home/lib/ext/spring, and copy the $jetty.home/extras/spring/target/jetty-spring-6.1-SNAPSHOT.jar into it
2. download Pitchfork and copy all of the dist/ and lib/ jars into $jetty.home/lib/ext/spring

Now you can create yourself a webapp, some ejbs and some beans that reference the ejbs using @EJB injection notation, and deploy it to Jetty!

I’ve put more detailed instructions on the Jetty wiki, plus a very simple webapp that uses EJB3s as an example to get you started.

JBoss have come up with an embeddable version of their EJB3 implementation. An alpha release is available for download.

I downloaded it and played around with the embedded example from the tutorial.
Here’s what I did:

1. once you’ve downloaded and unzipped the alpha release (I tested with jboss-EJB-3.0_Embeddable_ALPHA_5.zip), go to the
   docs/embedded-tutorial/embedded-war directory and build it (just type ant).
2. unjar the war file in docs/embedded-tutorial/embedded-war/build/standalone.war to your $jetty.home/webapps directory.
3. move all of the jars in $jetty.home/webapps/standalone/WEB-INF/lib except for tutorial.jar to $jetty.home/lib/ext/jboss (see below for more on this).
4. finally, edit the $jetty.home/webapps/standalone/EmbeddedEJB3.jsp file. The JNDI lookups for the beans in this file don’t work and don’t match the documentation, so you need to change them. Find the lines:
   
   

   CustomerDAOLocal local = (CustomerDAOLocal)
   ctx.lookup(CustomerDAOLocal.class.getName());
   CustomerDAORemote remote = (CustomerDAORemote)
   ctx.lookup(CustomerDAORemote.class.getName());
   

   
   
   change them to:
   
   

   CustomerDAOLocal local = (CustomerDAOLocal)
   ctx.lookup("CustomerDAOBean/local");
   CustomerDAORemote remote = (CustomerDAORemote)
   ctx.lookup("CustomerDAOBean/remote");
   

   
   

5. start jetty: java -jar start.jar and now you can test EJB3s in jetty by surfing to the demo: http://localhost:8080/standalone/EmbeddedEJB3.jsp

I don’t think it should be necessary to move the jboss jars out of the webapp, but it makes sense if you want to use EJB3 with more than one webapp.

I haven’t as yet been able to make it work with leaving the jars inside the webapp. I get a ClassNotFoundException:

Caused by: org.jboss.util.NestedRuntimeException:
Cannot load class org.jboss.mx.server.JBossMXServerConfig;
- nested throwable: (java.lang.ClassNotFoundException:
org.jboss.mx.server.JBossMXServerConfig)
at org.jboss.util.Classes.instantiate(Classes.java:514)
at org.jboss.mx.server.ServerConfig.getInstance(ServerConfig.java:74)
at javax.management.MBeanServerFactory.(MBeanServerFactory.java:79)

The class doesn’t seem to exist in any of the jars supplied with the demo, so the ClassNotFoundException seems reasonable enough. However, I haven’t had time to investigate why it does not occur when the jars are in Jetty’s lib directory.

With release 6.1.0pre2 we now provide Jetty-JBoss integration for the Jetty 6 series.

This brings a number of important new features for JBoss users to enjoy such as servlet 2.5 support, and moreover, scalability for ajax via our Continuations mechanism and our cometd implementation.

There’s the beginnings of documentation on it on the jetty wiki.

For the moment, you’ll need to build the extras/jboss module from the jetty src distro (instructions on the wiki). For future releases, we’ll publish a sar file to the usual repositories

The maven mvn archetype:create command is a powerful one. It can create you a whole new ready-to-run application, complete with templated sources, config files etc. It takes a lot of the pain out of starting a new application.
Webtide has created a collection of maven webapp project archetypes which are freely downloadable from our site. We’ve made archtypes for most of the popular webapp technologies: DWR, ActiveMQ-Web, Dojo, SiteMesh, Tapestry, WebWorks, Struts, Spring and more.
It’s just 4 easy steps to starting a new project:

1. download the mini-maven project for the archtype of your choice
2. build the archetype with mvn install
3. generate your project with mvn archetype:create …
4. execute your new webapp immediately with mvn jetty:run

Now you have a freshly-made, running project with the webapp techology of your choice already baked in and ready for you to modify and extend. You have saved yourself hours or even days of work!
I knew archetypes were powerful, but it was brought home to me today answering a question on the jetty lists. A user was having problems with a sitemesh webapp. I simply downloaded our sitemesh archetype, generated a sitemesh app and modified it to match the user’s configuration.
It took me all of 5 minutes until I had a working webapp I could use to try to replicate the problem!
Without the archetype, it would have taken me hours researching sitemesh, downloading it, making a maven project and a webapp that worked.
Even sweeter, just changing a single line in the generated webapp’s pom.xml allowed me to immediately run the webapp under a different version of jetty with the mvn jetty:run command. I was able to try out the webapp’s behaviour with 3 different versions of jetty in under 5 minutes!
We want our maven archetype portfolio to be as comprehensive as possible, so if you spot a technology we don’t have covered, please contact us and suggest it.

Somebody recently brought it to my attention that there’s a rumour going around that you can’t run JIRA on Jetty.

Sure enough, digging around on the Atlassian site showed up with this: http://www.atlassian.com/software/jira/docs/v3.6.5/servers/jetty.html.

Rising to the implicit challenge, I set out to make JIRA run under jetty 6.x. As it only took 5 mins, I didn’t have anything to do for the rest of the day, so I decided to write up a wiki entry for it: http://docs.codehaus.org/display/JETTY/JIRA

So with time still on my hands, I decided to blog about it too!

Actually I am a little disappointed that the Atlassian guys never contacted, so far as I am aware, any of the Jetty committers to ask for some help with any difficulties they were having. We are more than happy to work with anyone to get their project/product working with Jetty, as I hope we’ve demonstrated amply both in the past and present.

So, please give JIRA in Jetty a go, as it all seems to be working. Of course, if there are problems, feel free to post to jetty-discuss@lists.sourceforge.net and we’ll do our best to resolve them.

With any luck, an Atlassian will read this and update their website (hint hint hint).

Running any user program on low port numbers on *nix systems is generally tricky, as low port numbers are protected and only accessible as the root user.

In the past, jetty’s suggested solution has been to use iptables or ipchains to configure the operating system to forward traffic for port 80 (for example) to port 8080 (for example). Here’s the FAQ entry on how to do that here:
http://docs.codehaus.org/display/JETTY/port80

Recently, we decided to make this easier by adding a new feature which means you will be able to invoke jetty as the superuser, but after the ports have been opened the userid will change back to a non-privileged user, preserving the runtime safety of your system.

This little gem can be found currently in svn trunk and is slated for release in the 6.1.0. Look in $jetty.home/extras/setuid for the code and the README on how to build it. As the build requires native libs, there are some system-dependent configurations you have to provide, so there are a couple of steps you have to do manually for the build.
The README.txt file has full instructions, but I’ll reproduce it here to give you the general idea to start you off:

Build