Create a gist now

Instantly share code, notes, and snippets.

What would you like to do?
10thAirhacksQ&A

Hi Adam,
which technology stack would you prefer to choose for an interactive single page mobile app? As JavaFX is not supported by Apple, I am currently experimenting with a hybrid web app technology stack: GWT, MGWT, PhoneGap. I evaluated Vaadin for this purpose, but integrating custom widgets into their complex architecture seems to be a real pain. Something like Java EE + Primefaces seems not be the first candidate for a single page app to me. What would your approach be?
Regards,
Jens

What application server are you currently using for your new Java EE7 projects? Would you recommend GlassFish 4.1 despite the lack of commercial support, or is better to go with WildFly 8.2.0?
Thank you
Antonio.

Hi Adam,
what is your opinion about Project Avatar (https://avatar.java.net/)?
Thanks in advance.

Hi Adam,

I have a question regarding JAX-RS and its integration with BeanValidation, precisely the error reporting.
JSR-339(§7.6) says that implementations MUST provide an exception mapper for ValidationException and ConstraintViolationException, and SHOULD includes a response entity but the format of this entity is not in the scope of the spec.
Now if we look at 2 implementations:

  • First, Jersey on Glassfish just throws ValidationException and ConstraintViolationException by default. No ExceptionMapper returns entities unless the ServerProperties.BV_SEND_ERROR_IN_RESPONSE property is set to true.
  • On the other hand, RestEASY on Wildfly, has, by default, an ExceptionMapper that handles ValidationException and ResteasyViolationException and returns some response entities. Note that ResteasyViolationException is not a subclass of ConstraintViolationException.

Also note that since the response entities are not specified, they have different formats on Jersey and RestEASY.

Now, let's say we want to make a portable application with JAX-RS error reporting (at least Glassfish/Wildfly portable).
On Jersey, we just have to make a custom ExceptionMapper for ValidationException and ConstraintViolationException that returns entities with some format expected by the javascript client.
On RestEASY, such ExceptionMapper would not be called because when constraints are violated RestEasy throws ResteasyViolationException which is not a subclass of ConstraintViolationException. So we would have to do a specific build for Wildfly, using a maven profile for instance, that adds a specific ExceptionMapper to handle ResteasyViolationException and return the expected response entity.

Do you see an easier way to have portable error reporting?
Or am I missing something?
By portable error reporting, I just mean that the response would be the same on Wildlfy and Glassifh to use the same js client.

Thanks in advance

Benjamin

"JavaEE7 retired the DTO". How would you approach mapping inheritance structures in the era before JSR 367? It's rather vague what the best way is to do this with the standard JAXB API. Besides this the XML annotations look a bit weird when you're using JSON. They are portable however. Alternative could be to use Jackson annotations such as @jsonsubtypes, but these are not portable. So for example you have a Dog and a Cat which both extend Animal, no interfaces. There are (shared) properties in Animal and separate properties in Cat and Dog. Could you whip up a simple JAXRS project which automagically maps JSON input to the appropriate objects? And suppose the inheritance tree was more complex, would this then be a case where you would use a DTO to capture the JSON and do the mapping to the JPA entity manually? BTW, this question seems to be quite hot in all those 'boring enterprise projects'.

And how do you ignore unknown JSON properties with JAXB. Is there an equivalent for the Jackson annotation @jsonignoreproperties(ignoreUnknown = true) in JAXB? And I don't mean sticking XmlTransient on every property, I only want to have the properties in my object which I care about.

Thanks and keep up the good work with the show!

Remko

Hi Adam,

Do you have any suggestion to maintain a single code base for a Java EE product that's used by different clients? If yes, how do we maintain the customization for individual clients? For Example: Some client requires changes to an existing screen (field label, new field etc). Some clients want new modules that are currently not in the product? The product is deployed on-premise, so there is variation in the DB and Application server based on the client's existing infrastructure? The application uses old technologies (Struts 1.x, Hibernate 3.0, User Managed Transaction etc) and has around 300 screens. Unfortunately the Senior management want to save the existing investment and don't want to rewrite the application.

Thanks
Paddy

Hi,

I noticed in this airhack you recommended against GWT due to round trip time. I wonder if this impression is based on GWT 2.7+ or earlier versions? We currently use GWT SuperDevMode + IntelliJ IDEA to develop our client side apps and even the largest has no more than 2-3 second reloads. FWIW GWT 2.7 added incremental compiles such that reloads are proportional to the size of the source code change.

When we were using GWT 2.6.1 and earlier we did find the turn-around time high and actually started to build more of our applications using JSF if they could be shoe-horned to use JSF's strengths. But after GWT 2.7 came out we actually found GWT development was faster and have gone to back to it with few regrets. I see the difference between GWT 2.6.1 and GWT 2.7 as comparable to between J2EE and EE 5. The next version of GWT (due to release in the next week or so?) that uses all the Java 8 goodness is even better.

GWT development is still complex but a significant part of that is inherent in developing SPA/browser based applications. Some of the libraries are also sucky but you get that with any toolkit that has been around 8 years or so.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment