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.
> > 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: http://n2.nabble.com/Jersey-provider-detection-fails-under-Tomcat--tp1688690p2113665.html
Sent from the Jersey mailing list archive at Nabble.com.