users@jersey.java.net

Re: [Jersey] Jersey provider-detection fails under Tomcat?

From: Paul Sandoz <Paul.Sandoz_at_Sun.COM>
Date: Tue, 06 Jan 2009 10:44:01 +0100

Hi Craig,

The use of META-INF/services is Jersey specific. For Jersey-
infrastructure i wanted to avoid the end user having to provide
additional configuration beyond depending on the module. This is so
very easy for Maven just add the dependency and it works with no
specific Jersey configuration. IMHO having to document additional
configuration for JAXB XML, JAXB JSON, Multipart Mime (+ the
injectable provider), Atom is not desirable.

Note that the use of file scanning will not work when Jersey jars are
deployed on GF as file scanning will only be performed in the
application web area. Package scanning would work in this case, but it
is not necessarily guaranteed to work across all app servers,
depending on how class loading/isolation is supported. The choice of
which configuration registration mechanism to use for an application
is a choice of the user that should be independent of the registration
of the infrastructure components.

I agree the use of the JAX-RS interfaces for some providers is
unfortunate. It might be possible to change this, it won't break
Jersey itself, and still support the old naming.

Paul.

On Jan 5, 2009, at 7:59 PM, Craig McClanahan wrote:

> Gili wrote:
>> Paul Sandoz (via Nabble) wrote:
>> > They are not instantiated, the class definition is loaded and if
>> it > fails it is ignored. We used to supply one jar file with
>> everything > then we started modularizing but have not completed
>> it and plus some > people still want to use the bundle (ant
>> users). Developers found > warnings of components not loading for
>> stuff they were not interested > in annoying or disconcerting.
>>
>> If they're loaded but never used what's the harm of marking
>> them up
>> with @Provider? I get the feeling there is some sort of a
>> misunderstanding :)
>>
>> > > Yes, but unless you treat this strictly you will break
>> compatibility > > with
>> > > the JSR311 standard.
>> >
>> > Why? they are supplied by Jersey and many have Jersey
>> dependencies, > they are not designed to be cross compatible with
>> other JAX-RS > implementations. They are after all part of Jersey.
>>
>> What happens if a developer adds his own MessageBodyWriter,
>> and doesn't
>> mark it up with @Provider? Jersey will take it quite happily but upon
>> migrating to other implementations it'll break.
> In the particular case that triggered this discussion (a
> MessageBodyReader and MessageBodyWriter for jersey-multipart),
> Jersey automatically recognized them without the @Provider
> annotation because I *also* used a Jersey-specific feature -- an
> entry in the "META-INF/services/javax.ws.rs.ext.MessageBodyWriter"
> identifying my class as an MBW (and a corresonding entry for the
> reader). Despite the implications of the name of this service
> entry, it doesn't seem to be a standard JAX-RS feature (at least, I
> couldn't find it in the spec).
>
> I initially added this entry because that was the only way (at the
> time) to get the Jersey client to load the providers (at the time
> this was developed, the client's scanning stuff had some issues),
> and never noticed that it also caused the thing to load on the
> server without an annotation. Yes, in the particular case of jersey-
> multipart this is all Jersey specific ... but it would likely
> confuse a new developer who:
>
> * Wrote their own provider classes that were not Jersey specific ...
>
> * But cut-n-pasted from the jersey-multipart code (before I added
> the @Provider annotations) ...
>
> * And, not knowing better the developer also cut-n-pasted the
> service entry
> (thinking that, because the name starts with "javax.ws.rs.ext" it
> must be a standard thing) ...
>
> * And found that their provider class loaded in Jersey but not in
> some other implementation.
>
> I don't know if we can actually fix this without breaking backwards
> compatibility for apps based on Jersey 1.0 or 1.0.1, but I think
> this is the root cause of the confusion.
>
> Craig
>
>
>>
>> > > Furthermore, this isn't simply a hole
>> > > in the specification, they explicitly write that @Provider is
>> > > required.
>> > >
>> >
>> > I do not view it so for Jersey supplied infrastructure, i see it
>> more > so for application supplied providers or providers that are
>> designed > to be interoperable over multiple implementations.
>>
>> I don't necessarily disagree. It's just that:
>>
>> 1) It's not clear that Jersey treats application-supplied providers
>> any
>> differently.
>>
>> 2) I don't see the harm of adding @Provider to Jersey-supplied
>> providers
>>
>> > I suspect you are automatically using file-based scanning and
>> that is > pickup up the multipart providers. Many developers use
>> package-based > scanning that explicitly requires declaration of
>> the packages to > search (see the JavaDoc of ServletContainer for
>> more details). What is > your configuration/web.xml set up?
>>
>> It has no Jersey-specific stuff, just the servlet declaration. So I
>> assume I am using the file-based scanning as you mentioned.
>>
>> > > The error is probably occurring at the same time.
>> >
>> > You said this:
>> >
>> > - If the MessageBodyReader omits @Provider then no error
>> message > shows up.
>>
>> Right, because the default logging level does not display
>> CONFIG
>> messages and I am using the default logging level.
>>
>> > and then:
>> >
>> > - If the MessageBodyReader is annotated using @Provider the
>> following
>> > exception shows up when the webapp is initialized:
>> >
>> > implying different behavior occurred (regardless of the logging
>> > level), which i suspect is due to class loading differences, but
>> i > need to verify.
>>
>> Good point. I just remembered that when @Provider was added
>> the entire
>> webapp fails to deploy whereas when it was missing it would fail much
>> later at runtime (which I consider to be worse).
>>
>> > There might be a way to have a minimal log at the warning level
>> and a > more detailed log at the config level.
>>
>> That would help but keep in mind the behavior should still
>> be identical
>> whether @Provider is there or not.
>>
>> Gili
>>
>> ------------------------------------------------------------------------
>> View this message in context: Re: [Jersey] Jersey provider-
>> detection fails under Tomcat? <http://n2.nabble.com/Jersey-provider-detection-fails-under-Tomcat--tp1688690p2113665.html
>> >
>> Sent from the Jersey mailing list archive <http://n2.nabble.com/Jersey-f576304.html
>> > at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>