XFire

NullPointerException with hexBinary attribute

Details

  • Type: Bug Bug
  • Status: Open Open
  • Priority: Blocker Blocker
  • Resolution: Unresolved
  • Affects Version/s: 1.2.4
  • Fix Version/s: None
  • Component/s: Aegis Module
  • Labels:
    None
  • Environment:
    Java 1.5, JAXB 2.0.4
  • Number of attachments :
    0

Description

I used wsgen to create a client proxy (jaxb 2.0). I sent a message that contained an object with a null value for an attribute. The attribute is defined as

<xsd:attribute name="info" use="optional">
<xsd:simpleType>
<xsd:restriction base="xsd:hexBinary"/>
</xsd:simpleType>
</xsd:attribute>

It fails. There is no test for null before it tries to marshall the attribute value.

Exception in thread "main" org.codehaus.xfire.XFireRuntimeException: Could not invoke service.. Nested exception is org.codehaus.xfire.fault.XFireFault: Could not marshall type.
org.codehaus.xfire.fault.XFireFault: Could not marshall type.
at org.codehaus.xfire.jaxb2.JaxbType.writeObject(JaxbType.java:258)
at org.codehaus.xfire.aegis.AegisBindingProvider.writeParameter(AegisBindingProvider.java:206)
at org.codehaus.xfire.service.binding.AbstractBinding.writeParameter(AbstractBinding.java:273)
at org.codehaus.xfire.service.binding.WrappedBinding.writeMessage(WrappedBinding.java:89)
at org.codehaus.xfire.soap.SoapSerializer.writeMessage(SoapSerializer.java:80)
at org.codehaus.xfire.transport.http.HttpChannel.writeWithoutAttachments(HttpChannel.java:56)
at org.codehaus.xfire.transport.http.CommonsHttpMessageSender.getByteArrayRequestEntity(CommonsHttpMessageSender.java:382)
at org.codehaus.xfire.transport.http.CommonsHttpMessageSender.send(CommonsHttpMessageSender.java:320)
at org.codehaus.xfire.transport.http.HttpChannel.sendViaClient(HttpChannel.java:123)
at org.codehaus.xfire.transport.http.HttpChannel.send(HttpChannel.java:48)
at org.codehaus.xfire.handler.OutMessageSender.invoke(OutMessageSender.java:26)
at org.codehaus.xfire.handler.HandlerPipeline.invoke(HandlerPipeline.java:131)
at org.codehaus.xfire.client.Invocation.invoke(Invocation.java:75)
at org.codehaus.xfire.client.Client.invoke(Client.java:335)
at org.codehaus.xfire.client.XFireProxy.handleRequest(XFireProxy.java:77)
at org.codehaus.xfire.client.XFireProxy.invoke(XFireProxy.java:57)
at $Proxy30.release(Unknown Source)
at sampleapps.SvcClient.ClientApp.release(ClientApp.java:146)
at sampleapps.SvcClient.ClientApp.go(ClientApp.java:66)
at sampleapps.SvcClient.ClientApp.main(ClientApp.java:152)
Caused by: javax.xml.bind.MarshalException

  • with linked exception:
    [com.sun.xml.bind.api.AccessorException: java.lang.NullPointerException]
    at com.sun.xml.bind.v2.runtime.MarshallerImpl.write(MarshallerImpl.java:295)
    at com.sun.xml.bind.v2.runtime.MarshallerImpl.marshal(MarshallerImpl.java:148)
    at org.codehaus.xfire.jaxb2.JaxbType.writeObject(JaxbType.java:253)
    ... 19 more
    Caused by: com.sun.xml.bind.api.AccessorException: java.lang.NullPointerException
    at com.sun.xml.bind.v2.runtime.XMLSerializer.reportError(XMLSerializer.java:223)
    at com.sun.xml.bind.v2.runtime.XMLSerializer.reportError(XMLSerializer.java:238)
    at com.sun.xml.bind.v2.runtime.ClassBeanInfoImpl.serializeAttributes(ClassBeanInfoImpl.java:302)
    at com.sun.xml.bind.v2.runtime.XMLSerializer.childAsXsiType(XMLSerializer.java:617)
    at com.sun.xml.bind.v2.runtime.ElementBeanInfoImpl$1.serializeBody(ElementBeanInfoImpl.java:93)
    at com.sun.xml.bind.v2.runtime.ElementBeanInfoImpl$1.serializeBody(ElementBeanInfoImpl.java:127)
    at com.sun.xml.bind.v2.runtime.ElementBeanInfoImpl.serializeBody(ElementBeanInfoImpl.java:244)
    at com.sun.xml.bind.v2.runtime.ElementBeanInfoImpl.serializeRoot(ElementBeanInfoImpl.java:251)
    at com.sun.xml.bind.v2.runtime.ElementBeanInfoImpl.serializeRoot(ElementBeanInfoImpl.java:33)
    at com.sun.xml.bind.v2.runtime.XMLSerializer.childAsRoot(XMLSerializer.java:461)
    at com.sun.xml.bind.v2.runtime.MarshallerImpl.write(MarshallerImpl.java:292)
    ... 21 more
    Caused by: com.sun.xml.bind.api.AccessorException: java.lang.NullPointerException
    at com.sun.xml.bind.v2.runtime.reflect.AdaptedAccessor.get(AdaptedAccessor.java:33)
    at com.sun.xml.bind.v2.runtime.reflect.TransducedAccessor$CompositeTransducedAccessorImpl.print(TransducedAccessor.java:199)
    at com.sun.xml.bind.v2.runtime.property.AttributeProperty.serializeAttributes(AttributeProperty.java:61)
    at com.sun.xml.bind.v2.runtime.ClassBeanInfoImpl.serializeAttributes(ClassBeanInfoImpl.java:295)
    ... 29 more
    Caused by: java.lang.NullPointerException
    at com.sun.xml.bind.DatatypeConverterImpl.printHexBinary(DatatypeConverterImpl.java:382)
    at javax.xml.bind.DatatypeConverter.printHexBinary(DatatypeConverter.java:560)
    at javax.xml.bind.annotation.adapters.HexBinaryAdapter.marshal(HexBinaryAdapter.java:25)
    at javax.xml.bind.annotation.adapters.HexBinaryAdapter.marshal(HexBinaryAdapter.java:19)
    at com.sun.xml.bind.v2.runtime.reflect.AdaptedAccessor.get(AdaptedAccessor.java:31)
    ... 32 more

