Monday, May 7, 2018

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 EE
  • Servlet containers
  • APIs related to Java EE
  • The 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 what's important to the community.

It must be noted that OmniFaces is a JSF utility library, so the public we attract is naturally more interested in JSF than the primary public of the many parallel surveys that were going on. We did track where the respondents originated from, and 344 of them took the survey directly on the website.

It must also be disclosed that one of the OmniFaces members (the writer, Arjan), works for Payara. Payara however was in no way involved with either the creation of the survey or the report. Payara did tweet about the survey a couple of times.

Let's take a look at the outcome now.


Question 1 - Which versions of Java EE have you (historically) used?

This question was about which version of Java EE people have ever used, and hopefully will give us some idea of how much experience our audience has and how long they've been using Java EE.

It appears though that most of our respondents haven't used the older versions so much. Far less than half of the respondents has ever used Java EE 5. On the other hand, there's still a relatively big proportion of respondents that have used the precursor technologies of Java EE (the ones older than J2EE 1.2).

< J2EE 1.2 J2EE 1.2 J2EE 1.3 J2EE 1.4 Java EE 5 Java EE 6 Java EE 7 Java EE 8 0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 5% 10% 12% 23% 38% 63% 81% 34%


Question 2 - Which versions of Java EE have you recently (last couple of months) used?

Looking at what people have recently been working on we see that J2EE 1.3 and J2EE 1.4 is almost non-existent. The response for those is well within the error margin. There's still a number of people working on Java EE 5 applications though, which is now more than a decade old! Not surprisingly, most people are working with Java EE 7, for which all currently active vendors have a supported version out.

Maybe somewhat surprisingly is that 36% of the respondents are already using Java EE 8, given that not all vendors have a fully supported version out or have even implemented all Java EE 8 APIs yet. Of course, this can also mean respondents are using parts of Java EE 8. WildFly 12 for instance supports most Java EE 8 APIs, except for EE Security (which will come in WildFly 13).


Question 3 - Which application servers have you recently used?

Looking at which (Java EE) application servers are most frequently used there's a very clear winner, and that's RedHat's WildFly. More than half of the respondents have recently used this server. Trailing a good deal behind at the second place is Oracle's GlassFish. Despite being largely abandoned by Oracle and not supported, still 37% of responds use this. Payara Server and TomEE share the third place.

A slew of servers had so few respondents that taking the error margin into account qualifies them as practically unused by our respondents. This included Geronimo, the once promising server from Apache that silently and without any notice stopped, Resin, a very promising Web Profile implementation back then with its own CDI implementation (CanDI), which however never managed to get passed Java EE 6, and JOnAS, the mostly French server which had a number of its own unique component implementations as well, but like Geronimo just silently stopped at some point. Following is a number of mostly Korean, Japanese and Chinese servers. These servers are mostly used in their respective countries, and seemingly English language surveys are not (much) picked up by the users of these servers.


Question 4 - How would you rate the application servers that you've used?

For this question respondents could rate the servers they've used using 5 categories. There were two negative ones: "Hate it" and "Don't like it", a neutral one: "It does the job, but that's all", and two positive ones "Like it" and "Love it". The outcome has different aspects that we'll be looking at individually. Note that the servers that weren't effectively used by anyone are left out.

Love it

The first aspect we'll be looking at is a ranking of all servers that got the maximum appreciation: "Love it". Here we see Payara Server is the winner. Almost half of the people who used Payara said they loved it. At the second place we see WildFly again, where over a third of the respondents who use WildFly said they loved it. Do note that since WildFly is used much more than Payara Server, in absolute numbers more respondents from this survey loved WildFly. Statistics can be a tricky thing.

Quite interesting is that Liberty is relatively much loved and enters at the third place. Liberty is IBM's still relatively new server that does many things right compared to its older sibling WebSphere. Also interesting to see is the stark difference in love between Payara Server and GlassFish. Payara Server is directly based on GlassFish, but with many extra bug fixes and features.

Like it

In the "Like it" category we see WildFly and JBoss EAP topping the chart. Note that these too are largely the same server, with JBoss EAP essentially a kind of "LTS" of a specific WildFly version with the option to get a support subscription and extra bug fixes. With the exception of WebLogic and WebSphere, the servers are quite close together in this category.

Hate it

