sebastiandaschner news

thursday, may 18, 2017

Greetings from Shibuya, Tokyo and welcome to the sixth newsletter edition!

The last days were full of Java Community work and traveling, even more than usual.

In the beginning of May I held Docker hands-on workshops at a client in Munich. Interestingly the attendees were not only developers but also project managers who wanted some insight what these technologies are about. It was very nice to see the excitement of all attendees when running Docker containers themselves.

I attended JavaDay Istanbul to speak about the topic of CQRS with Java EE. Even though it was a very short stay for me — flying in in the morning and back in the evening — I totally enjoyed the short time in Istanbul, for me it the very first time in Turkey. A big thanks to the organizers and next time I definitely try to stay longer.

One day after Istanbul I flew to India — also for the first time. I gave the keynote presentation at Oracle Code New Delhi and helped out with live-streamed and recorded developer interviews. It was amazing to see the interest and engagement of the Indian developers as well as the high number of female developers. Our male-dominated industry needs more support in form of women in tech as well as diversity and all of us should take opportunities to encourage that.

After India the next destination was Japan. Java Community Manager Steve Chin and myself will go on another motorbike tour all across the country to speak about the Java ecosystem and to encourage Japanese Java developers to participate in the Community.

In order to do so we organized a Java unconference at an Onsen, called JOnsen. Staying there in the beautiful Izu peninsula and discussing Java and technology related topics with attendees from both Japan and the rest of the world was just a blast. The whole weekend went better than expected, was very inspiring for me and I hope for everybody else as well.

Yesterday JavaDay Tokyo took place. I helped with developer interviews and attending a panel discussion about the Japanese Java Community and their engagement not only in Japan but internationally.

Today I presented the topic of CQRS with Java EE at Oracle Code Tokyo and on Saturday the JJUG (Japan Java User Group) event will take place. These events are always a lot of fun and something to look forward to.

 

What’s new

 

Java EE quiz solution #1

You may have seen the Java and Java EE quizzes that are published from the official Java twitter handle as part of #100DaysOfJava.

See my first basic CDI question here.

As most of the responses correctly pointed out the answer is the method returns an instance of Hello — that will output hello when printed to string.

Some developers also mentioned that it depends on the bean discovery mode of CDI, that needs to be set to “All” to being able to inject managed beans that are not annotated.

 

Java EE quiz solution #1

The solution of my second Java EE related question is:

Invoking askFirst() will output

intercepted!
asked first
asked second

The QuizInterceptor is included to intercept all invocations of business method on Quiz instances. Therefore the askFirst() method will be intercepted and intercepted! will be printed first. The askSecond() method call inside of askFirst() is not intercepted since this is just a direct method invocation on the same object — without applying all cross-cutting concerns from the container. askSecond() is invoked on this object and not a proxy of Quiz. This is why the interceptor is ignored here.

 

Use JAX-RS exceptions for status codes

One way to send specific HTTP (error) status codes from a JAX-RS resource is to use the javax.ws.rs.core.Response class with its Builder Pattern-like API. If you want to specify the return type according to the response body, you can still do so and send a different status on errors by throwing a WebApplicationException.

@Path("test")
public class TestResource {

    @GET
    public String hello() {
        if (new Random().nextBoolean())
            throw new WebApplicationException(Response.Status.CONFLICT);

        return "Hello World, " + Instant.now();
    }

}

The constructors of this special type of exception accepts Responses, Response.Statuses or int types. The JAX-RS runtime will send the corresponding HTTP statuses and header fields, respectively.

There are also pre-defined subtypes of WebApplicationException for common errors like NotFoundException or BadRequestException.

 

Avoid wrapped EJB exceptions

And we stay in the area of exceptions. A common struggle when dealing with EJBs is that any thrown exception will be wrapped in an EJBException when accessed by any non-EJB context, e.g. a request scoped JAX-RS resource. This makes exception handling quite cumbersome, as the EJBException would have to be unwrapped to inspect the cause.

By specifying @ApplicationException on own exception types the cause will not be wrapped.

@Stateless
public class Hello {

    public String greeting() {
        if (new Random().nextBoolean())
            throw new GreetingException("Could not greet");

        return "hello";
    }

}
@ApplicationException
public class GreetingException extends RuntimeException {

    public GreetingException(String message) {
        super(message);
    }

}

By specifying @ApplicationException(rollback = true) the container will rollback an active transaction when the exception occurs.

Now calling hello.greeting() from any non-EJB context will provide the GreetingException directly.

In the next issue I will show another approach for own exception handling with custom JAX-RS status codes and header information included with EJB exceptions.

 

Thanks a lot for reading and see you next time!

 

Did you like the content? You can subscribe to the newsletter for free:

All opinions are my own and do not reflect those of my employer or colleagues.