This is a blocker for clients of my application because typically this attribute is not supplied. The schema is from an ECMA standard and I can't change the data type. This particular object is sent on pretty much every call to my web service.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
otexier added a comment -

I don't think it is a XFire bug, because I had exactly the same behavior, and fixed it by switching to jaxb 2.1.3.
(The exception aroused with optional hexbinary attribute)

In my case i am sure that JAXB 2.0.5 (which was my previous lib) is the culprit.

Of course, due to java endorsing mechanism, you must add a directive to your jvm in order to use jaxb 2.1.3 ( -Djava.endorsed.dirs=somewhereInYourProject/endorsed) and put the new jaxb-api.jar, jaxb-impl.jar and jaxb-xjc.jar in your endorsed dir)

Could you please confirm that ? (for Dan to close this issue)

Show
otexier added a comment - I don't think it is a XFire bug, because I had exactly the same behavior, and fixed it by switching to jaxb 2.1.3. (The exception aroused with optional hexbinary attribute) In my case i am sure that JAXB 2.0.5 (which was my previous lib) is the culprit. Of course, due to java endorsing mechanism, you must add a directive to your jvm in order to use jaxb 2.1.3 ( -Djava.endorsed.dirs=somewhereInYourProject/endorsed) and put the new jaxb-api.jar, jaxb-impl.jar and jaxb-xjc.jar in your endorsed dir) Could you please confirm that ? (for Dan to close this issue)
Hide
Permalink
Matthew added a comment -

I did test my stuff using jaxb 2.1.3 and XFire 1.2.5 and it works now. I also am still on Java 1.5 so I did not have to mess with endorsed.dirs yet.

I still wonder if the xfire code should be testing for null before sending the attribute off to the marshaller. Maybe just look at the code and see what you think. I will accept it either way.

My last concern is if jaxb 2.1.3 is 100% compatible with XFire. I only tested this with a simple client app. I haven't put it on the server yet. It would be nice if this version were included in the distribution - meaning that it was fully tested.

Thanks!

