Hi,
Re-stating some aspects of what i said in a previous email just on the
Jersey user list.
The key thing is JAX-RS does require a war (unlike IIRC JAX-WS) to
hook things up in terms of the base URI where the root resource
classes will be served.
The Jersey servlet that is instantiated needs access to the registered
resource and provider classes such that those classes can be analyzed
and instantiated (either by Jersey or by the container depending on
how those classes are managed). So the rules are really governed by
class loading visibility from the servlet associated with a war to
other archives, and i am not familiar with the exact rules.
Paul.
On Apr 22, 2010, at 2:44 PM, Alexis Moussine-Pouchkine wrote:
> CC'ing users_at_glassfish as this may find good answers there as well.
> -Alexis
>
> On 22 avr. 2010, at 13:41, Laird Nelson wrote:
>
>> Hello; thank you in advance for bearing with me on all these
>> questions. I appreciate the support and timely responses of this
>> mailing list.
>>
>> I am somewhat unclear as to the rules I must play by when deploying
>> my
>> JAX-RS based application.
>>
>> As I understand it, if I'm deploying to a Java EE 6 servlet
>> container,
>> I wouldn't need a web.xml file at all, nor any servlet annotations,
>> on
>> any class inside my war file. This fills me with a faint sense of
>> dread :-).
>>
>> Is it true, then, that I would be both JAX-RS and Java EE 6 compliant
>> if my war file looked like this:
>>
>> some.war/WEB-INF/lib:
>> someResources.jar
>> someOtherResources.jar
>> stillSomeMoreResources.jar
>> someProviders.jar
>>
>> ...? And would it also be true and specification-compliant if I
>> dropped that war file into a Java EE 6 container, with no further
>> configuration or changes, that it would be deployed correctly? Is
>> that a valid JAX-RS-in-Java-EE-6 deployment unit?
>>
>> How about this instead:
>>
>> some.ear/lib:
>> someResources.jar
>> someOtherResources.jar
>> stillSomeMoreResources.jar
>> someProviders.jar
>>
>> ...? Note: no .war file, no Application class. I would expect this
>> to fail--that is, I would expect that the intersection of the Java EE
>> 6 specification and the JAX RS specification would cause this to
>> fail.
>>
>> Here's a hybrid:
>>
>> some.ear:
>> empty.war
>> lib:
>> someResources.jar
>> someOtherResources.jar
>> stillSomeMoreResources.jar
>> someProviders.jar
>>
>> I'd actually expect this to work; it would appear that the .war file
>> is actually needed by the specifications only to establish a context
>> root. Everything else in a Java EE 6 environment can be inferred
>> from
>> classpath scanning, which includes not just the war file, but
>> apparently the ear/lib directory as well.
>>
>> Again, I'm looking for spec compliance, not so much whether this
>> setup
>> happens to work on Glassfish or JBoss.
>>
>> Thanks,
>> Laird
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>