Eclipse 4.5 SR2 released!

26 February 2016

Another year, another SR release; the Eclipse organization released maintenance release two of Eclipse 4.5 (aka, MARS.2, aka Eclipse 4.5.2) today.

The release has been done with little fanfare. There’s no notion of this event anywhere on the homepage. On the top of the page at the moment of writing is the Eclipse Foundation + Google Summer of Code and the fact that the EclipseCon 2016 starts March 7. The actual IDE that is Eclipse is not mentioned. Main releases typically are, but SR releases aren’t, or at least not right away. Last year we saw the event being put on the homepage after about 5 days.

As it appears, there were 95 bugs fixed for this release in the core of Eclipse.

Among others a somewhat older but high profile OS X bug is fixed involving a nasty NPE and an obscure one where Eclipse would actually delete code.

Furthermore the usual assortment of totally weird bugs where fixed, the ones even the most experienced developers have hardly any idea about what they could mean. Stuff like ClassCastException in Theme$1.propertyChange.

This time around the good people from the WTP project did not feel like posting about the SR2 event on their homepage. Fiddling with the handy bugzilla URLs revealed a list of 22 bugs that are likely to be fixed in WTP 3.7.2, the version that should be the one that’s bundled with Eclipse 4.5.2.

Among the highlights of bugs that WTP 3.7.2 fixed is a fix for the fact the pom.xml did not match a Most other fixes focused on solving null pointer exceptions. No less than 9 different ones of these were solved, including the dreaded NullPointerException in ParameterGuesser$VariableCollector.collect. Interesting to note is that all of these were reported via the automated error reporting that was introduced with Eclipse 4.5. Next to null pointer exceptions, a couple of array index out of bounds exceptions where fixed as well.

Following the trend, community reporting is even lower than last year. This year there’s really no reporting at all. But it has only been released today, so maybe a few outlets will pick it up in the following days.

It remains a fact, year after year, that SR releases apparently aren’t that exciting. But the lack of announcements about them and the silent releases of what should really be one of the most important products that the Eclipse organization delivers remains a curious thing.

Luckily the milestones for the next Eclipse, code named Neon (4.6), do get some more attention.

Hitachi Cosminexus v10 silently certified for Java EE 7

28 April 2015

Every time after a Java EE spec is released it’s somewhat of a battle of who is the first to certify for that new specification.

GlassFish is always the first (by definition, as required by the JCP rules for a RI implementation), with tech previews/community editions of JEUS and JBoss following suit. These are however not (directly) supported for production by their own vendors.

During the Java EE 6 cycle, IBM was the first to come out with a supported and certified server, namely WebSphere 8.0. For the Java EE 7 cycle, the battle seemed to be between IBM and Oracle. Both of them are expected to release a Java EE 7 server soon. People are eagerly awaiting this, as Java EE 7 brings many improvements.

Surprisingly it’s the relatively unknown HITACHI Cosminexus Application Server that was completely silently (in Western outlets, that is) added to Oracle’s certification page. HITACHI themselves do mention this fact on their homepage, but otherwise there hasn’t been much news about this.

It appears that HITACHI is focusing exclusively on the Japanese market, but still this may be an interesting server to check out.

Arjan Tijms

First official JSF 2.3 contribution from

27 January 2015

A while back we joined the JSF 2.3 EG as While we had contributed as individuals before (mostly via code suggestions and snippets in JIRA issues) we are proud that today our first more direct contribution was committed to Mojarra for the ongoing JSF 2.3 effort.

Co-spec lead Manfred Riem tweeted about this earlier today:

The commit in question can be seen in our GitHub mirror. To summarize the change; before it was only possible to inject the application map as follows:

Map applicationMap;

As can be seen, the map is missing its generic parameters. This is of course far from ideal. With the latest patch, this map can now be injected as it should be:

Map<String, Object> applicationMap;

Injection into a raw map is still supported, but for most cases the generic variant should be preferred.

It’s a fairly small change, but hopefully many more of such changes will follow soon πŸ˜‰

Arjan Tijms

Follow JSF 2.3 development via GitHub mirror

17 January 2015

Currently development for JSF 2.3 is well underway in the trunk of the Mojarra project.

