Hi Kevin,
The jersey-bundle contains core, server, client, json and atom
modules. it just copies the classes from those modules. We did run
the tests against using this module and they passed.
I wonder if there is a caching issue with GF? GF does not come with
Jersey installed and if you installed Jersey into GF using the update
centre then it will still require you put the Jersey jars in the web/
WEB-INF/lib directory.
The dependencies document informs maven and non-maven users the
dependencies are [1].
Even though you are using ServletAdapter it extends ServletContainer.
Infact if you are not using the persistence support of
ServletAdapeter you can use ServletContainer.
Paul.
[1]
https://jersey.dev.java.net/source/browse/*checkout*/jersey/trunk/
jersey/dependencies.html
On Aug 27, 2008, at 6:51 AM, Kevin Duffey wrote:
> Gees, thought I tried this already.. so I was using the jersey-
> bundle.10.snapshot. When I replaced that with the jersey-core and
> jerser-server, it works now. I thought the bundle was basically the
> core and server together? Why would deploying the bundle cause the
> httpServlet class not found issue, but core/server does not?
>
> ----- Original Message ----
> From: Kevin Duffey <andjarnic_at_yahoo.com>
> To: users_at_jersey.dev.java.net
> Sent: Tuesday, August 26, 2008 9:46:41 PM
> Subject: [Jersey] Problem with latest jersery/jsr mixing with
> version that comes with glassfish?
>
> Hey all,
>
> I seem to be running into some odd class not found issues. I
> grabbed the latest jersey trunk, and built it, all was good.
> Dropped it in my web/WEB-INF/lib dir, deployed my app and bang,
> problems with jersey. This is deployed in a glassfishv2ur2 domain.
> I still had the old jsr311 .9 in my lib, so duh.. grabbed latest
> jsr311, built it. Somehow its at snapshot 0.11, so that didnt work.
> Looked in my .m2 maven local repository, found the javax.. jsr, and
> in there I found a .10 and .10 snapshot. .10 had the "latest" it
> appeared, as ApplicationConfig was renamed to Application, which
> was shown in the changes.txt file for the trunk jersey I got. So I
> dropped that into my web/WEB-INF/lib dir. Deployed. It deployed ok,
> but when I access it, I get:
>
> java.lang.AbstractMethodError: javax.ws.rs.core.UriBuilder.encode(Z)
> Ljavax/ws/rs/core/UriBuilder;
> at javax.ws.rs.core.UriBuilder.fromUri(UriBuilder.java:81)
> at javax.ws.rs.core.UriBuilder.fromUri(UriBuilder.java:101)
> at com.sun.jersey.spi.container.servlet.ServletContainer.service
> (ServletContainer.java:259)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:831)
>
>
> Which is odd to me because I have in my web.xml to use the
> ServletAdapter, not ServletContainer. But even so, I looked at the
> source for jersey and jsr311, neither have the encode() call any
> more. So, my thinking now is, somehow, my current glassfish has an
> older jersery and/or jsr311 in it that is somehow being used BEFORE
> my WEB-INF/lib version, which I thought was wrong.. I thought the
> WEB-INF/lib jars had precedence on the classpath... maybe its a
> glassfish bug?
>
> Anyway, so I then moved my jersery/jsr jars into the domains/
> restDomain/lib/ext location, hoping that would work. I found that
> this technique worked on my client side where I was having similar
> issues when deploying jersey/jsr311. When I put them there, I get:
>
> java.lang.NoClassDefFoundError: javax/servlet/http/HttpServlet
>
>
> WHAT? How did putting those two jar files make glassfish not find
> its servlet classes? So now I am confused. Am I the only one
> deploying the latest jsr311.10 and jersey.10.snapshot jar files in
> a web app in glassfish and seeing this?
>
>
>
>
>