cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From GavinHogan <Gavin.Ho...@suny.edu>
Subject Re: Deploy my service implementation separately from my security configuration?
Date Wed, 07 May 2008 12:25:39 GMT

I know this is a very old post, but.....

I was wondering if you every got this fully working and if you would be
willing to share you solution.  Our team currently has a similar design
problem and there is a lack of concensus on how to proceed.  A good working
model would be a great place to start.  Or perhaps somebody else has solved
this issue a different way.

Also, our solution would need to guard non CXF services implemented with
XFire which we do not have time to port to CXF at this time.

Thanks

Gavin
 

dkulp wrote:
> 
> 
> Jason,
> 
> No idea what would cause that error.   That said, looking at the stack 
> trace, it seems to be picking up an IBM implementation of SAAJ instead 
> of the Sun one that we ship and test with...
> 
>>  com.ibm.ws.webservices.engine.xmlsoap.SOAPPart
> 
> Maybe a bug in their implementation?   I don't really know.   If you can 
> try and get the sun version used, that might help.   Again, I'm not 
> really sure.   :-(
> 
> Dan
> 
> 
> On Friday 15 February 2008, jason.laskowski@aurora.org wrote:
>> Dan,
>>
>> I really appreciate the way you try to answer everyone's questions on
>> this list!
>>
>> I can see from the logs that the message coming back from the
>> real/internal service are identical between JBoss and Websphere.
>> The response is getting back to the generic security service in the
>> same way (as far as I can tell).
>> I am still sorting out what each interceptor is for, etc.
>>
>> Update: On the shared library in Websphere (version is 6.1.0.11) we
>> had an older wsdl4j-1.5.2.jar so I had it replaced with the correct
>> 1.6.1 version and retested.
>> Now I am getting a different error in the same SoapOutInterceptor on
>> the generic security service (actually my version of it
>> MySoapOutInterceptor).
>>
>> I have all of the required jars in my deployed project, but I'm not
>> sure which ones are being overridden by the Websphere servers
>> classloader. Are there any other jars (besides the wsdl4j-1.6.1.jar) 
>> that need to be put on the shared library to correct classloader
>> issues?
>>
>> Here is the latest error that comes up with the 1.6.1 version of
>> wsdl4j jar:
>>
>>  Trace: 2008/02/15 10:21:20.634 01 t=AC75E0 c=UNK key=P8 (13007002)
>>    ThreadId: 0000001d
>>    FunctionName: doIntercept
>>    SourceId: org.apache.cxf.phase.PhaseInterceptorChain
>>    Category: INFO
>>    ExtendedMessage: Interceptor has thrown exception, unwinding
>> noworg.w3c.dom.DOMException: HIERARCHY_REQUEST_ERR: An attempt was ma
>>  de 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.ja
>>va:244) at
>> org.apache.cxf.staxutils.W3CDOMStreamWriter.newChild(W3CDOMStreamWrite
>>r.java:82) at
>> org.apache.cxf.staxutils.W3CDOMStreamWriter.writeStartElement(W3CDOMSt
>>reamWriter.java:99) at
>> org.aurora.saaj_gateway.interceptors.MySoapOutInterceptor.writeSoapEnv
>>elopeStart(MySoapOutInterceptor.java:132) at
>> org.aurora.saaj_gateway.interceptors.MySoapOutInterceptor.handleMessag
>>e(MySoapOutInterceptor.java:108) at
>> org.aurora.saaj_gateway.interceptors.MySoapOutInterceptor.handleMessag
>>e(MySoapOutInterceptor.java:47) at
>> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseIntercepto
>>rChain.java:208) at
>> org.apache.cxf.interceptor.OutgoingChainInterceptor.handleMessage(Outg
>>oingChainInterceptor.java:74) at
>> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseIntercepto
>>rChain.java:208) at
>> org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitia
>>tionObserver.java:77) at
>> org.apache.cxf.transport.servlet.ServletDestination.doMessage(ServletD
>>estination.java:79) at
>> org.apache.cxf.transport.servlet.ServletController.invokeDestination(S
>>ervletController.java:264) at
>> org.apache.cxf.transport.servlet.ServletController.invoke(ServletContr
>>oller.java:160) at
>> org.apache.cxf.transport.servlet.AbstractCXFServlet.invoke(AbstractCXF
>>Servlet.java:170) at
>> org.apache.cxf.transport.servlet.AbstractCXFServlet.doPost(AbstractCXF
>>Servlet.java:148) at
>> javax.servlet.http.HttpServlet.service(HttpServlet.java:763) at
>> javax.servlet.http.HttpServlet.service(HttpServlet.java:856) at
>> com.ibm.ws.webcontainer.servlet.ServletWrapper.service(ServletWrapper.
>>java:989) at
>> com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWr
>>apper.java:501) at
>> com.ibm.ws.wswebcontainer.servlet.ServletWrapper.handleRequest(Servlet
>>Wrapper.java:464) at
>> com.ibm.ws.webcontainer.webapp.WebApp.handleRequest(WebApp.java:3276)
>>         at
>> com.ibm.ws.webcontainer.webapp.WebGroup.handleRequest(WebGroup.java:26
>>7) at
>> com.ibm.ws.webcontainer.WebContainer.handleRequest(WebContainer.java:8
>>11) at
>> com.ibm.ws.wswebcontainer.WebContainer.handleRequest(WebContainer.java
>>:1455) at
>> com.ibm.ws.webcontainer.channel.WCChannelLink.ready(WCChannelLink.java
>>:113) at
>> com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleDiscriminat
>>ion(HttpInboundLink.java:454) at
>> com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleNewInformat
>>ion(HttpInboundLink.java:383) at
>> com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.ready(HttpInbound
>>Link.java:263) at
>> com.ibm.ws390.channel.xmem.XMemConnLink.ready(XMemConnLink.java:788)
>>         at
>> com.ibm.ws390.xmem.XMemSRBridgeImpl.httpinvoke(XMemSRBridgeImpl.java:2
>>30) at
>> com.ibm.ws390.xmem.XMemSRCppUtilities.httpinvoke(XMemSRCppUtilities.ja
>>va:74) at com.ibm.ws390.orb.ServerRegionBridge.httpinvoke(Unknown
>> Source) at com.ibm.ws390.orb.ORBEJSBridge.httpinvoke(Unknown Source)
>> at sun.reflect.GeneratedMethodAccessor53.invoke(Unknown Source) at
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccess
>>orImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:615)
>>         at
>> com.ibm.ws390.orb.parameters.HTTPInvoke.HTTPInvokeParmSetter(HTTPInvok
>>e.java:105) at
>> com.ibm.ws390.orb.CommonBridge.nativeRunApplicationThread(Native
>> Method) at com.ibm.ws390.orb.CommonBridge.runApplicationThread(Unknown
>> Source)
>>         at
>> com.ibm.ws.util.ThreadPool$ZOSWorker.run(ThreadPool.java:1666)
>>
>>
>>
>>
>>
>>
>>
>> Daniel Kulp <dkulp@apache.org>
>> 02/14/2008 02:04 PM
>> Please respond to
>> cxf-user@incubator.apache.org
>>
>>
>> To
>> cxf-user@incubator.apache.org
>> cc
>>
>> Subject
>> Re: Deploy my service implementation separately from my security
>> configuration?
>>
>>
>>
>>
>>
>>
>>
>>
>> Did you check all the information about websphere at:
>> http://cwiki.apache.org/CXF20DOC/appserverguide.html
>>
>> Honestly, I don't know what would cause that either.   You might want
>> to try a wireshark dump or message log or something to see how
>> different the SOAP message coming back from the server is as compared
>> to JBoss. That might give a clue.
>>
>> Dan
>>
>> On Wednesday 13 February 2008, jason.laskowski@aurora.org wrote:
>> > 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:24
>> >4) .at
>> > org.apache.cxf.staxutils.W3CDOMStreamWriter.newChild(W3CDOMStreamWri
>> >te r.java:82) .at
>> > org.apache.cxf.staxutils.W3CDOMStreamWriter.writeStartElement(W3CDOM
>> >St reamWriter.java:99) .at
>> > org.apache.cxf.binding.soap.interceptor.SoapOutInterceptor.writeSoap
>> >En velopeStart(SoapOutInterceptor.java:95) .at
>> > org.apache.cxf.binding.soap.interceptor.SoapOutInterceptor.handleMes
>> >sa ge(SoapOutInterceptor.java:76) .at
>> > org.apache.cxf.binding.soap.interceptor.SoapOutInterceptor.handleMes
>> >sa ge(SoapOutInterceptor.java:57) .at
>> > org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseIntercep
>> >to rChain.java:208) .at
>> > org.apache.cxf.interceptor.OutgoingChainInterceptor.handleMessage(Ou
>> >tg oingChainInterceptor.java:74) .at
>> > org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseIntercep
>> >to rChain.java:208) .at
>> > org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInit
>> >ia tionObserver.java:77) .at
>> > org.apache.cxf.transport.servlet.ServletDestination.doMessage(Servle
>> >tD estination.java:79) .at
>> > org.apache.cxf.transport.servlet.ServletController.invokeDestination
>> >(S ervletController.java:264) .at
>> > org.apache.cxf.transport.servlet.ServletController.invoke(ServletCon
>> >tr oller.java:160) .at
>> > org.apache.cxf.transport.servlet.AbstractCXFServlet.invoke(AbstractC
>> >XF Servlet.java:170) .at
>> > org.apache.cxf.transport.servlet.AbstractCXFServlet.doPost(AbstractC
>> >XF Servlet.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 <dkulp@apache.org>
>> > 02/05/2008 02:50 PM
>> >
>> > To
>> > cxf-user@incubator.apache.org
>> > cc
>> > jason.laskowski@aurora.org
>> > 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, jason.laskowski@aurora.org 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
> dkulp@apache.org
> http://www.dankulp.com/blog
> 
> 

-- 
View this message in context: http://www.nabble.com/Deploy-my-service-implementation-separately-from-my-security-configuration--tp15268762p17103685.html
Sent from the cxf-user mailing list archive at Nabble.com.


Mime
View raw message