Thanks for your suggestion Markus! It looks like a WebServiceProvider for either the SAXSource or StreamSource would fit our needs.
However the note regarding developers needing to manually handle SOAP envelopes leads me to assume that everything WS-SecurityPolicy related needs to be manually handled as well. Would you consider that correct? Kind regards Jesper -----Original Message----- From: Markus Schulz [mailto:m...@onesty-tech.de] Sent: 2. november 2018 09:43 To: users@cxf.apache.org Subject: Re: CXF and possible performance optimizations Am Freitag, 2. November 2018, 06:35:09 CET schrieb Jesper Duelund Isaksen: > Hello! > > I am currently on a project where we are building a platform exposing > a large number of standard WSDL-first SOAP services with typed SEI > classes. The purpose of the platform is to do authentication and > authorization for a large number of users before the users access > external data systems. We are aware that it is not proper usage of > SOAP services however we do not have control over our users. > > We are however experiencing unexpected large size requests and > responses to and from the platform (10-60 MB SOAP messages) and we are > seeing that: > > > * It seems that all these large requests take up a large amount of > memory since they are unmarshalled into Java object hierarchies and > marshalled back to XML when the requests and responses are forwarded. > * A large amount of CPU time is used for garbage collecting of all > these objects. > > Additionally we are using the WS-SecurityPolicy functionality handled > by Apache CXF since we in a WS-Trust-like setup for most of the > services. > > So the question is, is there any way we can avoid generating the Java > object hierarchies and keep the using CXF for handling security? you can switch to dynamic SEIs with a provider based implementations. take a look at http://cxf.apache.org/docs/provider-services.html. you can still unmarshal on demand the request xml into a java object structure. regards msc
