Search:

This looks similar to an error that spring-ws starting getting with castor 1.2 - which has been fixed in recent versions of spring-ws.

For what it is worth...

If you're using the MessageDispatcherServlet or the JMS-based WebServiceMessageDrivenBean, then it will automatically detect a top-level bean with the name of message factory. So something like the...

I suspect that is the problem too. By default spring-ws will use a SAAJ message factory which will effectively parse your 1MB request into a dom-like tree before transforming it to whatever your...

My thought on your #1 item is it probably doesn't matter too much either way. Depending on how many different technologies you want to deal with XML/Java bindings, and which ones you are using, you...

If you return false in your handleRequest, the endpoint will never get called and your interceptor will need to build the soap fault itself. You can get the response from the message context, and...

I raised a Jira issue for this, see: http://jira.springframework.org/browse/SWS-359

See my response in http://forum.springframework.org/showthread.php?p=181732&posted=1#post181732

What kind of Marshaller are you using? I have just been able to reproduce this using a CastorMarshaller, but I haven't tried other kinds of Marshallers.

Arjen - it looks to me like...

If you're using the axiom msg factory, I doubt use of any of the payload root endpoint mappers (qname or annotation) would be much of a perf hit even with big payloads. I say that because the soap...

The spring-ws api does allow you to gain access to the nested headers, but you have to end up using the Axiom API (or SAAJ I assume if not using Axiom) directly once you get ahold of the underlying...

Spring-ws does not support castor 1.2 yet. There is an open jira issue at
http://jira.springframework.org/browse/SWS-287. You could patch spring-ws locally with the patch in the jira issue if you...

Fixing the link in my post: http://kontrawize.blogs.com/kontrawize/2007/10/the-trouble-wit.html

I ran into this problem too when using the PayloadValidatingInterceptor to validate against multiple schemas that were all in the same namespace. Due to what looks to be a vagueness in the spec or...

James - I don't know what the final fix will be and when that will be integrated officially. My patch gives one way to address it generally, but still requires the response to be copied into a byte...

James,

There are a couple of related discussions on this, at:
http://forum.springframework.org/showthread.php?t=49586 and
http://forum.springframework.org/showthread.php?t=50967

Arjen - FYI - I was able to find a fairly clean way in AxiomSoapBody (when not doing payload caching) to prevent building an Axiom tree when sending back responses on the server-side as well as when...

couzteau - I've never used the XPath method annotations, so I'm not sure the cause of your error for sure, especially since it apparently worked when using saaj, albeit slow. Your failure seems to...

BTW - Axiom is definitely the way to go with the large messages. Be sure you disable payload caching when you setup the axiom msg factory.

On the server-side axiom will nicely stream the large...

Offhand I'm not sure why you get those errors.

It might be because you're using the reference impl of stax from sun, and I think spring-ws requires the woodstox stax impl.

Assuming you're using...

fbascheper - Good point, I should have.

I've raised a Jira issue at: http://jira.springframework.org/browse/SWS-287

I ran into this the other day. It looks like Castor 1.2 has changed the behavior of ClassDescriptorResolver and Marshaller/Unmarshaller, that doesn't work with the old way spring-ws's...

I had some high performance/throughput needs and was able to get spring-ws to avoid building the response into an axiom tree on the way out, while still being able to use interceptors (as long as...

One way to add custom header info with Axiom is to use the Axiom API directly. At present the spring-ws soap classes do not have this in their public API (see...

Hmm, the filtering classloader seems to work for me just fine without messing up the console or anything. I'm on WLS10 in an EJB container, but that should work with 9.2 or with other containers too...

I think you can use WebLogic's filtering classloader to use Woodstox for your application only, but not affect whatever STAX parser is used by WLS at the system level. I haven't tried this yet, but...