The Mojarra project still uses SVN, and only has the default web interface up and running. Specifically this means it’s not entirely easy to browse through the commits and see diffs, as this default web interface only offers a very bare bones browsing of the repository.

While there are of course web tools for SVN that show commits and diffs etc, simply importing the SVN repository into GitHub proved to be the easiest solution. So therefor we made a mirror available on GitHub:

This mirror is automatically updated every half an hour, so it should never be that far behind the SVN root repository. GitHub provides a number of extra features, such as feeds in atom format. Using that we can easily create widgets such as the one below that shows a near real-time overview of the 3 latest commits:

In addition to this mirror we’ve also published a fork of it, in which we made a few small changes that allows the Mojarra project to be used from Eclipse. This fork is at:

This fork will function as OmniFaces’ feature branch for code that we hope will be integrated into Mojarra and thus JSF 2.3 (which is of course subject to approval by the JSF spec leads and the other EG members).

For completeness, once checked-out, Mojarra can be build using the following steps:

Assuming SOURCE_HOME is the directory containing the source code:

  1. Copy to
  2. Edit and set to SOURCE_HOME
  3. Make sure JAVA_HOME is set and points to a JDK8 install
    e.g. on Ubuntu put JAVA_HOME=/opt/jdk8 in /etc/environment

  4. From SOURCE_HOME run (on the commandline) ant main clean main

The jsf-api.jar will be in SOURCE_HOME/jsf-api/build/lib and jsf-impl.jar will be in SOURCE_HOME/jsf-ri/build/lib.

When making changes from within Eclipse (use the OmniFaces fork for that):

  1. Make changes as needed in .java files, but note that the Eclipse compiled result in SOURCE_HOME/bin must be ignored
  2. From SOURCE_HOME run (on the command line) ant clean main

The jsf-api.jar will again be in SOURCE_HOME/jsf-api/build/lib and jsf-impl.jar will be in SOURCE_HOME/jsf-ri/build/lib.

Do note that the initial build command is ant main clean main, but all following builds happen via the command ant clean main. This is due to a circular dependency, that will likely be removed in the (near) feature if/when the entire project becomes a Maven project. Also note that when that happens, the Eclipse specific changes in the OmniFaces fork of Mojarra will not be needed anymore either.

Arjan Tijms

Mysterious Eclipse Luna update is SR1a

15 January 2015

Two days back I noticed Eclipse had a mysterious update available; Eclipse IDE for Java EE Developers, version with id “epp.package.jee”:


Of course there was no info on what this update was about and Googling for it yielded no results. Googling again for it today gave a single hit:

Looking at the URL revealed that “” is the alternative universe version for what’s otherwise known as “Luna SR1a”. Googling for the latter gave some more results, particularly the following one:

Eclipse Ships Luna SR1a Git Security Release

A bit out of character, but the Eclipse organization even linked to this from their homepage!

Why it’s so difficult for Eclipse to show a description for their updates is still a small mystery, but at least the mystery of what “” is about is now solved πŸ˜‰

Arjan Tijms

Mysterious new Java EE 6 server shows up at Oracle certification pages

31 October 2014

Oracle publishes a page listing all officially certified Java EE servers. The page has been known to list a couple of fairly obscure servers; servers that indeed exist but seemingly nobody has ever heard of (as partly proven by a diverse range of surveys).

Recently a new mysterious server just showed up on this page: InforSuite Standard Edition V9.1

It’s not entirely clear when this was exactly added, but as I visited the page a few weeks before I guess it must have been certified at most a couple of weeks ago. At the very least it was added after last May, as I copied the entire list of servers there for an article I was writing and it sure wasn’t there then.

As for the component listed, it’s unfortunately the usual inconsistent table (every entry has a different table with different terms). It mentions using EclipseLink (JPA), Weld (CDI) and Hibernate Validation (Bean Validation), as well as Oracle and Oracle, which probably means the Oracle reference implementations of JAX-WS (Metro core) and JAXB.

It’s interesting that this late in the Java EE 6 cycle, with Java EE 7 having been released a while ago and Java EE 8 preparations being in full swing, there are still brand new Java EE 6 servers coming out.

Arjan Tijms

