On Jun 24, 2009, at 7:56 PM, Jan Luehe wrote:
> On 06/24/09 01:11 AM, Paul Sandoz wrote:
>> Hi,
>>
>> GF v3 preview comes installed with Jersey 1.1.0-ea.
>>
>> If i create a web app with the Jersey 1.1.1-ea-SNAPSHOT jars in the
>> war WEB-INF/lib and set the
>>
>> <class-loader delegate="false"/>
>>
>> in the WEB-INF/sun-web.xml then deploy to GF v3, then i find that
>> Jersey 1.1.1-ea-SNAPSHOT is also loading the META-INF/services
>> files from Jersey 1.1.0-ea. Is that expected behavior ?
>>
>>
>> I found this out recently because we made some changes that
>> resulted in modifcations to some META-INF/service files. When I
>> deploy such an app (as described above) i get some exceptions
>> thrown by Jersey in the log (see end of email).
>>
>> These exceptions can only occur if a class cannot be loaded from a
>> META-INF/services file, and that can only occur if it is including
>> an 1.1.0-ea version of a META-INF/services file.
>>
>> Note that this currently does not affect the running of the
>> application, since the changes made are such that it is the case.
>>
>> But future changes may result in very odd/broken behavior if a
>> developer attempts to use a later version on Jersey, installed in
>> the war, that the version installed in GF.
>
> Note that the return value of java.util.ServiceLoader#load is an
> iteration over the
> result of a call to ClassLoader#getResources.
>
> The only effect of setting "delegate" to false is that any local
> matching resources will appear
> *first* in the returned Enumeration, but it does not mean that any
> matching resources higher
> up in the class loader delegation chain will be omitted from the
> Enumeration.
>
Thanks and drat... any ideas on how we may be able to work around
this? perhaps an option to completely isolate certain jars from being
used?
I guess the only reliable solution would be to ask developers to
upgrade the version of Jersey in GF, or remove it from GF.
Ideally i would like to continuously push SNAPSHOT releases to the GF
v3 update center.
Paul.