Skip to Content.
Sympa Menu

mace-opensaml-users - Re: xml-tooling exception / hack in XSQNameImpl

Subject: OpenSAML user discussion

List archive

Re: xml-tooling exception / hack in XSQNameImpl


Chronological Thread 
  • From: Brent Putman <>
  • To:
  • Subject: Re: xml-tooling exception / hack in XSQNameImpl
  • Date: Wed, 17 Oct 2007 19:16:19 -0400

Sorry for the delay in getting back to you on this, didn't return from the I2MM in San Diego until late Monday night...  See below.


Asa Hardcastle wrote:
Hi all,

I was getting a big fat null pointer exception when processing the following Body of a SOAP response (sent by HP's Select Federation):


      <S:Fault>
         <faultcode>S:Server</faultcode>
         <faultstring>security verification failure</faultstring>
      </S:Fault>
   </S:Body>


It didn't like faultcode or faultstring - I assume because they have no explicit NS prefix. 

I have tracked down the root cause of the NPE bug, but I need to do some more regression testing to verify whether the fix isn't going to cause problems in other areas.  The problem traces all the way back to the AbstractXMLObjectUnmarshaller, which is the superclass of all unmarshallers in the library.   FYI, our java-openws unit test for the SOAP fault case also produces this NPE.  Guess we haven't run or checked the results of the openws tests in awhile... :-(



So in order to get through this problem, I made a small change to a class in XMLTooling.   I have no idea of the implications of this, or whether there is a better way.  Can someone help me out?

No, unless you're seeing a different problem, I don't think this is relevant to addressing the bug at all.  However, (I think?) it's masking it because the unmarshaller calls the setValue(QName), which produces the NPE.   If the code in setValue doesn't run, you'd get no NPE.  But I'm actually not seeing that your change causes the bad code block to not get called.  Note that the QName that we're talking about here is the QName *content* of the faultcode element, not the name of the faultcode element itself.  So the fact that the faultcode has no explicit NS prefix is completely orthogonal to this, as far as I can tell...

As Scott already noted this NPE bug is a completely separate issue from the other bug, which is that the faultcode, faultstring, faultactor, and detail elements are incorrectly implemented as living in the SOAP 1.1 namespace.  I'll fix those shortly as well.



in the java-xmltooling class org.opensaml.xml.schema.impl.XSQNameImpl

OLD:

    /** {@inheritDoc} */
    public void setValue(QName newValue) {
        value = prepareForAssignment(value, newValue);
        addNamespace(new Namespace(value.getNamespaceURI(), value.getPrefix()));
    }


NEW:

    /** {@inheritDoc} */
    public void setValue(QName newValue) {
        // Asa Hardcastle added on October 11, 2007
        if(newValue.getPrefix().trim().length()!=0){
            value = prepareForAssignment(value, newValue);
            addNamespace(new Namespace(value.getNamespaceURI(), value.getPrefix()));
        }
    }




thanks,

asa






--
Asa Hardcastle, Technical Lead, openLiberty ID-WSF ClientLib
Skype: subsystem7





Archive powered by MHonArc 2.6.16.

Top of Page