On Oct 19, 2012, at 8:01 PM, Laird Nelson <ljnelson_at_gmail.com> wrote:
> On Wed, Oct 17, 2012 at 10:23 PM, Markus Eisele <myfear_at_web.de> 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:
>
> @javax.ws.rs.ApplicationPath("/rest/api")
> public class Application extends javax.ws.rs.core.Application {
>
> }
>
> 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.
Can you please file an issue against JAX-RS spec (
http://java.net/jira/browse/JAX_RS_SPEC)? I'd be also inclined to think the visibility is what should matter here.
Marek Potociar
(JAX-RS Spec Lead)
>
> 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): http://java.net/jira/browse/GLASSFISH-18793.
>
> Please file an
> issue [regarding customization] in the http://java.net/jira/browse/JAVAEE_SPEC
>
> OK, will do.
>
> Please contact the JSR 338 EG and file an issue with them [regarding lookups by business key]:
> http://java.net/jira/browse/JPA_SPEC
>
> 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,
> Laird
>
> --
> http://about.me/lairdnelson
>