[javaee-spec users] Misc. feedback

From: Laird Nelson <>
Date: Tue, 2 Oct 2012 19:57:09 -0700

Hi; was just at JavaOne's "meet the experts" panel for the EE 7
specification, which was lively, fun and informative.

Here are a few nuggets I've been holding back because I figured I probably
just don't fully understand the problems, or haven't known where to put
them, or....

With the entreaties for any and all feedback coming from all the spec
leaders on that panel, OK, you've been warned. :-)

1. I would love a clarification in the JAX-RS specification (or perhaps the
EE spec where it concerns JAX-RS) whether it is legal to have an empty .war
file housing my (empty) JAX-RS Application, with the resource classes found
in the enclosing ear file's lib directory. This works, but there are
injection problems involving CDI and @ManagedBean intersection issues when
we do this. Both the EE specification and the JAX-RS specification are
silent on this issue. Paul Sandoz indicated to me a while back that he saw
no reason that this way of getting resource classes "auto discovered"
should be a problem.

Overall Java EE configuration/customization:
2. I know there have been discussions on this in the past, but I'd love to
see some sort of...what, formal area? dashboard? whiteboard? where we can
talk about configuration and Java EE. Talking to David Blevins and Bill
Shannon and others I'm sure I've bored you all silly pointing out just how
hard it is for an end customer of our .ear-file-based solution to customize
it. ("See, what you do is, you unpack it, and then you unpack the things
inside it, and, in some cases, the things inside those--then you edit your
single value, then repack everything (don't make a mistake here!) and then
there, you're all set.") Where is the best place to start this feature
request in earnest?

3. JPA: it sure would be nice to have first-class support for looking up
entities by their "business key". In our JPA designs, our entities have
opaque, generated primary keys. This is great. But we then have
unique-constraint fields that represent the business key that means
something to our customers. It would be nice to be able to have some
support in JPA for this rather than simply defining a query each time. We
can't define some sort of templatized named query for it, and creating a
new JPA query on the fly each time (where 99% of it is the same each time)
is cumbersome. I seem to recall some sort of talk about a @NaturalId
annotation, but am not sure now if I've invented that.

A couple of meta-points:

(1) is an example of where I see a hole or a crack in either the platform
spec or the specific component spec. In this case, back when I raised it
to Paul thousands of years ago, he didn't know offhand whether or not the
EE spec would permit it or not (i.e. he was understandably thinking of his
spec in isolation). Is this something where I should raise it to the
JAX-RS spec list, or the platform list?

(2) is an example of: I have a vague feature request. It's been bothering
me and my customers and people to whom I champion Java EE for ages. I
haven't thought it through. I don't have a proposal. It's not baked. It
is probably of staggering importance in the real world of applications,
maybe even more so than our usual debates about meta-annotations of
annotations and other deep dives into EE lore. Where does real discussion
about this feature idea/problem area take place? Is this suitable for the
Java EE expert/user list? Is it tracked somewhere? If it is, am I just
dumb for not knowing immediately where that would be? :-)

(3) is an example of a down-in-the-trenches problem in the world of
applications that comes up IMMEDIATELY with certain application designs,
and not, I would imagine, very obviously during deeper and drier
specification discussions. It would be nice to gather a whole pile of such
problems somewhere, because there are (surely) many, many of them that just
don't crop up when you're thinking about specifications and only show up
after you've tried to code something big and hairy and customizable and run
smack into the issue.

Thanks for reading. I hope you throw tomatoes at me, use this as a
springboard, take me to task, etc. etc. Anything to get the discussion