On Jan 5, 2009, at 5:51 PM, 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 :)
>
Because i wanted a very clear distinction of what is infrastructure
and what is not and wanted to ensure that scanning ignores
infrastructure stuff (without depending on package names). Note that
there are other infrastructure-based provider instances using Jersey
specific interfaces registered e.g. injection stuff added by the
Jersey Servlet.
> > > 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.
Note that when scanning only classes annotated with @Path or @Provider
are registered.
However, i think Jersey is a bit loose is in one aspect and agree with
you it can cause an interop issue. The Jersey implementations of
Application do allow any class or singleton to be added and is not
restricted to those annotated with @Path or @Provider. So a developer
could explicitly add a class not annotated with @Path or @Provider and
it is considered a provider. Thankfully this is rare but still needs
to be fixed. Need to think some more about this...
>
> > > 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.
>
Yes.
> > > 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).
>
Yes, for application-based providers this makes sense, but for
infrastructure stuff there is a "keep on trucking approach" because of
what i previously described about bundles.
> > 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.
>
Yes.
Paul.