Hello Noah,
you can't replace jersey present in Glassfish 3.0.1 with recent version
due to admin console dependency (it is not compatible with jersey 1.2+
if I recall correctly).
advice about trying Glassfish 3.1 is most sound one, you can overcome
lots of potential issues and you can take advantage of new Glassfish
features.. you should be able to override it (see Marek's link) - I can
try it out if you have some issues with "override in war" approach (make
sure you have class loader delegation set to false [1]).
Regards,
Pavel
[1]
http://download.oracle.com/docs/cd/E19798-01/821-1752/beagb/index.html
On 03/09/2011 05:12 AM, NBW wrote:
> Leo/Marek -
>
> I tried these procedures to update a GFv3.0.1 install to Jersey 1.5. I tried
> both the app server upgrade and the WAR file upgrade approach an they both
> failed. I posted recently on this (last Monday). The only advice was from
> someone who said they had the same issues I did and they just decided to go
> directly to GF3.1 which has Jersey 1.5 bundled.
>
> -Noah
>
> On Tue, Mar 8, 2011 at 8:52 AM, Marek Potociar<marek.potociar_at_oracle.com>wrote:
>
>
>> Did you try to follow the Jersey users guide that talks about how to
>> override Jersey in GF?
>>
>> http://jersey.java.net/nonav/documentation/latest/user-guide.html#d4e1868
>>
>> Marek
>>
>> On 03/07/2011 05:14 PM, Leo Romanoff wrote:
>>
>>> Hi,
>>>
>>> I'm facing the following problem.
>>>
>>> I have an EAR file that uses the latest version of Jersey. If I build the
>>> EAR to include the latest Jersey libs, it deploys just fine on those
>>>
>> builds
>>
>>> of the GF application server, which do not contain Jersey libs by
>>>
>> default.
>>
>>> Unfortunately, some of the GF builds that are used by our customer in
>>> production include older versions of Jersey. In this case, EAR deployment
>>> fails due to incompatibilities and conflicts between Jersey versions.
>>>
>>> I've read this explanations about upgrading Jersey on Glassfish:
>>> http://jersey.java.net/nonav/documentation/latest/glassfish.html ,
>>> but it assumes that I'm allowed to modify Glassfish settings or even the
>>> global libs directory, which is not the case in my scenario ;-(
>>>
>>> I'd like to be able to use the required version of Jersey with my EAR
>>>
>> file
>>
>>> even if Glassfish already provides its own Jersey. And I'd like to
>>>
>> achieve
>>
>>> it only by means of creation of a proper EAR (eventually with some
>>>
>> special
>>
>>> descriptors, etc). Is it possible???
>>>
>>> I was thinking e.g. about using Maven shade plugin with its relocate
>>> feature:
>>>
>>>
>> http://maven.apache.org/plugins/maven-shade-plugin/examples/class-relocation.html
>>
>>>
>> http://www.javabeat.net/articles/185-apache-maven-20-maven-plugins-3.html
>>
>>> I guess, with it the class renaming should not be an issue. But I'm not
>>>
>> so
>>
>>> sure about different XML descriptors and the like. I have the feeling,
>>>
>> that
>>
>>> Jersey internally uses some string constants which refer original
>>>
>> Jersey's
>>
>>> class or package names and they would stop working properly after
>>>
>> renaming.
>>
>>> Or am I wrong and someone managed to use this renaming trick with Jersey?
>>>
>>> I'm very interested in any suggestions!
>>>
>>> Thanks,
>>> Leo
>>>
>>> --
>>> View this message in context:
>>>
>> http://jersey.576304.n2.nabble.com/How-to-use-a-specific-version-of-Jersey-with-your-EAR-if-appserver-includes-an-older-version-of-Jersy-tp6097868p6097868.html
>>
>>> Sent from the Jersey mailing list archive at Nabble.com.
>>>
>>
>