Archive for January, 2015

First official JSF 2.3 contribution from zeef.com

27 January 2015

A while back we joined the JSF 2.3 EG as zeef.com. 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:

@Inject
@ApplicationMap
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:

@Inject
@ApplicationMap
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

CDI based @Asynchronous alternative

19 January 2015

Arguably one of the most convenient things in EJB after declarative transactions is the @Asynchronous annotation. Applying this annotation to a method will cause it to be executed asynchronously when called (the caller does not have to wait for the method to finish executing).

The downside of this annotation is that it’s only applicable to EJB beans. While EJB beans these days are lightweight and nothing to avoid in general, the fact is that in Java EE 6 and especially Java EE 7 other managed beans, specifically CDI ones, play an increasingly important role. These beans unfortunately can not directly take advantage of the platform provided @Asynchronous.

Building such support ourselves in Java EE 7 however is not that difficult. Thanks to the Java 8, and the Interceptors and Concurrency specs it’s actually quite simple, but with a small caveat (see below):

We’ll start with defining the annotation itself:

@InterceptorBinding
@Target({METHOD})
@Retention(RUNTIME)
@Inherited
public @interface Asynchronous {}

Next we need a helper class that effectively unwraps the dummy Future instance (of type AsyncResult, as provided by the EJB spec) that an asynchronous method returns. Such a wrapper class is needed in Java, since you otherwise can’t call a method that returns say String and assign it to Future<String>. This is not specific to this CDI implementation, but is exactly how EJB’s @Asynchronous works.

public class FutureDelegator implements Future<Object> {
 
    private final Future<?> future;
 
    public FutureDelegator(Future<?> future) {
        this.future = future;
    }
 
    @Override
    public Object get() throws InterruptedException, ExecutionException {
        AsyncResult<?> asyncResult = (AsyncResult<?>) future.get();
        if (asyncResult == null) {
            return null;
        }
 
        return asyncResult.get(); 
    }
 
    @Override
    public Object get(long timeout, TimeUnit unit) throws InterruptedException, ExecutionException, TimeoutException {
        AsyncResult<?> asyncResult = (AsyncResult<?>) future.get(timeout, unit);
        if (asyncResult == null) {
            return null;
        }
 
        return asyncResult.get(); 
    }
 
    @Override
    public boolean cancel(boolean mayInterruptIfRunning) {
        return future.cancel(mayInterruptIfRunning);
    }
 
    @Override
    public boolean isCancelled() {
        return future.isCancelled();
    }
    @Override
    public boolean isDone() {
        return future.isDone();
    }
}

With those 2 classes in place the actual interceptor can be coded as follows:

@Interceptor
@Asynchronous
@Priority(PLATFORM_BEFORE)
public class AsynchronousInterceptor implements Serializable {
 
    private static final long serialVersionUID = 1L;
 
    @Resource
    private ManagedExecutorService managedExecutorService;
 
    @AroundInvoke
    public Object submitAsync(InvocationContext ctx) throws Exception {
        return new FutureDelegator(managedExecutorService.submit( ()-> { return ctx.proceed(); } ));
    }
}

There are a few things to take into account here. The first is the priority of the interceptor. I put it on PLATFORM_BEFORE, which is the absolute lowest level, meaning the interceptor will likely hit before any other interceptor. If this interceptor would ship with a library it’s more correct to use the lowest range reserved for libraries: LIBRARY_BEFORE.

For the actual parallel execution, the call to ctx.proceed() is scheduled on a thread pool using the Java EE Concurrency provided executor service. While this service was only recently introduced in Java EE 7, it in fact originated from a very old spec draft that was dragged into modern times. Unfortunately that spec felt it needed to use the somewhat archaic @Resource annotation for injection instead of the more modern @Inject. So that’s why we use that former one here and not the latter.

A caveat is that the interceptor as given does not work on the current released versions of Weld, but in fact does work on the not yet released SNAPSHOT version. The issue is explained by Jozef on the CDI-dev mailing list.

As a temporary workaround a thread local guard can be used on Weld as follows:

@Interceptor
@Asynchronous
@Priority(PLATFORM_BEFORE)
public class AsynchronousInterceptor implements Serializable {
 
    private static final long serialVersionUID = 1L;
 
    @Resource
    private ManagedExecutorService managedExecutorService;
 
    private static final ThreadLocal<Boolean> asyncInvocation = new ThreadLocal<Boolean>();
 
    @AroundInvoke
    public synchronized Object submitAsync(InvocationContext ctx) throws Exception {
 
        if (TRUE.equals(asyncInvocation.get())) {
            return ctx.proceed();
        }
 
        return new FutureDelegator(managedExecutorService.submit( ()-> { 
            try {
                asyncInvocation.set(TRUE);
                return ctx.proceed();
            } finally {
                 asyncInvocation.remove();
            }
        }));
    }
}

Future work

The interceptor shown here is just a bare bones copy of the EJB version, but lacks the setup of a request scope. Going further however we can add additional features, like using a completable future, optionally named thread pools, etc.

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:

github.com/javaeekickoff/mojarra

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:

github.com/omnifaces/mojarra

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 build.properties.glassfish to build.properties
  2. Edit build.properties and set jsf.build.home 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 4.4.1.20150109 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 4.4.1.20150109-0740 with id “epp.package.jee”:

eclipse-luna-sr1a

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:

download.eclipse.org/technology/epp/packages/luna/SR1a/p2.diff.txt

Looking at the URL revealed that “4.4.1.20150109-0740” 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 “4.4.1.20150109-0740” is about is now solved ๐Ÿ˜‰

Arjan Tijms

css.php best counter