Pax Web 4.0 has been released about a week ago. This version consists of more then 100 issues. So take a look at the key benefits of this version.
What’s important and new
This will give you a brief overview about the new and the important changes of Pax Web 4.0.
A lot has changed internally to support JSP 2.2 out of the box. JSF 2.1 can be used too, this has been back ported and introduced to the Pax Web 3.x line as well.
This is more of an internal thing. Still I think it’s a valuable enhancement for the project. From 4.0 on it is possible to use Code-Coverage (JaCoCo). Even our Sonar is now able to use that.
Upgrade to the latest 9.0 version of Jetty. The upgrade to Jetty 9.1 is targeted for Pax Web 4.1.
One of the things I regard to be important in this release is the much better support for Tomcat as underlying server. A lot of the stuff you can do with Jetty as underlying server can also be done with Tomcat now. Still I don’t think using Tomcat in combination with Pax Web 4.0 is good for production, there are still things to fix and to improve. Beginning with Pax Web 4.0, a feature for installing Pax Web with Tomcat is available, so you can easily decide between Jetty and Tomcat if you run in a Karaf environment.
Following is a list of improvements still open for the Pax Web Tomcat support:
- Full Support for JSP
- support of a tomcat-web.xml like jetty-web.xml, if something like this is really supported by tomcat.
- support of configuring tomcat by an extra config file, similar to the way jetty is configurable with the jetty.xml
This is already possible with Pax Web 3.x, but in Pax Web 4.0 this has been much improved. If a Shared HttpContext is used it needs to register itself in the service registry as share-able. For this a flag is used which has been mentioned on the OSGi Wiki for this kind of operation. Btw. if using the right API method of the WebContainer API this will be done automatically.
The best way of using this feature will be handled in another blog post.
Better support for Filters
This has been one of the most nagging things in the past. Due to the fact that till Pax Web 4.0 the welcome files are handled via a specialized filter, this filter also blocked handling other filters on the “/”-path of an application. This has been removed! With Pax Web 4.0 the welcome files are handled directly and not through a Filter.
Support of Web-Fragments
Maybe it should have been already possible with Pax Web 3, since version three is meant to be compatible to Servlet API in version 3 also. Though somehow this part slipped through and is one of the new major benefits of Pax Web 4.
Beware a Web-Fragment is something different then a OSGi-fragment. Both are supported by Pax Web.
This is the point the Pax Web team (or better I) needs help:
- Test, test and some more tests:
Only if people start using this version and do give feedback the version can be of a real benefit for all.
Right now this is pretty much a one man show here, every now and then I do get some patches, but the number of those should improve
That is a good question, if you take a look at the roadmap for 4.1, there are already some ideas. Some of those are more improvements – like some issues for Tomcat – and some other new ideas or dependency upgrades.
I fear the release of Pax Web 4.0 will take much longer then planned. This is mostly due to the fact that the time I’m able to spent on it, isn’t enough to implement all new features or improvements.