users@jersey.java.net

[Jersey] Re: Fw: JAXBJSONContext in Glassfish 3.1

From: Jakub Podlesak <jakub.podlesak_at_oracle.com>
Date: Tue, 29 Mar 2011 12:56:59 -0700

Hi Ronak,

You should not need to upgrade the Metro bundle in your GlassFish 3.1
to get a Jersey 1.5 based application work on it. I have just tried
with the Jersey jMakiBackend example application (which uses the JSON
JAXBContext stuff),
GFv3.1 and Java SE 1.6.0_24, without bundling any jars with the war, end
everything
just worked.

Some people experience such a VerifyError problem when they have one class
available in multiple jars in the classpath. Could that be related
to your use case? I would search for the NaturalJAXBProvider class,
which you mentioned in the original post.

Anyway, it is hard to help without a reproducible test case application.

~Jakub

On 03/29/2011 09:55 AM, Ronak Patel wrote:
> So, I installed Metro again into Glassfish to get JAXB 2.2.3 but now
> when I compile my own Java code; I always get java.lang.Verify errors.
>
> I tried installing the latest Metro distribution into
> $JDK_HOME/lib/endorsed on my Mac (latest Apple JDK) and I see it being
> pulled into my classpath properly in Eclipse.
> However; I still get similar errors after I recompile; restart
> Glassfish and redeploy.
>
> Has anyone ever tried this and succeeded?
>
> ------------------------------------------------------------------------
> *From:* Ronak Patel <ronak2121_at_yahoo.com>
> *To:* "users_at_jersey.java.net" <users_at_jersey.java.net>
> *Sent:* Monday, March 28, 2011 8:47 AM
> *Subject:* [Jersey] Re: Fw: JAXBJSONContext in Glassfish 3.1
>
> All,
>
> I've played with many different configurations and only one seemed to
> work (bundle everything with the war which bloats my war files from 8
> MB to 14 MB).
>
> I am trying to put JAXB 2.1.13 API in the
> ${Glassfish.home}/glassfish/lib/endorsed and the JAXB 2.1.13 RI in
> ${Glassfish.home}/glassfish/lib.
>
> What should I do now? I'm tempted to downgrade back to Glassfish 3.0.1
> if I cannot get this resolved by today.
>
> I always get this exception:
>
> Could not instantiate bean class
> [com.snocell.resort.controller.NaturalJAXBProvider]: Constructor threw
> exception; nested exception is java.lang.RuntimeException: NATURAL
> JSON notation configured, but JAXB RI 2.1.10 not found. For the recent
> builds to get this working correctly, you need even at least JAXB
> version 2.1.12. Please add it to your classpath!. Please see
> server.log for more details.
>
>
>
>
>
>
>
> *From:* Ronak Patel <ronak2121_at_yahoo.com>
>
> *To:* "users_at_jersey.java.net" <users_at_jersey.java.net>
> *Sent:* Sunday, March 27, 2011 8:31 AM
> *Subject:* Re: [Jersey] Fw: JAXBJSONContext in Glassfish 3.1
>
> Well I spent the whole day swapping out different versions of JAXB in
> and out...and am getting tired.
> Have you ever been successful deploying a JAX-RS Jersey Service on
> Glassfish 3.1 with JDK 6 update 24?
>
> This is a VERY common configuration so what's the deal?
>
> ------------------------------------------------------------------------
> *From:* Tatu Saloranta <tsaloranta_at_gmail.com>
> *To:* Ronak Patel <ronak2121_at_yahoo.com>
> *Sent:* Saturday, March 26, 2011 10:55 AM
> *Subject:* Re: [Jersey] JAXBJSONContext in Glassfish 3.1
>
> On Sat, Mar 26, 2011 at 10:22 AM, Ronak Patel <ronak2121_at_yahoo.com
> <mailto:ronak2121_at_yahoo.com>> wrote:
> > Hi All,
> > I'm trying to upgrade to the latest versions of HIbernate 3.6, Hibernate
> > Search, Hibernate Spatial and Glassfish 3.1.
> > My RESTful Web Service defines custom JAXBJSONContexts for my JAXB
> beans.
> > Everything used to work fine on Glassfish 3.0.1.
> > However, after upgrading to Glassfish 3.1, I'm getting the following
> errors:
> > 2011-03-22 05:39:17,322 ERROR ContextLoader:225 - Context initialization
> > failed
> > java.lang.VerifyError: (class:
> com/events/controller/NaturalJAXBProvider,
> > method: <init> signature: ()V) Bad type in putfield/putstatic
> > I am running JDK 1.6 on MacOSX.
> > Has anyone ever dealt with this?
> > How do you solve this?
>
> Nope, but that looks like a library version conflict: version used to
> compile one of jars differs from one with which it is deployed. In
> this case some type passed to construct of class being mentioned.
>
> -+ Tatu +-
>
>
>
>
>
>
>
>
>
>
>
>