Dan
Ok - so I switched back to using the Spring Framework's XMLValidator instead
of SAXParser. I had switched to SAXParser because I couldn't customize
XMLValidator. But using it combined with adding the
schema-validation-enabled property to my spring.xml means it checks the
schema of the Soap body and complains when it should complain without me
having to do any additional processing. This is such great news - I spun my
wheels for weeks on this only to find out the solution was this simple.
Thank you thank you thank you!!
Brenda
Brenda Coulson wrote:
>
> Dan
>
> sorry to bother you again - just a little confused. So I am using JAXWS
> endpoints and I added the line below to my spring.xml file and it didn't
> make a difference. Do I still need to add the interceptor you mentioned
> before? Your recent message implies I should be able to acheive what I
> want without the additional intereceptor. I do not need to accept invalid
> Soap messages - my original problem is that the validator is not
> complaining. Sorry to bother you! Your help has been invaluable. here is
> my endpoint configuration:
>
> <jaxws:endpoint id="armService" implementor="#armServiceImpl" address="/"
> wsdlLocation="#wsdlLocation">
> <jaxws:inInterceptors>
> <ref bean="exceptionScrubber" />
> <ref bean="serviceValidationInInterceptor" />
> <ref bean="agencyValidationInInterceptor" />
> <ref bean="usernameInterceptor" />
> </jaxws:inInterceptors>
> <jaxws:outInterceptors>
> <ref bean="mtomForceInterceptor" />
> <ref bean="serviceValidationOutInterceptor" />
> </jaxws:outInterceptors>
> <jaxws:outFaultInterceptors>
> <ref bean="mtomFaultForceInterceptor" />
> </jaxws:outFaultInterceptors>
> <jaxws:properties>
> <entry key="mtom-enabled" value="true" />
> <entry key="schema-validation-enabled" value="true" />
> </jaxws:properties>
> </jaxws:endpoint>
>
> dkulp wrote:
>>
>> On Thu October 22 2009 5:08:26 pm Brenda Coulson wrote:
>>> Dan
>>>
>>> This does help enormously. I need to process my options to figure out
>>> which
>>> works best. Our system already runs like a dog so performance is a real
>>> issue. Just a quick question - since the Soap message I am receiving is
>>> technically wrong, is there any way to get the validator/parser to choke
>>> at
>>> that point - ie if my soap body is not namespace-qualified? That seems
>>> like
>>> the easiest thing to do and something that a web service processor
>>> should
>>> automatically have in place?
>>
>> If using JAXB databinding (default) or XMLBeans, just turn on schema
>> validation.
>>
>> <jaxws:endpoint name="{http://apache.org/hello_world_soap_http}SoapPort";
>> wsdlLocation="wsdl/hello_world.wsdl"
>> ......>
>> <jaxws:properties>
>> <entry key="schema-validation-enabled" value="true" />
>> </jaxws:properties>
>> </jaxws:endpoint>
>>
>> That should automatically catch and schema related issues and send an
>> exception back.
>>
>> If using Aegis, not much can be done until CXF 2.3. :-(
>>
>> For Provider based endpoints, there in the latest SNAPSHOTS that turn on
>> validation with the above flag as well. Not available in a release yet
>> though.
>>
>> Dan
>>
>>
>>
>>>
>>> brenda
>>>
>>> dkulp wrote:
>>> > On Thu October 22 2009 4:31:21 pm Brenda Coulson wrote:
>>> >> That is great to know! I am so confused between the difference
>>> between
>>> >> Interceptors and Handlers and when to use them. Ok so I have a Soap
>>> >> message
>>> >> that I am trying to ultimately validate. However, there are times
>>> when I
>>> >> may receive a message that does not specify the namespace for the
>>> soap
>>> >> payload. Example as follows:
>>> >>
>>> >> <soapenv:Envelope
>>> >> xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/";>
>>> >> <soapenv:Header/>
>>> >> <soapenv:Body>
>>> >> <getReference>
>>> >> <agcHcsId>80640</agcHcsId>
>>> >> </getReference>
>>> >> </soapenv:Body>
>>> >> </soapenv:Envelope>
>>> >
>>> > Oi.. Ick.. Technically, that's an invalid soap message as, according
>>> to
>>> > spec, direct child elements of soap:Body must be namespace qualified.
>>> > But
>>> > let's ignore that issue for a second. :-)
>>> >
>>> >> Technically the XML inside the payload is well-formed so the
>>> validator
>>> >> does
>>> >> not complain. However, there is a required element, referenceId,
>>> >> missing. So as I am validating, I would like to just get to the Soap
>>> >> payload, aka
>>> >>
>>> >> <getReference>
>>> >> <agcHcsId>80640</agcHcsId>
>>> >> </getReference>
>>> >>
>>> >> And validate it against my schema, regardless of whether or no the
>>> >> namespace is specified. I need to do this for all methods on my web
>>> >> service, one of which has a Soap attachment, which based on other
>>> posts
>>> >> I
>>> >> saw, may cause some problems with the different processing phases.
>>> >>
>>> >> Net effect is how do I just get the Soap payload part of the message?
>>> If
>>> >> I
>>> >> don't need to use a Logical Handler, great. If I do, great too. Does
>>> not
>>> >> matter to me.
>>> >
>>> > OK. There are a couple of options that you could pursue for this.
>>> >
>>> > 1) You COULD write an interceptor that lives just before the
>>> > DocLiteralInInterceptor that takes the XMLStreamReader and wrappers it
>>> > with a
>>> > new XMLStreamReader that would "correct" the namespace issue.
>>> (override
>>> > the
>>> > getNamespace calls and such to return the correct value). If you do
>>> > that,
>>> > you could just turn on the CXF built in schema validation stuff.
>>> See:
>>> > http://cxf.apache.org/faq.html
>>> > That option would have the best performance as the built in jaxb
>>> > validation
>>> > doesn't need to load the whole message while unmarshalling.
>>> >
>>> > 2) Next easiest is to configure in the SAAJInInterceptor (or have your
>>> > interceptor call it) and work with the SAAJ model directly. Your
>>> > interceptor
>>> > would just look something like:
>>> >
>>> >
>>> > public MyInterceptor() {
>>> > super(Phase.PRE_PROTOCOL);
>>> > getAfter().add(SAAJInInterceptor.class.getName());
>>> > }
>>> > public void handleMessage(SoapMessage msg) throws Fault {
>>> > SOAPMessage doc = msg.getContent(SOAPMessage.class);
>>> > if (doc == null) {
>>> > saajIn.handleMessage(msg);
>>> > doc = msg.getContent(SOAPMessage.class);
>>> > }
>>> > //process doc here
>>> > }
>>> >
>>> > Not quite as good as it loads the whole message into memory, but
>>> > certainly easy to work with.
>>> >
>>> > 3) Register a jaxws LogicalHandler with the endpoint. The
>>> > LogicalMessageContext that is passed in has a
>>> > getLogicalMessage().getPayload()
>>> > method that returns a Source. (I think a DOMSource is what we
>>> return)
>>> > Advantage here is that it would be portable to other jaxws
>>> > implementations.
>>> > Disadvantage is that performance is way worse than option 2. Also,
>>> > JAX-WS
>>> > handlers have to be registered per-endpoint whereas an interceptor can
>>> be
>>> > configured on the Bus and thus be more "global".
>>> >
>>> > Hope that helps!
>>>
>>
>> --
>> Daniel Kulp
>> dk...@apache.org
>> http://www.dankulp.com/blog
>>
>>
>
>
--
View this message in context:
http://www.nabble.com/LogicalHandlerInInterceptor-examples-tp26012831p26025204.html
Sent from the cxf-user mailing list archive at Nabble.com.