Skipping the neutral and dislike categories (they'll be included in the final score though), let's take a look at the hate category. Overal we see that there's relatively little hate among the respondents. Liberty, JBoss EAP, TomEE, GlassFish, Payara Server and WildFly all have very small percentages of hate. The only real exception is WebSphere here, and to a lesser degree WebLogic. In the case of WebSphere, it's perhaps not a surprise. Only its installer is already larger than many complete servers (around the 100MB), and it downloads in excess of 2GB of "stuff". Even in 2018 that's still excessive. After that an actual server needs to be created taking another 200MB or so. This and a number of other issues (e.g. not being able to run on macOS) doesn't make it much popular. Of course IBM recognised this long ago, and all new development is on Liberty, which is essentially everything that WebSphere is not.

Total score

For the total score we used a weighted sum, with the weights (factors) being -3 for "Hate it", -2 for "Don't like it", 1 for "It does the job, but that's all", 2 for "Like it" and 3 for "Love it". For this total score we see Payara Server still wins, but now it's only a small margin with WildFly, which is very close. This seems mainly attributed to WildFly having many more points in the "Like it" category. In the next group we see Liberty, TomEE, JBoss EAP and GlassFish all scoring quite close to each other. All the way at bottom we find WebLogic and WebSphere. WebLogic just about manages to get a positive score, but WebSphere's is deeply negative.


Question 5 - Which Java EE APIs have you used recently?

When looking at the Java EE APIs that people use most, JPA is the overal winner. This is interesting, since in recent years efforts for the JPA spec have been minimised, even to the point that one not rarely hears that JPA is "done" and people have moved on to e.g. MongoDB. Looking at the outcome of this survey this doesn't seem to be exactly the case. CDI follows close and lands at the second place. This is probably no surprise, as since its inception in 2009 CDI has rapidly increased in performance and is now for many cases the default type of bean to use.

Initially somewhat surprising is JSF scoring so high here, and landing just above JAX-RS at the 3rd place. This is surprising since there's a quite vocal community out there proclaiming the era of server side rendering frameworks has come to an end, and the future belongs to the client. For obvious reasons we at OmniFaces don't fully agree with that, but we're also not entirely blind to the fact that the client has indeed taken a large bite out of the total web framework market. As mentioned in the beginning of this article, OmniFaces is a JSF utility library, so our audience likely has a more than average amount of JSF users among it.

Truly surprising though is the high score of EJB, which is often cited as having its name tainted by the complexities of EJB 2 and never quite recovered. Even though EJB 3 is very usable, in Java EE 7 and above CDI can be used instead for quite a lot of cases. It could of course be that EJB is only used for a few small things such as its timer service, but this would need more research and possibly a follow-up survey to really get clear.

Java EE Security, a new spec in Java EE 8, is already used by 24% of the respondents. Given its young age this is quite a good outcome. JASPIC and JACC are both at the very bottom, but these APIs (SPIs actually) are not really aimed at application developers. They are used by higher level frameworks and vendors, e.g. the Java EE Security API strongly builds on JASPIC and will likely build more on JACC in a future release. So these APIs are being used, but just not directly by application developers. A somewhat similar thing also holds for JTA, which is mostly used under the covers by JPA and EJB, but is effectively used directly with the relatively new @Transactional and @TransactionScoped annotations.


Question 6 - Have you used a (standalone) Servlet container recently?

A standalone Servlet container is a server that supports at least the Servlet spec, and typically a number of strongly related specs such as the Servlet Container Profile of JASPIC (not full JASPIC), Expression Language, JNDI, JSP and WebSocket.

As it appears, about the half of the respondents have used such Servlet container, while the other half hasn't (and thus only used a full or web profile Java EE server).


Question 7 - Which Servlet containers have you used recently?

From the people who have used a Servlet container, the overwhelming majority used at least Tomcat. At 85% Tomcat largely dominates this segment. Still, 29% and 22% for Jetty and Undertow are nothing to sneeze at either, and seemingly a non-trivial amount of respondents use either Jetty or Undertow next to Tomcat (people could choose multiple servers).

Undertow's 22% is particularly impressive, as Undertow is not so much known as a standalone Servlet container but more as the Servlet container that Jboss EAP/WildFly uses. It's also relatively new, especially when compared to Tomcat and Jetty which both have existed since the dawn of times.

The "other" category was perhaps not entirely understood, as most respondents choosing this entered products that actually weren't standalone Servlet containers. WebLogic, GlassFish, Liberty and Payara certainly aren't. Grizzly and Netty come closer, but they actually are more akin to HTTP engines, and are themselves not Servlet compatible.



Question 8 - Which additional Java EE libraries do you use with your Servlet container?

This question asked specifically about the Java EE libraries that people add to their Servlet containers. Java EE libraries here means an implementation of a Java EE spec, such as JPA and CDI, but not e.g. Guave, Spring, etc.

Consistent with the API usage outcome, JPA is added most often to a standalone Servlet container, followed by JSF, JAX-RS, Bean Validation and CDI. In this particular question though it was asked which exact implementation people add. As can be seen Hibernate wins hands down over EclipseLink (25%) and OpenJPA (7%). Likewise Mojarra (46%) wins over MyFaces (15%) and Jersey (45%) wins over RESTEasy (28%) and CFX (17%).

The EE Security API has only one standalone implementation yet, which is Soteria (there's another implementation by IBM, but it's embedded in Liberty and not suitable for standalone use). This one is quite new and only used by a couple of people, but it's nevertheless interesting that it is being used standalone.

The "Other" category wasn't entirely understood however. The idea was for other implementations of Java EE specs to be listed here, like e.g. Wink for JAX-RS, HornetQ, OpenMQ or JORAM for JMS, Narayana or JOTM for JTA, etc. None of these were mentioned though, and instead PrimeFaces, OmniFaces, DeltaSpike and Spring were mentioned, which aren't implementations of Java EE specs. Here it's probably the wording of the survey question that's to blame. One respondent did mention DataNucleus though, which is a JPA implementation, and suggested that the question is biased against it by not mentioning it. Given the importance of JPA this is indeed true, so we'll make sure to include DataNucleus next year.



Question 9 - Have you used MicroProfile APIs recently?

MicroProfile is an industry effort to bring extra APIs into the EE fold for things which Java EE doesn't have an API now, such as configuration and metrics. At the same time MicroProfile is also a profile like WebProfile, where only those extra APIs are included as well as JAX-RS and CDI.

Despite all Java EE vendors, with the exception of Oracle, offering those extra APIs with their products, and some implementations being able to be used standalone as well, usage among the respondents was quite low. Only a little more over 15% said to have used MicroProfile APIs recently.

This may have to do with all of those APIs being still very young and haven't established themselves yet. Another reason could be that most vendors by default promote MicroProfile as its own isolated product and not as an extra set of APIs to be used together with the main Java EE ones (Payara is the only notable exception here). As most people would use for example the regular WildFly server (as opposed to the spin-off product WildFly Swarm), which doesn't have the MicroProfile APIs out of the box, this could be a potential barrier.


Question 10 - Which MicroProfile products have you used recently?

Looking at which server product those relatively few people that use MicroProfile APIs use it's again WildFly that tops the charts here, with more than 50% of respondents using this variation of the WildFly main server. Payara Micro follows closely with 45%. Compared to the (Java EE) server product the gap between WildFly and Payara is much smaller here. Payara also has all the MicroProfile APIs included out of the box with the EE Server product, and in this variation Liberty and Payara are used exactly as much. There are various other MicroProfile products, but they are not (yet) so popular (specifically when taking into account only a small proportion of respondents said to be using MicroProfile in the first place)

Seeing that Payara Micro is more used for MicroProfile APIs than Payara Server, one may come to the conclusion that the fact that most MicroProfile vendors don't support these APIs out of the box on their server product doesn't matter that much. While this may be true, it could also be that many users aren't quite aware Payara Server supports these APIs.


Question 11 - Which MicroProfile APIs have you used recently?

Config was the first MicroProfile API and arguably one of the APIs that's most missed in Java EE. A Java EE Configuration API was in the works, but it never materialised. It's perhaps no surprise that config is thus the most used API from the MicroProfile. Health, Metrics and JWT Authentication follow with some distance. Open API, Open Tracing and the Type-safe rest client are all quite new and haven't been implemented by all vendors yet, so it's not a big surprise these aren't used that much yet.


Question 12 - Which Java EE specific extension libraries have you used recently?

This question was specifically about Java EE extension libraries, meaning libraries that one can only use with Java EE. This mostly means libraries that extend or are plug-ins for JSF, CDI, JCA, etc. PrimeFaces is the clear winner here, followed with some distance by OmniFaces (but keep the bias in account, since the survey was promoted via the OmniFaces account and website). Given the popularity that Seam once had, and DeltaSpike being its spiritual successor, just over 20% feels a bit on the low side. DeltaSpike is certainly worth looking at though. Once one of the most frequently used JSF component libraries, RichFaces after being sunset by Red Hat has been reduced to only 13% usage, while newcomer BootsFaces has climbed up to that same percentage.

As far as the "Other" response goes, "MyFaces" was mentioned a lot, but this of course isn't a Java EE Extension library, but a Java EE Implementation library (it implements JSF, as mentioned in a previous question). Tobago, ButterFaces, IceFaces and PrettyFaces are indeed all Java EE extension libraries. Oracle ADF is too, although this is a somewhat specific one (it practically only really works on WebLogic). It's a question if one can really count Spring as a Java EE extension framework. Technically it is, but at the same time it mostly positions itself as an independent full stack framework.

So again, for next year we could do with an explicit definition of "Java EE specific extension library".



Question 13 - Which APIs would you most like to see updated in the next version of Java EE (Jakarta EE)?

When asked which API (spec) people like to see updated, a natural instinct might be to say "all of them". Perhaps not including the ones they hate, or maybe even those so that they can be hated a little less. With only a finite amount of resources this is not always an option, so that's why this question specifically asks respondents to rank the available APIs.

We take a look at the results in three different ways; the amount of people who put an API on the number one position, the amount of people who put an API on the number two position, and finally the total weighted score per API.

APIs at number 1 of the ranking

As can be seen none of the APIs had a really absolute majority. The highest score here was JSF with just over 20%. The question is, did JSF score so (relatively) high here because the potential bias, or do many people see JSF as something that has potential but *really* could do with some desperately needed improvements? CDI and JPA are high on this list too, which matches the outcome of which APIs people use most. Java EE Security is somewhat of an outlier. Being a new spec in Java EE 8 it isn't used that much yet, but already people want to see it improved. As a side-note, Java EE Security 1.0 could only address some of the basics (the low hanging fruit). More was planned for 1.0, but a lack of resources prevented many of those other planned things (such as security interceptors, evens and custom authorization rules) to be actually included.

APIs at number 2 of the ranking

In the number 2 list we see some more variety in the category of APIs having more than 2% of the respondents choosing them, although we do largely see the same APIs again in the top tier. CDI now takes the lead, moving up one place from the number 1 list, and JAX-RS moves up 3 places. JPA is again at number 3, while JSF is at 4 now.

Total score

When we take a look at the total score, we see that the top tier is formed of JPA, CDI and JAX-RS, which is basically identical to the top tier of question 5, which asked what APIs people have used recently. Clearly, people like to see APIs that they actually use improve. In the total score ranking too, EE Security is the exception. It lands on the 4th place, just an inch away from JAX-RS. Interestingly though, JASPIC and JACC end at the last places. As mentioned above, it's likely not common knowledge that these two APIs are the foundation of EE Security.

JavaMail and JDNI are both two examples of APIs that are used more than that people want to have them improved. Likely they just do the job (sending mails resp. looking up resources) and people don't see much need for further improvements there.


Question 14 - What do you think about these options to improve Java EE / Jakarta EE?

This question asked for a variety of broad, somewhat cross-cutting concerns to improve Java EE overall (the potentially improved Java EE will be called Jakarta EE then). The choices with their keys in the graph were:

  • CDI rebase - Rebase most Java EE APIs on CDI (remove JSF @ManagedBeans, remove JAX-RS @Context, ...)
  • Remove deprecated - Aggressively remove everything that is already @Deprecated (e.g. getServlet() in ServletContext)
  • Deprecate legacy - Aggressively deprecate and remove legacy features (e.g. JSP support in JSF)
  • Add MP APIs - Add equivalents of some or all MicroProfile APIs to Java EE (e.g. Config, JWT, ...)
  • Deployment models - Officially add alternative deployment models (Uberjar, run .war from command line, etc)
  • Add JCache - Add JCache to Java EE so that both applications and internal components (such as JPA) can use it
  • Rebase on Concurrency - Rebase most Java EE APIs that use threading to use Concurrency Utils thread pools
  • Cloud connectors - Add more connectors to cloud services (e.g. Amazon SQS, MQTT, Apache Kafka)
  • Security connectors - Add more connectors to security services (e.g. OAuth2, SAML, OpenID, Yubikey)

We'll be looking at two graphs for this one; the one which shows the options for which respondents choose "Please do this!", and the one with the weighted outcome (using the same weights as in question 4).

Please do this!

Of all the options presented, rebasing most Java EE APIs on CDI is the one that most people really want to see. It's followed closely by more security connectors (authentication mechanisms). Clearly the ones that currently ship by default with Java EE, namely FORM (+ custom form), BASIC, DIGEST and CERT aren't enough anymore. MicroProfile recognised this too and therefor added a JWT authentication mechanism as one of the initial new APIs.

Weighted score

When looking at the weighted score, we see that all options presented have community support. Security connectors though have the most support, followed with some distance by adding JCache. Rebasing on CDI and Concurrency Utils, which could indirectly be taken as a wish to have a better integrated platform, has much support as well. At the bottom of the graph we see "Remove deprecated" and "Deprecate legacy". Seemingly people support removing some of the cruft that's in Java EE, but they are not overly concerned about this.

It's interesting to see that the alternative "Deployment models", which according to some vocal voices is *the* reason Java EE has been losing ground (the AS model is allegedly outdated), doesn't bother our respondents that much either. A reason is perhaps that with popular tools such as docker it doesn't matter so much whether you put an AS in it, or an uberjar. The AS might be known outside Java EE as a super large monolith, but actual Java EE users probably know that a modern AS is ~70 to 100mb and starts between 1 and about 3 seconds, while an uberjar can easily be around that same size too and starts in about the same time as well.


Question 15 - Do you have any final comments on how Java EE / Jakarta EE can be improved in the future?

The final question was a fully open question where people could comment whatever they wanted. 179 respondents left a comment, which is about 16% of the total number of respondents. Overal the quality of the comments was quite good. We'll provide a few of them here:

"Take good care of it, don't leave legacy behind. But still move it forward. by all means remove already deprecated stuff. I feel things can often be don the old and the new way.. And the support forums are full of good recomendations on both old and new. And it's sometimes confusing not being an expert."

"Please, single set of bean annotations. Not mixture of CDI, EJB and JSF"

"Externalize configuration for both AS domain and the app for all configurable properties. - All AS settings must be configurable via command line."

"Make it easier to have something between a full application server and just a few features (i.e. I only need JSF, JAX-WS, JavaMail, and DB, but not JPA and EJB, etc.) so they don't have to be manually added in the app or grafted into the servlet container in some non-standard way. Also, I'd prefer to be able to easily choose which technologies (JSF: Mojarra vs MyFaces, JAX-WS: Metro vs Apache CXF, etc.). Just a general thing to watch out for: Don't assume all users will want to use Maven; be sure you provide another way to download."

Tag cloud

Thursday, March 15, 2018

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 EE
  • Servlet containers
  • APIs related to Java EE
  • The 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

Wednesday, March 7, 2018

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:

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

Wednesday, August 23, 2017

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:



This will cause the container to enable a build-in bean with interface type HttpAuthenticationMechanism, but having an unknown (vendor specific) implementation.

Next we'll definite an alternative for this bean via a CDI producer:

public class ApplicationInit {
    public HttpAuthenticationMechanism produce(InterceptionFactory<HttpAuthenticationMechanismWrapper> interceptionFactory, BeanManager beanManager) {
        return ...
Note that perhaps somewhat counter intuitively the @Alternative annotation is put on the bean hosting the producer method, not on the producer method itself.

A small challenge here is to obtain the bean with type HttpAuthenticationMechanism that would have been chosen by the CDI runtime had our producer not been there. For a decorator this is easy as CDI makes that exact bean injectable via the @Decorated qualifier. Here we'll have to do this manually. One way is to get all the beans of type HttpAuthenticationMechanism from the bean manager (this will include both alternatives and non-alternatives), filter ourselves from that set and then let the bean manager resolve the set to the one that would be chosen for injection. We then create a reference for that chosen bean.

The following shows this in code:

HttpAuthenticationMechanism mechanism =
                       .filter(e -> !e.getBeanClass().equals(ApplicationInit.class))


With createRef being defined as:

HttpAuthenticationMechanism createRef(Bean<?> bean, BeanManager beanManager) {
    return (HttpAuthenticationMechanism) 


We now have an instance to the bean to which we like to apply the interceptor binding. Unfortunately, there's a somewhat peculiar and very nasty note in the CDI spec regarding the method that creates a proxy with the required interceptor attached:

If the provided instance is an internal container construct (such as client proxy), non-portable behavior results.

Since the HttpAuthenticationMechanism is a client proxy (it's application scoped by spec definition) we have no choice but to introduce some extra ceremony here and that's by providing a wrapper ourselves. The interceptor will be applied to the wrapper then, and the wrapper will delegate to the actual HttpAuthenticationMechanism instance:


HttpAuthenticationMechanismWrapper wrapper = 
    new HttpAuthenticationMechanismWrapper(mechanism);


Having our HttpAuthenticationMechanism instance ready, we can now dynamically configure an annotation instance. Such instance can be created via CDI's provided AnnotationLiteral helper type:

    new RememberMeAnnotationLiteral(
        86400, "",       // cookieMaxAgeSeconds
        false, "",       // cookieSecureOnly
        true, "",        // cookieHttpOnly
        "JREMEMBERMEID", // cookieName
        true, ""         // isRememberMe


Finally, we create the above mentioned new proxy with the configured interceptor binding applied to it using the interception factory's createInterceptedInstance method and return this from our producer method:

return interceptionFactory.createInterceptedInstance(
    new HttpAuthenticationMechanismWrapper(wrapper));


A full example can be found in the Java EE 8 samples project.

Note that there's a small caveat here; if the Interceptor needs access to the interceptor bindings (which is almost always the case when the binding has attributes), you can't just inspect the target type as one would usually do in CDI 1.2 and earlier code. The interceptor binding annotation is not physically present on the type. At the moment it's not entirely clear how to obtain these in a portable way. The interceptors in the Java EE Security RI (Soteria) uses an RI specific way for now.

The example was tested on Payara Server 5, of which a snapshot can be downloaded from the snapshot repository. An initial alpha will be released very soon, but in the mean time the latest version can be downloaded here:

Arjan Tijms

Thursday, August 17, 2017

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 long statements):

public class MappingInit implements ServletContextListener {
    public void contextInitialized(ServletContextEvent sce) {
        FacesContext context = FacesContext.getCurrentInstance();
           .filter(e -> e.getClassName().equals(FacesServlet.class.getName()))
               reg -> context.getApplication()
                             .getViews(context, "/", RETURN_AS_MINIMAL_IMPLICIT_OUTCOME)
                             .forEach(e -> reg.addMapping(e)));

What the above code does is finding the existing FacesServlet, then getting all views for the entire application in a form that happens to be exactly suitable for extensionless URLs, and then adding each of them as mapping to the FacesServlet we previously found.

After adding the above shown WebListener to an application, its view can be requested via URLs like, etc.

The example was tested on Payara Server 5, of which a snapshot can be downloaded from the snapshot repository. An initial alpha will be released very soon, but in the mean time the latest version can be downloaded here:

Arjan Tijms

Tuesday, August 15, 2017

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 also takes away most of the guesswork. The following shows an example:

public class CdiExtension implements Extension {

    public void afterBean(final @Observes AfterBeanDiscovery afterBeanDiscovery) {
            .id("Created by " + CdiExtension.class)
            .createWith(e -> new MyBeanImpl("Hi!"));

The above makes a bean available for injection into MyBean injection points and with the @ApplicationScoped scope, backed by a MyBeanImpl class.

A fully working example is provided in the Java EE 8 Samples project.

The example was tested on Payara Server 5, of which a snapshot can be downloaded from the snapshot repository. An initial alpha will be released very soon, but in the mean time the latest version can be downloaded here:

Arjan Tijms

Tuesday, June 13, 2017

Should the community take over or not?

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

Since the community has largely taken over JSF already, should this perhaps be made more formal by actually letting the community (individual, foundation, or even representative small company) take the lead in developing the next version of JSF? In such scenario, the existing JSF versions (2.3 and before) and their respective TCKs would stay with Oracle, but (i.e. JSF 2.4 or 3.0) would be fully specified, implemented and released by the community (OmniFaces in particular, with possibly the help of others).

Is a large and important spec such as JSF better off at a large and responsible, albeit resource constrained, organisation such as Oracle, or do you want OmniFaces to take over the spec lead role? If you want, you can cast a vote in the poll below or leave a comment:

Do you want OmniFaces to take over the JSF spec lead role?