[javaee-spec users] Re: Misc. feedback

From: Laird Nelson <>
Date: Fri, 19 Oct 2012 11:01:36 -0700

On Wed, Oct 17, 2012 at 10:23 PM, Markus Eisele <> wrote:

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

> I'm not sure I understand the problem here. Why should someone package
> the war related resource classes into the ear?

We do it for customization purposes. Let me explain.

We use JAX-RS (and resource adapters, hence our need for the full EE
profile and our use of the .ear deployment format). We allow our customers
to essentially own the .ear itself and its contents. Don't like a
particular Jenzabar .jar file that implements a particular interface? Take
our implementation jar out, throw in yours, and yours is used instead.

The .ear file is thus where all of the loose coupling comes together. We
have a single skinny .war inside it that houses our JAX-RS application, and
no other libraries or classes or files—it contains nothing else—and the
application subclass itself is essentially a no-op. It looks essentially
just like this:"/rest/api")
public class Application extends {


If you don't like an endpoint or your particular distribution of our
product doesn't require one, then you simply remove the resource class jar
from the .ear's lib directory (like you would any other .jar file in our
product that you don't want). Everything is done the same way. So we rely
on the specification-described "auto discovery" mechanism.

> I also don't see a reason why "auto discovery" shouldn't work in this
> case.

Right; my point is that no one explicitly says in either the EE or the
JAX-RS specification whether or not it should work in an .ear environment.
 The JAX-RS specification in fact hints slightly that it won't work.
 Section 2.3.2 reads as follows:

"A JAX-RS application is packaged as a Web application in a .war file. The
application classes are packaged in WEB-INF/classes or WEB-INF/lib and
required libraries are packaged in WEB-INF/lib. See the Servlet
specification for full details on packaging of web applications."

This sounds suspiciously like my case is not supposed to work at all. But
I'm thinking this is a language issue in the specification.

In this case my resource .jars are not "application classes" (they are not
.class files, they are .jar files), but perhaps they are required libraries.

At any rate, section 2.3.2 goes on to say:

"...if both Application.getClasses and Application.getSingletons return an
empty list [this is what happens in our application] then all root resource
classes and providers **packaged in the web application** MUST be included
in the published JAX-RS application." [emphasis mine]

So in our case, our root resource classes are NOT "packaged in the web
application", but they ARE packaged in the enterprise application, and ARE
VISIBLE from the web application. I'm looking for a clarification here on
what the specification really means. As I mentioned before, Paul Sandoz
gave a hint that really perhaps visibility was meant here, not strict
packaging requirements. Our scenario (mostly) works in GlassFish; I am
willing to bet money sight unseen that it will fail in JBoss.

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

No, but you can read about the GlassFish bug report behind all this here
(still can't log in to JIRA; logging out and logging in doesn't fix the
issue; some sort of SSO problem):

> Please file an
> issue [regarding customization] in the

OK, will do.

> Please contact the JSR 338 EG and file an issue with them [regarding
> lookups by business key]:

OK, will do.

> Discussions [of genuine EE-scoped concerns] "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.

My impression as well. The forum software and email gateway are
impediments here (amiright?). They ferry the text to and from the
eyeballs, but beyond fulfilling this simple requirement they stink in
almost every other regard ranging from formatting to timeliness. I guess
if (a) it's what we have and (b) it's what Oracle mandates as has been made
obliquely clear to me on several occasions by several expert group members
in person, then we make do.

> Best,