Eclipse 4.4 SR1 once again completely silently released

29 September 2014

Another year, another SR1 release, another deafining amount of silence; the Eclipse organization released maintance release one of Eclipse 4.4 three days ago.

As usual, there’s no notion of this event anywhere on the homepage. What counts this time is the Eclipse Newsletter about Project Quality and the fact that LocationTech has announced the 2014 Tour. The actual IDE that is Eclipse doesn’t seem to be that important.

As it appears, there were 131 bugs fixed for this release in the core of Eclipse.

Among others a high profile bug is fixed where Eclipse generated a bad class file and another bug where JSR 45 support (JSP debugging among others) was completely broken.

Furthermore several bugs related to Java 8 were fixed. As Eclipse uses its own compiler (JDT), supporting new language features is always extra difficult for Eclipse as compared to other IDEs that just use javac.

Eclipse 4.4 SR1 fixed some nasty issues with lambda type inference (and another one), deserialization, bridge methods, and explicit null-annotations.

Unfortunately, even with the focus on Java 8 fixes, a very basic and known type inference bug is still in Eclipse 4.4.1, as found out by my co-worker Jan Beernink:


This time around even the good people from the WTP project did not feel like posting about the SR1 event on their homepage. Fiddling with the friendly bugzilla URLs revealed a list of 32 bugs that are likely to be fixed in WTP 3.6.1, the version that should be the one that’s bundled with Eclipse 4.4.1.

Among the highlights of bugs that WTP 3.6.1 fixed is a fix for that fact the JSF EL validation is too strict and that when using the famous “Run on Server” feature, a wrong URL mapping is used.

Following the trend, community reporting is even lower than last year. This year there’s virtually no reporting at all. There’s a lone post from an Eclipse vendor, and that seems to be it.

Unfortunately Eclipse 4.4.1 also introduced a major new bug, one that’s appears right away when you startup a completely clean freshly downloaded instance:

