Skip to main content

[javaee-spec users] Misc. feedback

  • From: Laird Nelson <ljnelson@...>
  • To: users@...
  • Subject: [javaee-spec users] Misc. feedback
  • 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 going!


[javaee-spec users] Misc. feedback

Laird Nelson 10/03/2012

[javaee-spec users] Re: Misc. feedback

Markus Eisele 10/18/2012

[javaee-spec users] Re: Misc. feedback

Laird Nelson 10/19/2012

[javaee-spec users] Re: Misc. feedback

Pete Muir 10/20/2012

[javaee-spec users] Re: Misc. feedback

Marek Potociar 10/22/2012

[javaee-spec users] Re: Misc. feedback

Laird Nelson 10/22/2012

[javaee-spec users] Re: Misc. feedback

Marek Potociar 10/22/2012
Please Confirm