Announcement Announcement Module
Collapse
No announcement yet.
Axiom Exception Resolver - Fault problems Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Axiom Exception Resolver - Fault problems

    I switched from SAAJSoapMessageFactory to the AxiomSOAPMessageFactory (in order to use JiBX marshalling) and when I get web service exceptions they delegate to the exception resolver - but I get the following error:


    IllegalArgumentException: A fully qualified fault code (namespace, prefix, and local part) must be specific for custom fault code.
    at org.springframework.ws.soap.axiom.AxiomSoapMessage $AxiomSoapBody.addFault(AxiomSoapMessage.java:423)


    When this was setup for SAAJ I didn't have a problem with the exception resolver and I made no changes when flipping over to Axiom? How do I fix this? Is there a different exception resolver configuration when using Axiom as opposed to SAAJ?

    any help would be great. thanks!
    Ron

  • #2
    It does not look like you're using the latest snapshots. I can tell by the classname . We now have nightly builds (see http://forum.spring.io/node/18117), which you can download from http://static.springframework.org/ma...gframework/ws/. If you're using maven2, it's easy to depend on the jars you want. If you're using ant, then you must download them yourself; unfortunately there is no all-in-one zip yet. I'm working on that.

    Let me know how those latest snapshots work for you.

    Cheers,

    Comment


    • #3
      Thanks - however, moving open source libraries to my company's network is quite a process - it took me three weeks to get the 'jibx fix' snapshot moved... is the fault problem a known bug?? How can I work around it to continue on without updating my libraries each night!

      thanks
      Ron

      Comment


      • #4
        Well, the fault problem is only showing up because an exception is being thrown somewhere, and that is converted into a fault. So if you (temporarily) remove the exception resolver, you can see what the cause exception is, and we can fix that so that it no longer occurs.

        Comment


        • #5
          That sounds good to me... thanks!

          Comment


          • #6
            endpoint exception resolver required for endpoint?

            I removed the endpoint exception resolver (as suggested) and I started getting null pointer exceptions earlier in the stack (it never got to invoking my endpoint method)... once I re-instated the end point resolver it started getting back to my endpoint again?! SO, it appears the an endpoint resolver is required - if it is not set then a NullPointerException occurs?

            So - any idea what resolver properties are required for the Axiom fault message?

            Has anyone tested using Axiom as the context factory with JiBX as the marshaller?

            thanks
            Ron

            Comment


            • #7
              I will try and create a little app that uses JiBX and axiom ASAP. Right now, I'm trying to make aggregated nightly builds, i.e. one zip that contains everything.

              Comment


              • #8
                axiom-jibx

                FYI - I keep tinkering - I figured out that as long as I mapped at least one exception the exception resolver didn't throw a NullPointerException - so I got past that problem (although, I would still like for the Axiom fault handling bug to be fixed?!).

                That said, I got the round-trip Axiom-based JiBX object marshalling to work (one object in, different object out)... abeit without fault handling.

                Let me know if the fault handling is resolved.

                thanks!
                Ron

                Comment


                • #9
                  Cool, I will investigate the fault handling then.

                  Comment


                  • #10
                    Well, I created a little application that used both Jibx and Axiom, and have no problems, with or without exception handlers. I am using the current code base however, so it could be that the snapshot you use has a bug. Whatever it was, it has been solved now. :-)

                    If you're interested, I can give you the source. Just drop me a line at arjenp at interface21 dot com.

                    I also did some profiling on the codebase, and increased performance quite drastically. See the other "Performance test" thread on this forum.

                    Comment

                    Working...
                    X