On Jan 5, 2009, at 4:59 PM, Gili wrote:
>
>
> On Dec 24, 2008, at 3:10 AM, Gili wrote:
> An error will be logged at the level of CONFIG. This will occur when
> the class is attempted to be loaded. The reason for using CONFIG is
> some what historical but also related to using jersey-bundle that may
> contain many providers that are not needed but are instantiated and
> errors will result because the dependencies are deliberately not
> included.
> </config>
>
> Why couldn't you omit these from jersey-bundle? Can you go into more
> details
> of why they are instantiated in the first place?
>
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.
The reason for the bundle is so that a bundle of functionality can be
supplied in one jar file but this invariably means that not everyone
wants everything from the bundle.
>
> Paul Sandoz wrote:
>>
>> Note that it is not necessary for all providers to be annotated with
>> @Provider. Infrastructure-based providers are registered using META-
>> INF/services, thus there is no need to class scan and instead
>> registration occurs because the jar is in the class path.
>>
>
> 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.
> Users migrating from Jersey to another implementation
> and back will see different behavior.
Not for the standard providers as JAX-RS specifies what must be
supplied. JAX-RS does not specify how the standard support is
supplied. If you are depending on non-standard providers then it is a
different matter.
> 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.
>
> Paul Sandoz wrote:
>>
>> Did you configure class scanning (file or package) to the multipart
>> providers? I presume you did.
>>
>
> No, I just had jersey-multipart in my classpath. How would you
> configure
> class scanning as you mention?
>
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?
>
> Paul Sandoz wrote:
>>
>> I don't understand why the error occurs when the class is
>> instantiated
>> rather than when the class is loaded. Namely the code to
>> instantiate a
>> provider class registered via META-INF/services or annotated with
>> @Provider and scanned is the same.
>>
>
> The error is probably occurring at the same time.
You said this:
- If the MessageBodyReader omits @Provider then no error message
shows up.
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.
> The difference is that I
> am using the default logging level, which ignores CONFIG. Looking at
> the
> logging levels, this definitely sounds like it should be logged
> using WARN
> instead of CONFIG.
>
There might be a way to have a minimal log at the warning level and a
more detailed log at the config level.
Paul.