Hi Laird,
thanks for your continued contributions! It was nice meeting you again in SF :)
> Hi; was just at JavaOne's "meet the experts" panel for the EE 7
> specification, which was lively, fun and informative.
I second that! Thanks to Linda and Bill and every single spec lead who
made this possible!
> JAX-RS:
> 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.
I'm not sure I understand the problem here. Why should someone package
the war related resource classes into the ear?
Re-using the same for different wars? It seems as if you are moving
into the opposite direction than everybody else: Putting more to the
ear level and less to the war.
I also don't see a reason why "auto discovery" shouldn't work in this
case. I'm not sure if I feel the need to state this explicitly in any
spec at all. Would love to know details about the CDI issues. Did you
send that to the JSR 346 issue tracker?
> 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?
Yes. It is an issue. And far beyond the points you mentioned there are
also some legal things (e.g. MaRisk, Banking) that would make
configuration of any kind a wonderful thing to have. Please file an
issue in the
http://java.net/jira/browse/JAVAEE_SPEC
> JPA:
> 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.
Please contact the JSR 338 EG and file an issue with them:
http://java.net/jira/browse/JPA_SPEC
> 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?
Good question. I would do both to get the conversation running. So,
raising an issue in both JIRAs helps them to talk to each other about
it :)
> (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? :-)
Tracking happens in the JIRAs of the different JSRs. To file this kind
of issues I would suggest doing this against the individual
specifications. For (2) this is clearly the EE spec because we simply
don't have a "configuration JSR". Discussions "should" exactly happen
_here_ or on the eg-mailinglist. Honestly, I simply don't feel that
this is is working very well at the moment. But it is the only way we
have as of today. To my understanding many discussions happen
_offline_ during conferences or even calls.
> (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.
This happens from time to time ;) You are free (and encouraged) to
raise this with the related JSRs. The JPA EG is active and happy to
discuss this kind of requests (that's at least my impression) and I
bet they have an opinion here.
> 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!
Thanks again for taking care and writing up all of this!
- Markus