Java EE 7 needs improvements in app configuration mechanisms

Most applications need configuration options or preferences, a way for the user to edit them, and a way for the application to read and edit them. Java EE applications are no exception. Right now Java EE applications have numerous options for such settings - but no single choice that's simple, admin- and app-author friendly, and easy for both admin and app to modify.

This is not a new issue, as can be seen with this 2001 question on The Server Side. Back then they suggested *using JMX* ... which doesn't exactly fit the *simple* requirement.

Java EE is supposed to provide much of the groundwork for apps as part of the container, so the app author can get on with solving their problem. Right now it doesn't help much with application settings, and this needs improvement so that apps:

• Don't need to each provide a custom UI in order to edit even the simplest settings
• Can easily modify their own settings
• Can guarantee the persistence of their settings across redeploys and across cluster nodes
• Don't require a full database and data access layer / JPA / etc just to store simple configuration options.

I'd like to highlight this as an issue for Java EE 7 or 8.

UPDATE: Marcus Eisele pointed out a related post by Antonio Goncalves as part of a jsr342-experts post on configuration. Have a look at Antonio's piece; he's looking at it from a slightly different angle, but with many of the same issues.

See also this stack overflow post from a while back, where I asked for help on this topic and got crickets.

Update on JPA 2.1 and fetch control

UPDATE: JSR388 has been released with support for "fetch groups", which at first glance seem to meet this need.

I re-posted my query to javaee-spec-users after seeing no response on the jpa-spec users list. A reply from Linda DeMichiel on the javaee-spec list looks promising.

Separate discussion (twitter) suggests it's conference season so everyone's busy and sidetracked as well.

The spec proposal does indeed list:

Support for the use of "fetch groups" and/or "fetch plans" to provide further control over data that is fetched, detached, copied, and/or used in merging.

but I'd seen no discussion of it on the EG list, which I've been monitoring since near start. (UPDATE: There'd been a wee bit, I just missed it.) I didn't realise they were working to an ordered, specific agenda, though it certainly makes sense to tackle such a big task in small chunks like that.

The JPA 2.1 spec proposal also has some other good stuff. Points of particular interest to me include:

• Methods for dirty detection
• Additional event listeners and callback methods; availability of entity manager to callbacks

Dirty detection in particular has caused me a lot of pain in the past, so it's good to see it on the list. It'd simplify quite a few tasks around working with JPA, particularly in apps with longer-lived sessions like interactive GUI / swing apps, Vaadin web apps, etc.

One thing that isn't there that perhaps should be is handling failure more cleanly. Currently one needs to clone entity graphs before attempting to persist them using a tool like org.hibernate.util.SerializationHelper, because they may be in an inconsistent state if a persist operation fails. It's slow and ugly to need to serialize/deserialize to clone an entity graph, but hard to get around because dynamic weaving and enrichment means you can't properly clone an entity just by allocating a new one and copying properties into it. Worse, you have to handle all the cascades yourself. Many common use cases involve situations where failure is normal: serialization failures of serializable transactions, optimistic locking issues, etc. Often you want to re-fetch the entities and re-do the work from scratch, but that's painful if you have user-modified state in those entities and all you want to do is retry a merge after a database serialization failure.

Guess I'd better pipe up about that too. It isn't news, but if it isn't on the agenda maybe it should be added for discusson.

Now is the time to join the jpa-spec users list on http://java.net/projects/jpa-spec and pipe up about practical, real-world issues you face with JPA. Even if everyone's out conferencing, email queues up nicely.

Mail to the JPA 2.1 Expert Group re fetch control

I'm setting up another opportunity to look foolish - which I view as a good thing; if I don't risk looking foolish, I don't learn nearly as much.

I've mailed the JPA 2.1 EG re control over fetch mode and strategy on a per-property, per query basis, as I'm concerned this may not otherwise be considered for JPA 2.1 and thus Java EE 7. As previously expressed here I think it's a big pain point in Java EE development.

I'd appreciate your support if you've found JPA 2's control over eager vs lazy fetching limiting and challenging in your projects. Please post on the JPA 2.1 users mailing list.

---

UPDATE:: JSR388 has been released with support for "fetch graphs", a feature that appears to meet the specified needs. I'm no longer working with Java EE or JPA, so I haven't tested it out.

UPDATE: http://blog.ringerc.id.au/2012/06/update-on-jpa-21-and-fetch-control.html

UPDATE: Many of these problems are solved, albeit in non-standard and non-portalbe ways, by EclipseLink. EclipseLink extensions can be used to gain much greater control over fetches at the entity definition level and more importantly via powerful per-query hints. Glassfish uses EclipseLink by default, but you can use EclipseLink instead of Hibernate as your persistence provider in JBoss AS 7.

---

JPA 2.1 will support CDI Injection in EntityListener - in Java EE 7

It's official, JPA 2.1 in Java EE 7 will support injection into EntityListener. I've checked the JPA 2.1 spec, and in draft 3 the revision notes state that:

Added support for use of CDI injection in entity listeners. Added requirement for Java EE container to pass reference to BeanManager on createContainerEntityManagerFactory call.

This is good news. The spec needs more eyes. If you use JPA, you need to have a look. Check to see if any pain points you encounter in JPA 2 are addressed. Check the revision notes at the end and see if something jumps out at you as being problematic or unsafe. If you have concerns contact the EG. More eyes on draft standards means fewer problems in released standards. EclipseLink has already implemented JPA 2.1 Arithmetic expressions with Sub-Queries, option support for select and from clause subqueries and JPA 2.1 JPQL Generic Function support so go try them out in EclipseLink 2.4.0 pre-releases using the latest milestone.

It might be worth trying out the new goodies too. Sometimes a feature seems reasonable on paper, but works very poorly in practice. The spec-before-implementation development model of Java EE means we get to "enjoy" lots of those issues; help prevent more by testing the implementation early.

I didn't see anything about fetch strategies and modes, so I'm going to have to go nag them again. I had success the first time around in pushing for CDI injection into EntityListener, but the spec is significantly further along now. OTOH, the difficulty of controlling eager vs lazy properties on a per-query basis is a big pain point.

UPDATE: done, let's see what happens.

(BTW, it seems a shame that JPA 2.1 is being tied to EE 7, as that's still a long way off.)

JPA2 is very inflexible with eager/lazy fetching

This must be a common situation with JPA2, but seems poorly catered for. I feel like I must be missing something obvious. It's amazingly hard to override lazy fetching of properties on a per-query basis, forcing eager fetching of normally lazily fetched properties.

There doesn't appear be any standard API to control whether fetching of a given relationship or property is done eagerly or lazily in a particular query. Nor is there a standard hint for setHint(...) - EclipseLink offers some limited control, Hibernate has no hint equivalent to its own Criteria.setFetchMode( ). JPQL/HQL's left join fetch and the (somewhat broken) Criteria equivalent scale very poorly to more than a couple of properties or to nested lazy properties, and don't permit other fetch strategies like subselect or SELECT fetching to be used.

Tell me I'm wrong and there's some facility in JPA for this.

Read on before replying with "just use left join fetch". I wish it were that simple, and not just because a join fetch isn't always an appropriate strategy.