Dan,

I actually got your suggestion working under JBoss 4.0.4GA but am having 
issues with running under Websphere.

I am using the SAAJ api's to send the request to the real server and then 
the generic service takes care of wrapping the security onto the response.

The service interface keeps it really generic by changing the SOAPMessage 
to a string/base64 as needed.
This way any service method can be passed without need to change the 
generic service.

@WebService(name="SAAJGatewayService", 
targetNamespace="http://services.my.namespace";)
public interface SAAJGatewayService {

    String sendMessage (
        @WebParam(name = "message")
        String message);

}

The real service works under Websphere since its not using any of the 
security.
The problem I'm having with the generic service seems to have something to 
do with the SAAJ api's conflicting with the servers j2ee.jar (SOAPMessage, 
SOAPBody, and SOAPPart classes).
I tried having the jars for the SAAJ put on the Websphere server, but now 
it looks like I am having problems mixing com.sun with com.ibm xerces 
parsers.

Without the saaj api on the server, I actually had the response coming 
back to the generic server, but the SoapOutInterceptor is blowing up on:

ExtendedMessage: Interceptor has thrown exception, unwinding 
noworg.w3c.dom.DOMException: HIERARCHY_REQUEST_ERR: An attempt was made to 
insert a node where it is not permitted.
.at org.apache.xerces.dom.CoreDocumentImpl.insertBefore(Unknown Source)
.at org.apache.xerces.dom.NodeImpl.appendChild(Unknown Source)
.at com.ibm
.ws.webservices.engine.xmlsoap.SOAPPart.appendChild(SOAPPart.java:244)
.at 
org.apache.cxf.staxutils.W3CDOMStreamWriter.newChild(W3CDOMStreamWriter.java:82)
.at 
org.apache.cxf.staxutils.W3CDOMStreamWriter.writeStartElement(W3CDOMStreamWriter.java:99)
.at 
org.apache.cxf.binding.soap.interceptor.SoapOutInterceptor.writeSoapEnvelopeStart(SoapOutInterceptor.java:95)
.at 
org.apache.cxf.binding.soap.interceptor.SoapOutInterceptor.handleMessage(SoapOutInterceptor.java:76)
.at 
org.apache.cxf.binding.soap.interceptor.SoapOutInterceptor.handleMessage(SoapOutInterceptor.java:57)
.at 
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:208)
.at 
org.apache.cxf.interceptor.OutgoingChainInterceptor.handleMessage(OutgoingChainInterceptor.java:74)
.at 
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:208)
.at 
org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:77)
.at 
org.apache.cxf.transport.servlet.ServletDestination.doMessage(ServletDestination.java:79)
.at 
org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:264)
.at 
org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:160)
.at 
org.apache.cxf.transport.servlet.AbstractCXFServlet.invoke(AbstractCXFServlet.java:170)
.at 
org.apache.cxf.transport.servlet.AbstractCXFServlet.doPost(AbstractCXFServlet.java:148)
etc....

I am stuck at this point wondering what is happening to the SOAP object 
that could be causing this HIERARCHY_REQUEST_ERR.




Daniel Kulp <[EMAIL PROTECTED]> 
02/05/2008 02:50 PM

To
[email protected]
cc
[EMAIL PROTECTED]
Subject
Re: Deploy my service implementation separately from my security 
configuration?








You MAY be able to do this by writing a completely generic 
Provider<SOAPMessage> based service that just forwards onto another 
service.   The security information would be set on that and the spring 
could configure in a URL to the service it then sends the SOAP messages 
onto.   It would then use the dispatch APIs (or even the straight SAAJ 
apis I think would work if you are talking straight HTTP) to forward the 
SAAJ message onto the real server, get the SAAJ back, and return it 
where the security would do it's thing. 

Dan



On Monday 04 February 2008, [EMAIL PROTECTED] wrote:
> Hello,
>
> I am working with CXF 2.0.4 with javaFirst/Spring/CXF Servlet.
> I have the jaxws setup using Timestamp, Signature, and Encypt.
> I have some customized interceptors and  a handler.
>
> This is all included in one war file (just like the demos) that I
> deploy to JBoss (and eventually Websphere).
>
> I was wondering if its possible to:
> - separate out my service implementation as one war file and my
> security configuration as another war file
>       or
> - have my service endpoint be external from the same JVM that CXF is
> under (the internal endpoint is different from the published external
> endpoint).
>
>
> The goal is to keep the security settings "untouchable" when further
> maintenance/enhancements of the service methods goes forward.
> We don't want to have to worry about the security getting broken once
> we know that its working correctly.
>
> I believe that this is called "hardening" the security.
>
> Any suggestions/readings would really be appreciated.



-- 
J. Daniel Kulp
Principal Engineer, IONA
[EMAIL PROTECTED]
http://www.dankulp.com/blog

Reply via email to