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 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

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) ?

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)?

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