Show
Matthew added a comment - I did test my stuff using jaxb 2.1.3 and XFire 1.2.5 and it works now. I also am still on Java 1.5 so I did not have to mess with endorsed.dirs yet. I still wonder if the xfire code should be testing for null before sending the attribute off to the marshaller. Maybe just look at the code and see what you think. I will accept it either way. My last concern is if jaxb 2.1.3 is 100% compatible with XFire. I only tested this with a simple client app. I haven't put it on the server yet. It would be nice if this version were included in the distribution - meaning that it was fully tested. Thanks!
Hide
Permalink
Steven E. Harris added a comment -

I'm seeing the same behavior with CXF, and my schema has similar particles: an optional attribute of type "xs:hexBinary" – or a restriction thereof. I've tried to find some way to incorporate the updated JAXB artifacts you mention, but I haven't figured out how to force Maven to override these transitive dependency versions.

I did try just dropping the jaxb-impl-2.1.3.jar into my project WAR; Java threw a LinkageError, complaining that other parts of the system wanted version 2.0 of the library, and mentioned using the "endorsed" directory. What a headache.

Are we sure this isn't a problem with XFire (or CXF)? The only similar bug I found in Sun's database is 6492933:

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6492933

That one was closed at the end of February and declared as not being reproducible with the then-latest implementation.

Show
Steven E. Harris added a comment - I'm seeing the same behavior with CXF, and my schema has similar particles: an optional attribute of type "xs:hexBinary" – or a restriction thereof. I've tried to find some way to incorporate the updated JAXB artifacts you mention, but I haven't figured out how to force Maven to override these transitive dependency versions. I did try just dropping the jaxb-impl-2.1.3.jar into my project WAR; Java threw a LinkageError, complaining that other parts of the system wanted version 2.0 of the library, and mentioned using the "endorsed" directory. What a headache. Are we sure this isn't a problem with XFire (or CXF)? The only similar bug I found in Sun's database is 6492933: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6492933 That one was closed at the end of February and declared as not being reproducible with the then-latest implementation.
Hide
Permalink
Dan Diephouse added a comment -

Steven - are you running on Java 6? Unfortunately Java 6 comes prebundled with JAXB 2.0 so thats probably causing the conflict.

Show
Dan Diephouse added a comment - Steven - are you running on Java 6? Unfortunately Java 6 comes prebundled with JAXB 2.0 so thats probably causing the conflict.
Hide
Permalink
Steven E. Harris added a comment -

Yes, I'm running the latest Java 6 available.

I'm a little confused, though. My CXF project winds up including three JAXB-related JARs by virtue of Maven's transitive dependencies; I'm not even sure which artifacts are pulling them in. If I'm running Java 6, does that mean that my JVM is ignoring those JARs? How much of JAXB is built-in, as you allude above, versus being provided by supplementary JARs?

Show
Steven E. Harris added a comment - Yes, I'm running the latest Java 6 available. I'm a little confused, though. My CXF project winds up including three JAXB-related JARs by virtue of Maven's transitive dependencies; I'm not even sure which artifacts are pulling them in. If I'm running Java 6, does that mean that my JVM is ignoring those JARs? How much of JAXB is built-in, as you allude above, versus being provided by supplementary JARs?
Hide
Permalink
otexier added a comment -

All jaxb 2.0 is included in java6, and NOTHING from jaxb 2.1

According to me, you have to :

  • wait for java 7
  • force the use of specific jaxb 2.1 jars with -Djava.endorsed.dirs. I don't know maven enough to know how to do that, but it is a java option, so it must be possible.

Sadly, i don't see any other way, perhaps are they ?

Show
otexier added a comment - All jaxb 2.0 is included in java6, and NOTHING from jaxb 2.1 According to me, you have to : wait for java 7 force the use of specific jaxb 2.1 jars with -Djava.endorsed.dirs. I don't know maven enough to know how to do that, but it is a java option, so it must be possible. Sadly, i don't see any other way, perhaps are they ?
Hide
Permalink
otexier added a comment -

I did not see the xfire code, but if is is only a nullPointer to test, IMO perhaps it is a good idea to fix it, because java6 is here for a long time, it will avoid many similar jiras ...

Show
otexier added a comment - I did not see the xfire code, but if is is only a nullPointer to test, IMO perhaps it is a good idea to fix it, because java6 is here for a long time, it will avoid many similar jiras ...

People

  • Assignee:
    Dan Diephouse
    Reporter:
    Matthew
Vote (0)
Watch (2)

Dates

  • Created:
    Updated: