XFire
  1. XFire
  2. XFIRE-887

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

        Hide
        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
        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
        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
        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
        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
        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
        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
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated: