Issue Details (XML | Word | Printable)

Key: GLASSFISH-19287
Type: Bug Bug
Status: Resolved Resolved
Resolution: Fixed
Priority: Blocker Blocker
Assignee: Iaroslav Savytskyi
Reporter: bthalmayr
Votes: 0
Watchers: 1
Operations

If you were logged in you would be able to see more operations.
glassfish

JAXB 1.0 based applications do not work due to JAXB-899

Created: 05/Nov/12 11:47 AM   Updated: 17/Jan/13 02:52 PM   Resolved: 17/Jan/13 02:52 PM
Component/s: web_services
Affects Version/s: 3.1.2.2
Fix Version/s: None

Time Tracking:
Not Specified

Tags: jaxb metro-gf3125
Participants: bthalmayr, Iaroslav Savytskyi, kumara and Martin Grebac


 Description  « Hide

Having a web-application which uses classes created by JAXB 1.0.x does not run on GF 3.1.2.2 due to bug JAXB-899

Copying stacktrace from JAXB-899

Caused by: javax.xml.bind.JAXBException

  • with linked exception:
    [java.lang.NoSuchFieldError: theInstance]
    at com.sun.xml.bind.ContextFactory_1_0_1.createContext(ContextFactory_1_0_1.java:100)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
    at java.lang.reflect.Method.invoke(Unknown Source)
    at javax.xml.bind.ContextFinder.newInstance(Unknown Source)
    at javax.xml.bind.ContextFinder.find(Unknown Source)
    at javax.xml.bind.JAXBContext.newInstance(Unknown Source)
    at javax.xml.bind.JAXBContext.newInstance(Unknown Source)
    at javax.xml.bind.JAXBContext.newInstance(Unknown Source)
    at mypackage.JAXBContextWrapper.getInstance(JAXBContextWrapper.java:57)
    at mypackage.JAXBObjectWrapper.getUnmarshallerStatic(JAXBObjectWrapper.java:161)
    at mypackage.JAXBObjectWrapper.unmarshalStatic(JAXBObjectWrapper.java:184)
    at mypackage.JAXBObjectWrapper.<init>(JAXBObjectWrapper.java:67)
    ... 11 more
    Caused by: java.lang.NoSuchFieldError: theInstance
    at mypackage.generated.jaxb104.impl.runtime.DefaultJAXBContextImpl.<init>(DefaultJAXBContextImpl.java:50)
    at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
    at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source)
    at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source)
    at java.lang.reflect.Constructor.newInstance(Unknown Source)
    at com.sun.xml.bind.ContextFactory_1_0_1.createContext(ContextFactory_1_0_1.java:94)
    ... 24 more


Iaroslav Savytskyi added a comment - 17/Jan/13 02:52 PM

Should be integrated into 3.1.2.5 GF version.
JAXB SVN revision: 3997


Iaroslav Savytskyi added a comment - 20/Dec/12 01:24 PM

Hi,

I've merged 3918 revision to jaxb 2.2.5.3 version.


Martin Grebac added a comment - 21/Nov/12 04:32 PM

Hi, went again through this more properly - the fix for this went into 2.2.6:

Revision: 3918
Author: snajper
Date: 2012-05-11 15:20:09 UTC
Log Message:
------------
fix for JAXB-899 - keep the jaxb1 required methods, but deprecate all of them + the class -> issue 723 will remain closed because we removed usage of these duplications from the RI2 code and deprecation should (hopefully) make sure we don't start using them again
the whole class should be refactored away eventually in the future - requires little api update since currently it's impossible to reuse the API DTC instead of the RI's one

The bug is not about missing class (thus it is not osgi issue), but about missing theInstance method which was caused as a regression from trying to merge the DTC implementations used in jaxb api/ri. So, I guess the only thing needed is to merge the fix into 2.2.5.x codebase.


Iaroslav Savytskyi added a comment - 21/Nov/12 08:24 AM

Hi, all,

as I understand GF 3.1.2.2 uses JAXB 2.2.5.2 which contains JAXB1 classes. So probably problem is somewhere else. We need testcase to reproduce this bug.


Iaroslav Savytskyi added a comment - 07/Nov/12 10:52 AM

Definitely you are right. May be it's also a good idea to mark jaxb-extra-osgi as 'optional' jar.


Martin Grebac added a comment - 07/Nov/12 10:40 AM

Yardo, as we're defining jaxb-extra-osgi since metro 2.1.1 for backw. compatibility purposes, I think that would be the right place for jaxb1 as well - what do you think?


bthalmayr added a comment - 05/Nov/12 04:06 PM

We try to deliver a JAXB 1.0 based web-application (as we do not have time to migrate it to JAXB 2.0).

As this web-app can be run on fully J2EE compliant container like GF v3 and servlet engines like Tomcat we possibly need to deliver 2 different distro of the application

Old discussion: 'self-contained' vs. 'container-provided' libraries

As JAXB 2.0 should be backward compatible (for all my readings) we actually don't want to bundle any J2EE related libraries with the 'J2EE distro'.


Martin Grebac added a comment - 05/Nov/12 02:36 PM

Yarda, please work with Lukas on getting this fixed in a branch for GF 3.1.2.x patch. Thanks.


kumara added a comment - 05/Nov/12 01:00 PM

-> web_services because glassfish gets jaxb from metro integration handled through web_services sub component.