Posts

Java EE Survey 2018 - results

At OmniFaces we poll the community from time to time about Java EE and related technologies. With all the changes that are about to happen with the move of Java EE to Eclipse and the subsequent renaming to Jakarta EE, we expanded the survey a little for this year. In the 2018 edition, there were 4 categories of questions: Current usage of Java EEServlet containersAPIs related to Java EEThe future of Java EE / Jakarta EE Jakarta EE provides the opportunity to revitalise and modernise Java EE, but in order to do that it's more important than ever that we know what matters to all of its users out there. We started the survey the 15th of March, 2018. Unfortunately a small barrage of other surveys would soon follow, among others the Eclipse Jakarta EE Survey, the Jakarta EE Logo selection, and the Baeldung survey. Despite all those other surveys going on at the same time we still managed to get 1054 respondents. Not as much as we hoped for, but still enough to have some idea of wh…

Java EE Survey 2018

At OmniFaces we poll the community from time to time about Java EE and related technologies. With all the changes that are about to happen with the move of Java EE to Eclipse and the subsequent renaming to Jakarta EE, we expanded the survey a little for this year. In the 2018 edition, there are 4 categories of questions: Current usage of Java EEServlet containersAPIs related to Java EEThe future of Java EE / Jakarta EE Jakarta EE provides the opportunity to revitalise and modernise Java EE, but in order to do that it's more important than ever that we know what matters to all of its users out there. So therefor we'd like to invite all Java EE users to participate in The Java EE Survey 2018 Update: Survey now closed

Payara 5 RC1 available for testing

We are happy to announce that Payara 5 release candidate 1 is now available for download. Payara 5 is the first release that will include all of the Java EE 8 and MicroProfile 1.2 components, including a special build of Mojarra (JSF 2.3) based on the 2.4 master in which a lot of refactoring has been done, and a special build of Soteria (Java EE Security) based on the 1.1 master with several bug fixes. The full list of changes are available from the links given below: Changes in Payara 5 RC 1Changes in Payara 5 Beta 2Changes in Payara 5 Beta 1Changes in Payara 5 Alpha 3Changes in Payara 5 Alpha 2Changes in Payara 5 Alpha 1 Payara 5 runs all the Java EE 7 samples, all the Java EE 8 samples and all of the MicroProfile 1.2 samples. If no major bugs surface Payara 5 Final should be released soon. Arjan Tijms

Dynamically adding an interceptor to a build-in CDI bean

In Java EE's CDI, beans can be augmented via 2 artefacts; Decorators and Interceptors. Decorators are typically owned by the application code and can decorate a bean that's shipped by the container (build-in beans) or a library. Interceptors are typically shipped by a library and can be applied (bound) to a bean that's owned by the application. So how do you bind a library shipped interceptor to a library shipped/build-in bean? In CDI 1.2 and before this wasn't really possible, but in CDI 2.0 we can take advantage of the new InterceptionFactory to do just this. It's not entirely trivial yet, but it's doable. In this article we'll demonstrate how to apply the @RememberMe interceptor binding from the new Java EE 8 Security spec to a build-in bean of type HttpAuthenticationMechanism, which is from the Security spec as well. First we configure our authentication mechanism by means of the following annotation: @BasicAuthenticationMechanismDefinition( …

Extensionless URLs with JSF 2.3

An extensionless URL is a URL without a final suffix like .xhtml, .html, .jsp, etc. Such a suffix is seen as technical "clutter" that's hard to remember for humans. Servers often need it though to route a request to the right controller. JSF, a Java EE MVC framework, has supported extensionless URLs for some time via PrettyFaces (now merged to the general Rewrite framework) and OmniFaces. Both of these solutions used various workarounds to trick JSF into working with extensionless URLs. Though JSF 2.3 does, unfortunately, still not support extensionless URLs fully out of the box via e.g. a single parameter, it can provide support for it by basically combining the new support for exact mapping and the API for obtaining a list of all view resources. Additionally combining this with the Servlet 3.1 feature for dynamically adding Servlet mappings and some JDK8 streaming and lambdas, makes it possible to enable extensionless support with just 2 statements (albeit somewhat…

Dynamic beans in CDI 2.0

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, but als…

Should the community take over JSF.next or not?

Image
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 communit…