1st Airhacks Q&A And The Questions Are:

  1. Jeff Picklyk: "How would you suggest convincing the ivory tower decision makers to leave plain old Tomcat + Spring in favour of JavaEE 6 or 7?"
  2. Andreas Haufler: "...and you should evaluate: Do I even need a JavaEE monster? Scalability can be achieved at a much lower price (in terms of learning curve and complexity)."
  3. My thoughts on Controversial 80 characters max withs.
  4. Tony Anecito: "JavaFX and ClassPath"
  5. Alberto Gori: "If this is true, I would say it's better to call em.clear() just after em.flush()."?
  6. Manfred Pauli: "You state you're never design your application by technical structures. Where would you pack exceptions to? Especially if they are used through the whole project. "
  7. Yasser: "I am trying to use your example, but my test fails at "facade.service = service". It looks like my test case doesn't have access to the @EJB Service in the ServiceFacade."
  8. Tim B. "If you have two applications communicate via REST and DTOs are forbidden, how do you share the model between those two?"
  9. Anonymous: "How one generates eg: REST client stubs in Delphi for java endpoints? There is still no widespread WSDL-like tools for REST"
  10. Conversation with Jeanne Boyarsky about @Ignore in unit test

I will at least answer the above questions today. If you have any other questions, just write a comment to this post. There are a few hours left...

You can also ask questions during the show using the built-in chat: or via twitter mentioning me: http://twitter.com/AdamBien (@AdamBien) or using the hashtag: #airhacks.

See you at Java EE Workshops at MUC Airport or on demand and in a location very near you: airhacks.io!


I have seen that you often suggest the use of @TransactionAttribute(NOT_SUPPORTED) with @PersistenceContext(type=EXTENDED) EntityManager.

Hibernate team instead is in favor of switching to manual flushing, keeping @TransactionAttribute at REQUIRES and explicitely flushing the EntityManager and the end of the conversation. The rationale is that TransactionAttributeType.NOT_SUPPORTED does not propagate to other EJB in a consistent manner. For example if you call a @Stateless bean from a @Stateful bean with extended persistence context, the former will use the transaction as declared at its class level (of default).

What are your thoughts about this topic?

Posted by Alberto Gori on April 07, 2014 at 12:27 PM CEST #

How can you propagate a back-end exception (for example an OptimisticLockException) to the front-end (JSF or JavaFX)?
Thank you so much.


Posted by Davide Mainardi on April 07, 2014 at 01:28 PM CEST #

what do you recommend for javaee7 beginners in terms of getting expertise in building enterprise class applications? where to begin? assume that they have Java SE knowledge

Posted by Abhishek on April 07, 2014 at 03:37 PM CEST #

diff b/w Managed Beans (JSR 316) and CDI?

Posted by Abhishek on April 07, 2014 at 03:37 PM CEST #

Why is DI included in CDI ? Isn't DI spec enough? What's the main difference?

Posted by Abhishek on April 07, 2014 at 03:38 PM CEST #

what about the front end? JSF is too vast and complex and JavaScript is not Java. This proves to be a hindrance to test apps based on JAXRS and WebSockets. Any simpler way to build front end for JavaEE apps? The ones which probably leverage pure Java

Posted by Abhishek on April 07, 2014 at 03:39 PM CEST #

About web application in JSF and "javax.faces.STATE_SAVING_METHOD" param with "client" value.
Is it possible to decrypt hidden field with view state, change validators on client side and send post with invalid data to server ?
If I use client side saving state, should I write form validators twice (the second time before save to database) ?

Posted by Marek on April 07, 2014 at 04:35 PM CEST #

I use custom "composition" components (facelets) in JSF pages (each element contains label + input). How would you design such component in a multi-war application in case it depends on some entity common to all wars (e.g. it presents all items in some dictionary which is identified by code - a "dictionary" is a common entity used in all wars)?

Posted by Bartosz Kamiński on April 07, 2014 at 05:05 PM CEST #

Do you still see GlassFish as reasonable choice as an application server?

Posted by Patrik Dudits on April 07, 2014 at 05:56 PM CEST #

Hi Adam,
When would you use @Async over the traditional JMS queues ? Another question is there any way to get the message persistence when using @Async ?

Posted by marek on April 07, 2014 at 06:41 PM CEST #

Thanks a lot for taking out the time for helping us with our queries!

Posted by Abhishek on April 07, 2014 at 07:02 PM CEST #

@Alberto Gori
This pattern and its usages is described in Pro JPA 2 (Chapter Six, Merge Strategies sub chapter, here if Google allows you to preview it: http://books.google.pl/books?id=SbEAAQAAQBAJ&pg=PA160&lpg=PA160&dq=%22edit+session%22 )

Posted by Piotr Gliźniewicz on April 07, 2014 at 07:40 PM CEST #

Hi Adam,

first thanks for your time and your answers.

I am not totally satisfied with the answer to my question (number 5). I did some tests and I've found there is a real gain in performance calling em.clear() just after flushing the entitymanager inside the interceptor.

I have also documented these facts in an ad-hoc github project. You can check and test by yourself cloning this repo: https://github.com/agori/interceptor-perf

Posted by Alberto Gori on April 13, 2014 at 02:30 PM CEST #

Post a Comment:
  • HTML Syntax: NOT allowed
...the last 150 posts
...the last 10 comments