Arjan Tijms' Weblog

A while ago we wrote about CDIs ability to dynamically add Bean<T> instances to the CDI runtime. A Bean<T> is a kind of factory for beans, that makes types available for injection, lookup via the bean manager , or by referencing them in expression language. CDI producers (via the @Produces annotation) fulfil a somewhat similar role, but they essentially only make the "create instance" method dynamic; the rest (like scope, types, etc) is more or less static. A programmatically added Bean<T> essentially makes all those aspects dynamic. As the previous article showed, dynamically adding such Bean<T> is a bit more work and it's quite verbose, as well as a little complex as the developer has to find out what to return as a default for various methods that are not directly of interest. CDI 2.0 has addressed some of the above issues by providing a very convenient builder that not only makes creating a Bean<T> instance far less verbose, bu...

JSF aka JavaServer Faces is a component based MVC framework that's part of Java EE and is one of the oldest Java MVC frameworks that's still supported and actively used (version 1.0 was released in 2004 ). Over time, Java EE itself has grown considerably and as such the resources required to maintain and evolve Java EE have grown as well. Now Oracle has indicated at several occasions that it just doesn't have the resources required for this, and for most constituent specs of Java EE it can do at most small updates, but in other cases can't do any updates at all. In order to lessen this immense burden on Oracle somewhat, the community has largely taken over for JSF 2.3 and Java EE Security API 1.0. The following graph (taken from a presentation by JSF spec lead Ed Burns) gives an indication: The question is how to continue for JSF.next ? Since the community has largely taken over JSF already, should this perhaps be made more formal by actually letting the ...

The proposed final draft (PDF) of the Servlet 4.0 spec has just been made available at GitHub . The major new feature is HTTP/2 support and specifically the push support that comes with it. Java EE already has support for push via WebSockets (including WebSocket support in JSF 2.3 ), but there are other interesting changes as well, such as for instance the Mapping Discovery API . The following contains a terse list of changes, taken from section A.1 of the above linked Servlet 4.0 PFD document. All mentioned references to sections are to that document. Requirement to support HTTP/2, see Section 1.2, “What is a Servlet Container?” on page 1-1 and “What is a Servlet?” on page 1 1. This includes HTTP/2 server push, see “HTTP/2 Server Push” on page 3 29. Modify javadoc for ServletContext getAttribute() and getInitParameter(), specify that NullPointerException must be thrown if the argument “name” is null. Modify javadoc for ServletContext.setAttribute() and setInitParameter() to...

After a long and at times intense spec and development process the JSF 2.3 EG is proud to announce that today we've released JSF 2.3 . JSF (JavaServer Faces), is a component based MVC framework that's part of Java EE. JSF 2.3 in particular is part of Java EE 8. Major new features in JSF 2.3 are a tighter integration with CDI, support for WebSockets, a really cool component search expression framework (donated by PrimeFaces ), basic support for extensionless URLs, and class level bean validation. The age old native managed beans of JSF 2.3 have finally been deprecated (although they are still available for now) in favour of CDI. It's expected that these will be fully removed (pruned) in a future release. The JSF 2.3 EG would like to thank everyone who contributed to JSF in whatever way, by creating bug reports, testing builds, providing comments and insights on the mailinglist and contributing code. Without those community contributions JSF 2.3 would not have been...

In the beginning and middle of this year we looked at how well modern Java EE servers supported portable authentication (JASPIC) in Java EE. As the end of 2016 approaches we take a third look to see how things are progressing. Since our last time new versions of all servers have been released. Payara went from 163-beta to 164, WildFly went from 10.0 to 10.1, Liberty beta went from 2016-5 to 2016-11, WebLogic went from 12.2.1 to 12.2.1.2 and TomEE went from 7.0 to 7.0.2. We also added a new server, namely Tomcat. Tomcat was indirectly already tested via TomEE, but given the importance of standalone Tomcat we decided to put this one in explicitly. Do note that Tomcat is not a full or web profile Java EE server, so the integration tests for technologies it doesn't support (like JSF, CDI, etc) are simply omitted. Tests were added for request.authenticate , an injected CDI request , the servlet path after a forward , isMandatory in a SAM , and finally for a SAM request to be seen ...

Last month we presented a way how a Java EE application can provide custom rules for authorization . The code shown in that article was developed and tested using Payara . We're now going to look at how the code can be used on some other servers, starting with IBM's Liberty. Liberty has a highly modularised architecture and features a rather amazing way by which and end user can compose the runtime. By means of its server.xml file, a Liberty user can add or remove nearly every individual feature that Liberty has independently. The Liberty core system keeps track of the dependencies of each module representing such feature and adds or removes its dependencies accordingly (in a way not quite unlike what a tool like Maven does at build time). All this power does come at some price. For Liberty the JACC provider which is needed to implement the logic behind the custom authorization rules has to be turned into a Liberty specific module (called a user feature), which is quite a...

In a previous article we looked at implementing a Java EE authorization module using the JACC specification. This module implemented the default authorization rules as specified by the JACC-, Servlet- and EJB specifications. In this article we go beyond that default algorithm and take a look at providing our own custom authorization rules. In order to implement custom rules, one would traditionally ship an entire JACC provider with factory, configuration and policy. Not only is this a lot of code (JACC doesn't have any code that can be reused, for the smallest change everything needs to be implemented from scratch) , it's also problematic that a JACC provider is global for the entire application server, while authorization rules are almost always specific for an individual application. Even when you adhere to the best practice of using one application per server , it's still quite a hassle to re-install the JACC provider after every little change separately from the app...