[GLASSFISH-20507] NullPointerException in RuntimeModelBuilder.java line 195 Created: 10/May/13  Updated: 28/Oct/14

Status: Open
Project: glassfish
Component/s: web_services
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: mkarg Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

GlassFish 3.1.2.2, Win 7 Pro SP 1 (32 Bit), JDK 1.7.0_21


Attachments: GZip Archive GF_20507.tar.gz    
Tags: 4_0_1-approved, incomplete

 Description   

Application is working well on GlassFish 3.1.1, but not on 3.1.2.2!

When deploying on GlassFish 3.1.2.2 instead (with same environmental conditions), it crashes when JAXB-unmarshalling the exact same data! Since it works in GF 3.1.1, it seems GF 3.1.2.2 replaces working parts of JAXB by failing replacements!

Simplified stack trace:

com.sun.xml.bind.v2.model.impl.RuntimeModelBuilder$IDTransducerImpl.parse() (line 195) <--- throws NPE here
com.sun.xml.bind.v2.runtime.reflect.TransducedAccessor$CompositeTransducedAccessorImpl.parse() (line 247)
...
javax.xml.bind.helpers.AbstractUnmarshallerImpl.unmarshal() (line 219)
de.quipsy.util.http.HttpClient (line ...) <--- catched in my code when doing marshaller.unmarshal(InputStream).

Strange but true, this happens only with some XML content, but not with any other. And no, the InputStream is not null.

We cannot migrate from 3.1.1 to 3.1.2.2 because of this issue!



 Comments   
Comment by Martin Grebac [ 13/May/13 ]

Hi, thanks for submission. We can't do anything about it without the (as minimal as possible) reproducible testcase. Have you tried running your application against latest JAXB to verify if the issue is already fixed?

Comment by mkarg [ 13/May/13 ]

The problem is that the fault only happens in the middle of our full-size Enterprise application, which is a rather heavy sized EAR that Needs lots of resources and database tables to get to that Point that is crashing, unfortunately. I do not see any chance to provide a test case. So you need to tell me things I can trace to help you (like enabling Special logging levels). JAXB is the one contained in JRE 7u21. Is that what you mean with "latest" or how to make GlassFish use "latest"?

Comment by mkarg [ 02/Apr/14 ]

Bug still exists in GF 4.0 running on JDK 1.8.0!

This is a showstopper for us to migrate from 3.1.1 to 4.0 or at least 3.1.2.2.

Comment by mkarg [ 02/Apr/14 ]

Unfortunately I cannot test against 4.0.1-nightly-latest due to https://java.net/jira/browse/GLASSFISH-21027. As soon as GLASSFISH-21027 is fixed I will try whether the bug is possibly gone in 4.0.1 (in 4.0.0 it is still existing).

Comment by mkarg [ 03/Apr/14 ]

I found out that the problem can be reproduced in my EAR by the following:

  • Use @XmlID on a public String member of @XmlRootElement class Parent.
  • Use @XmlRefID on @XmlAttribute private Parent myParent within class Child.
  • Child itself is parent to another child, having @XmlID on its own so the Grand Child uses @XmlRefID again, etc.
    -> You get a chain of @XmlID parent – @XmlIDRef child – @XmlIDRef grandchild.

When unmarshalling such a JAXB tree in some cases (more often than not in my application) the failure occurs.

I can proof this by simple removing the @XmlID / @XmlIDRef annoations, which makes the unmarshalling work correctly, but certainly leading to wrong results (included copies of the parents instead of referenced singletons).

We really are stuck with this! It is a total showstopper! Please help us with a fix! If there is anything we can do to speed this up, please tell us right now!

Comment by mkarg [ 03/Apr/14 ]

Test project (WAR file incl. source code and Maven build script demonstrating the bug) sent directory to Iaroslav Savytskyi. The bug only happens with a class uses both, @XmlID and @XmlJavaTypeAdapter.

Comment by mkarg [ 10/Apr/14 ]

Provided WAR file with test code a week ago but did not even get any ack of receipt so far. Possibly you didn't get my emails or your answers are getting lost. Can you please ack here so I know that you received the test code?

Comment by Iaroslav Savytskyi [ 10/Apr/14 ]

User's test case.

Comment by Iaroslav Savytskyi [ 10/Apr/14 ]

Hi,

To be honest I can't promise any terms when we'll be able to start working on this.

Comment by mkarg [ 12/Apr/14 ]

Can you please provide us with a time frame when Oracle might be able to fix this critical bug? I mean, it is OK if this is not solved in the next weeks certainly, but we should have a GlassFish including a fixed JAXB within the next six months if any possible. In the end we talk about a showstopper without any existing workaround.

Comment by mkarg [ 19/May/14 ]

It's been six weeks since last contact so I'd like to kindly ask if meanwhile the planning is done, hence, whether at least Oracle could commit to fix this before GF 4.0.2 GA?

Comment by mkarg [ 20/Jun/14 ]

Another eight weeks later and not even a "ping" echo from Oracle on this crash issue. I wonder what's going on? Given up bug fixing on JAXB or possible the JAXB team sent to holidays in the caribbean sea? :-D

Comment by kdevaras [ 22/Jun/14 ]

The bug has been assigned to me(internally) and I'll be picking up this issue from this week.

Thanks.

Comment by mkarg [ 22/Jun/14 ]

That sounds very promising. I am looking forward to the final solution!

Comment by mkarg [ 05/Aug/14 ]

kdevaras, I really don't want to bother, but I would be totally happy if you could post a status update; thanks!

Comment by kdevaras [ 06/Aug/14 ]

I forgot to update it here.

There are actually a couple of updates.

The NPE is here:
UnmarshallingContext.getInstance().addToIdTable(value);

UnmarshallingContext.getInstance() is null.

An UnmarshallingContext instance is pushed to and popped from a ThreadLocal when entering a method and exiting a method respectively.

While debugging, it appeared that a pop was called out of turn. Hence the getInstance() call returned null.

This issue may be fixed in jaxb 2.2.8/2.2.9 as the Threadlocal strategy was reworked for an NPE. I'm trying to verify with that version.

Thanks.

Comment by kdevaras [ 06/Aug/14 ]

Btw, Glassfish seems to be using 2.2.5-5.

Comment by mkarg [ 06/Aug/14 ]

Thanks for the status update.

As GF-4.0.1 is soon to come, can you please inform GF team that 4.0.1 must not be published before your fix is merged into GF? I think it is really essential for GF as JAXB is a core technology. Without a recent status update they may think there will be no fix in time and publish without pulling latest JAXB. Thanks.

Comment by kdevaras [ 06/Aug/14 ]

Not sure if I can ask that.

Even if the fix is merged after the release, I'll try to provide a patch that can applied.

Thanks.

Comment by mkarg [ 09/Sep/14 ]

kdevaras, I'm currently reviewing the list of issues I reported against GF4 and kindly like to ask for a status update on the following of your above comments: "This issue may be fixed in jaxb 2.2.8/2.2.9 as the Threadlocal strategy was reworked for an NPE. I'm trying to verify with that version.". Did you find the time for this test and hence can you confirm that the problem is gone in JAXB 2.2.9? Also I wonder what the correct way is to ask the GlassFish team to incorporate at least 2.2.9 in GF 4.0.1 / 4.1 (whom to ask for that)?

Comment by kdevaras [ 28/Oct/14 ]

I got caught up with urgent issues. I'm now back to this one.

Strangely, I don't seem to be able to reproduce this issue anymore.
I'm using the same steps you described in go.cmd. I've checked on both 3.1.2.7 and 3.1.2.8.

Generated at Thu May 28 12:56:14 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.