java.lang.ClassCastException: org.eclipse.osgi.internal.framework.EquinoxConfiguration$1 cannot be cast to java.lang.String
	at org.eclipse.m2e.logback.configuration.LogHelper.logJavaProperties(
	at org.eclipse.m2e.logback.configuration.LogPlugin.loadConfiguration(
	at org.eclipse.m2e.logback.configuration.LogPlugin.configureLogback(
	at org.eclipse.m2e.logback.configuration.LogPlugin.access$2(
	at org.eclipse.m2e.logback.configuration.LogPlugin$
	at java.util.TimerThread.mainLoop(

It seems clear that SR releases aren’t that exciting, but the complete lack of attention to them and the completely silent releases of what should be the most important product that the Eclipse organization delivers remains a curious thing.


Maybe after reading this article (who knows ;)), but a few days later the Eclipse organisation did finally post about the release event, and the following appeared on the homepage:

Eclipse Luna SR1 Now Available
The SR1 release of the Eclipse Luna release train is now available for download.

BalusC joins JSF 2.3 EG

12 September 2014

A few weeks ago joined the JCP:

Via, BalusC (Bauke Scholtz) applied this morning for membership of the JSF EG and was accepted later on the day by spec lead Ed Burns:

Bauke is well known for his many answers on StackOverflow, his blog and of course his work for the JSF utility library OmniFaces.

As members of the JSF 2.3 EG, Bauke and myself (I joined the JSF EG as well) will be looking among others at the possibility of bringing over things from OmniFaces into the JSF core spec and overall help out with taking JSF to the next level. What will eventually end up in JSF is of course subject to community feedback and EG negotiation and approval.

At any length, both Bauke and I are looking forward to working together with the other EG members and contributing to the JSF core spec πŸ™‚

Arjan Tijms

Eclipse Luna and JDK8

25 June 2014

Today marked the launch of Eclipse Luna, which is the first version of Eclipse which ships with Java 8 support built in. As we like to stay on the cutting edge here at ZEEF, I decided to give this new version of Eclipse a try straight away.

Unfortunately, I ran into a bug in the Java 8 support fairly quickly. Type inference in Luna seems to fail when the return type of a method needs to be inferred from a lambda within a lambda that has been used as a method parameter. For example, the following code snippet compiles normally using javac, but fails in Eclipse Luna:

        .flatMap(s -> s.chars().mapToObj(i -> Character.valueOf((char)i)))

Eclipse seems to infer that the return type of the “i -> Character.valueOf((char)i)” lambda is Object instead of Character, which leads to infer that the return type of flatMap() should be Stream<Object> instead of Stream<Character>. As the method reference used as the filter parameter, the compiler fails on this line as this method reference is not applicable for an argument of type Object.

Fortunately, it’s easy to work around this bug in Eclipse’s compiler. Any change to either the outer or inner lambda which makes the return type explicit allows Eclipse to correctly compile the code. Casting either the inner or the outer lambda to the correct type, assigning either to a variable or replacing either with a method reference allows Eclipse to correctly compile the code. For example, if you were to assign the inner lambda to a variable, you would end up with the following code:

    IntFunction<Character> characterFromInt = i -> Character.valueOf((char)i);
        .flatMap(s -> s.chars().mapToObj(characterFromInt))

The need to for such a workaround is unfortunate as improved type inference is one of the major enhancements in Java 8. Hopefully a fix for this issue will be available soon.

Experiences with migrating from JBoss AS 7 to WildFly 8.1

24 June 2014

This month the first major update of WildFly 8 (the base for a future JBoss EAP 7) was released; WildFly 8.1.0.Final.

I tried to get running on it, which currently runs on JBoss AS 7. is a relatively new Java EE 6 based web application that was started about a year ago. As such there is not yet that much legacy code present in it.

This article is about the issues I encountered during this initial migration.

In broad lines the issues fell into the following categories:

  • Tomcat/Undertow differences
  • Valves


The first issue I run into was a failed deployment. WildFly spitted out page upon page of unintelligible mumble jumble. Upon a closer look there was something about our datasource in the middle of all of this. Apparently WildFly was trying to tell me that the datasource couldn’t be found. For we define our datasource in application.xml (the Java EE standard way) and switch between stages uses a delegating switcheable datasource.

Moving the datasource definition to ejb-jar.xml solved the problem. Now WildFly 8.1 does support the definition of datasources in application.xml as demonstrated by this test (although a small workaround is needed). It might be an issue with loading the SwitchableXADataSource from the EAR level, but I didn’t investigate this further.


The next problem concerned an amount of issues related to JASPIC, the Java EE standard authentication API. JASPIC is an important but troublesome spec. It’s suspected that its TCK is very light, as (preview) implementations that don’t actually work (yet) have been certified.

The WildFly team however has done a fair amount of work to make sure its JASPIC implementation is reasonably correct, among others by using an external set of tests designed to verify that JASPIC does the most basic things right (like actually authenticating). Unfortunately one case slipped through, and that mainly concerned the behavior of HttpServletRequest#authenticate.

Specifically the following issues occured:

  • authenticate() does nothing and closes response (UNDERTOW-263)
  • authenticate() closes response when no authentication happened (UNDERTOW-259)
  • HttpServletRequest#logout doesn’t fully clear security context (WFLY-4602)
  • NullPointerExceptions right after request processing (WFLY-3514)
  • NullPointerExceptions for requests after a session is created (WFLY-3518

(update: UNDERTOW-259 and WFLY-3514 are fixed in WildFly 8.2, UNDERTOW-263, WFLY-4602 and WFLY-3518 are fixed in WildFly 9.0)

The first two issues could be worked around by installing an HttpServletRequestWrapper, e.g. via an Undertow Handler as follows:

public class JaspicHandler implements HttpHandler {
	private Field authenticationStateField; 
	private HttpHandler next;
	public JaspicHandler(HttpHandler next) { = next;
		try {
			authenticationStateField = SecurityContextImpl.class.getDeclaredField("authenticationState");
		} catch (NoSuchFieldException | SecurityException e) {
			throw new RuntimeException(e);
	public void handleRequest(final HttpServerExchange exchange) throws Exception {
		ServletRequestContext context =	exchange.getAttachment(ATTACHMENT_KEY);
		if (context != null) {
			ServletRequest request = context.getServletRequest();
			HttpServletRequestWrapper wrapper = new HttpServletRequestWrapper((HttpServletRequest) request) {
				public boolean authenticate(HttpServletResponse response) throws IOException, ServletException {
					if (response.isCommitted()) {
						throw MESSAGES.responseAlreadyCommited();
					SecurityContext securityContext = exchange.getSecurityContext();
					if (securityContext instanceof SecurityContextImpl) {
						SecurityContextImpl securityContextImpl = (SecurityContextImpl) securityContext;
						try {
							// Perform the actual reset of the authentication state
							authenticationStateField.set(securityContextImpl, authenticationStateField.get(new SecurityContextImpl(null, null)));
						} catch (IllegalArgumentException | IllegalAccessException | SecurityException e) {
							throw new RuntimeException(e);
					if (securityContext.authenticate()) {
						if (securityContext.isAuthenticated()) {
							return true;
						} else {
							throw MESSAGES.authenticationFailed();
					} else {
						// Just return false. The original method for some reason closes the stream here.
						 // see
						return false;

And then register this as an innerHandler:

public class UndertowHandlerExtension implements ServletExtension {
    public void handleDeployment(final DeploymentInfo deploymentInfo, final ServletContext servletContext) {
        deploymentInfo.addInnerHandlerChainWrapper(handler -> new JaspicHandler(handler)); 

The handler extension itself has to be registered by putting its fully qualified class name in /META-INF/services/io.undertow.servlet.ServletExtension.

For the other two issues JASPIAuthenticationMechanism had to be patched by inserting a simple guard around obtaining the so-called “cached account”:

cachedAccount = authSession == null? null : authSession.getAccount();

and by inserting another guard in secureResponse to check if a wrapper hadn’t been installed before:

ServletRequest request = exchange.getAttachment(ATTACHMENT_KEY).getServletRequest();
if (!TRUE.equals(request.getAttribute("JASPIAuthenticationMechanism.secureResponse.installed"))) {
    request.setAttribute("JASPIAuthenticationMechanism.secureResponse.installed", TRUE);
    // original code

(the fix for this last issue was committed rather fast by WildFly developers and fixes it in a better way)

Tomcat/Undertow differences

The next problems were about (small) differences between Tomcat/JBossWeb that JBoss previously used and the new Undertow that’s used in WildFly 8.

The first of those issues (UNDERTOW-348) are about what HttpServletRequest#getRequestURI and HttpServletRequest#getServletPath return when a welcome file is requested. Tomcat will return the requested location for getRequestURI and the welcome file resource for getServletPath, while Undertow will return the welcome file resource for both calls.

E.g. with a welcome file declaration in web.xml as follows:


and when requesting the context root of an application (e.g. http://localhost:8080 for a root deployment), the results are as follows:

getRequestURI getServletPath
Tomcat/JBossWeb / /welcome
Undertow /welcome /welcome

The information about the requested resource can be used to redirect the user to the root (“/”) when for some reason the welcome file resource is directly requested. With such a redirect the website will always display a ‘clean’ URL in the address bar. With the way Undertow does things there’s no way to distinguish a request to “/” from a request to “/welcome” and thus no opportunity to redirect. If a redirect was already in place based on the Tomcat/JBossWeb behavior an endless redirect loop will be the result.

A workaround here is to create another Undertow handler as follows:

public class RequestURIHandler implements HttpHandler {
    private HttpHandler next;
    public RequestURIHandler(HttpHandler next) { = next;
    public void handleRequest(final HttpServerExchange exchange) throws Exception {
        String requestURI = exchange.getRequestURI();

This handler too has to be registered like we did for the JaspicHandler, but this time as an initialHandler.

(update: The behavior of welcome files was changed back to how it was in WildFly 9.0)

Another difference (likely a bug) between JBossWeb and Undertow is that for a root deployment the former will write the JSESSIONID cookie with the path set to “/”. Undertow however leaves the path empty.

An empty path is however interpreted by the browser as being the requested URI, meaning that the JSESSIONID cookie is set on each path where the user happens to do something that creates a session. It doesn’t require much imagination to understand this causes chaos in an application.

As it appears the fact that APIs for getting the context root often return the empty string for the root deployment (instead of “/”), but the path name for other deployments (e.g. “/foo”) is the culprit here. Undertow is not the first one to fall for this. Mojarra once had an identical bug with respect to setting a cookie for The Flash.

We can workaround this issue by setting the path explicitly in web.xml as follows:


(update: Cookies for a root deployment are fixed in WildFly 8.2)


Tomcat (and thus JBossWeb) has a low level mechanism called a Valve, which is a kind of Filter like element but at a much lower level and with access to some of the internal server APIs.

Ideally an application wouldn’t have to resort to using these, but sometimes there’s no choice. For instance a Filter can not change the outcome of the Servlet pipeline. It’s already fully established when the Filter is called. A Filter can redirect or forward, but these mechanisms have various side-effects. There’s also no mechanism in Servlet to intercept ALL cookies being written. By wrapping the HttpServletResponse you can catch a lot, but not these emitted by lower level components like the server generated JSESSIONID and cookies set by e.g. a SAM.

For we had to resort to use a few of these. As Valves are highly specific to Tomcat it’s only logical that Undertow can’t support them. It does have another construct called HttpHandler, which we already used above for some workarounds.

Those handlers are quite powerful. There are ones that are called before the request pipeline is set up (initial handlers) and ones that execute during this pipeline (inner and outer handlers).

One of the things where we used a Valve for in Tomcat/JBossWeb is to do universal cookie rewriting. Unfortunately Undertow doesn’t have a way to rewrite a cookie right away. There is an opportunity to have a kind of listener called right before the response is being written, but it’s a bit non-obvious.

Via a handler and some reflective code we can do this more directly, as shown by the following code:

public class CookieRewriteHandler implements HttpHandler {
    private Field responseCookiesField;
    private final HttpHandler next;
    public CookieRewriteHandler(HttpHandler next) {
 = next;
        try {
            responseCookiesField = HttpServerExchange.class.getDeclaredField("responseCookies");
        } catch (NoSuchFieldException | SecurityException e) {
            throw new RuntimeException(e);
    public void handleRequest(final HttpServerExchange exchange) throws Exception {
        // Overwrite the map used to store cookies internally so we can intercept
        // the cookies being written.
        // Alternatively: there's a wrapper handler called just before the response
        // is being written. We could use that to iterate over the cookie map.
        responseCookiesField.set(exchange, new HashMap<String, Cookie>() {
            private static final long serialVersionUID = 1L;
            public Cookie put(String key, Cookie value) {
                // *****************************
                // rewrite cookie here as needed
                // *****************************
                return super.put(key, value);

Of course using reflection to hack into the internals of a server is rarely a good idea and this handler is at risk of breaking with every minor update to Undertow.


During the initial attempt to get our application running on WildFly I certainly encountered a fair number of issues. It certainly wasn’t the case of just deploying the app and having everything working.

Of course we do have to realize that the Java EE standard datasource and authentication mechanism are unfortunately still not used that much as most vendors keep documenting their proprietary mechanisms first and foremost, which likely causes users to use those most, which on its turn may cause these standard ways to get less testing hours.

The Tomcat/WildFly differences initially looked major, but are after all just small bugs.

The Valves issue is debatable. It’s a major change in the product JBoss, but most Java EE applications should maybe not have used them in the first place. Purely from the point of view of the Java EE spec it doesn’t matter that Red Hat changed this, but looking from the point of view of JBoss itself it does matter and people have little choice but to rewrite their code if they want to upgrade.

Finally we have to realize that WildFly from a certain point of view is like an open beta. It has freely downloadable binaries, but the product is early in its lifecycle and there’s no commercial support available for it yet. When the WildFly branch transitions to JBoss EAP 7 many bugs that the community discovers now will undoubtedly have been fixed and commercial support will be available then. In a way this is the price we pay for a free product such as this. As David Blevins wrote “Open Source Isn’t Free”. Users “pay” by testing the software and producing bug reports and perhaps patches, which IMHO is a pretty good deal.

At any length there’s the eternal tradeoff to be made: adopt the new Java EE 7 spec early with WildFly 8 but be prepared to run into some issues, or wait a good deal longer for JBoss EAP 7 but then have a much more stable product to begin with. This is of course a choice everyone has to make for themselves.

Arjan Tijms

css.php best counter