This release is significant for web as it moves off the AS 5 development branch and now supports Servlet 3.0. As I have listed in the previous entries on JBoss Web 3, there is more than simply this new API that has been added.
One of the main refactorings has been around the integration of the JSP container. Although not the most trendy EE technology, JSP is still used in many applications, and its integration was a big issue. The main difficulty is that tag library descriptors (TLD) processing is serious business (possibly the most convoluted item in the entire EE, actually), where Jasper (the JSP container in Tomcat and JBoss Web) would end up doing its own parsing. Very hackish and fragile code too ... As the Servlet container also had to be aware of TLDs, this meant duplicating parsing. So a lot of work went into factoring this out of Jasper, and moving off all TLD processing to JBoss Metadata and AS deployers, and replacing Jasper's code with usage of metadata objects representing the TLDs. The end result is that, in addition to a massive speed improvement over AS 5 (for the first JSP compilation in a webapp), TLDs are now fully configurable using AS deployers. Pretty powerful.
Another work area has been around connectors, with the addition of async support in Servlet 3. Rather than adding a new code path to support it, I chose to simply take advantage of the HttpEvent API that was introduced in JBoss Web 2.1. Of course, there was a problem for the connectors which did not support events. So I separated the event functionality in two parts: the part that required polling and non blocking IO (which was not needed to implement Servlet 3's async), and the rest (suspend, resume and timeout, mostly). All connectors now have support for the later (with APR HTTP also supporting the former). Pretty painless overall. Except the dispatcher logic, but having it look like the other include and forward dispatchers seemed like a maintainable solution.
Last, lots of time went into supporting web.xml modularity, Servlet container initializers, and all the annotation scanning (injections and the new Servlet 3 features). That means lots of scanning. Although this is convenient for developers and library packagers, this also causes a war deployment time impact. To address that, the war deployers support scanning exclusions. Large legacy webapps can be tagged with a jboss-scanning.xml and/or started on demand. We did that for our own admin-console. This can allow keeping war deployment time in line with the web container in AS 5, although as users will need to do some homework (given the default is to be EE compliant), some will see apparent regressions here.
A lot of work remains for AS M3 and beyond, including extracting a JBoss Web standalone packaging which makes sense in terms of size and feature set.
For the general AS 6.0.0 M2 release announcement, see Brian's blog entry.
Subscribe to:
Post Comments (Atom)
3 comments:
Hi, is there something particular to configure to enable async support (I have the APR native library 1.1.17).
I have defined a servlet with async-supported and request.isAsyncSupported() is always false when the servlet is called.
Note that the same servlet works fine on GlassFish v3.
Forget it, seems there is a Weld filter breaking async somewhere.
Yes, the whole execution stack has to support async for it to work. It is possible some frameworks will need updates to be usable with it. And async also works with the java.io HTTP connector.
Post a Comment