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.