You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Jimi Hullegård <ji...@mogul.com> on 2010/12/30 23:11:21 UTC
Re: minimum set of dependencies for a ws-* client to run - Found
word(s) list error in the Text body
I don't know how much it applies to the current situation, but nowadays with spring, and annotations and such alot of things can happen simply by having some "unused" jar files in the classpath. And there is always the risk of jar collisions (different versions of 3rd party jars). Don't you agree?
While you seem to tend to lean towards the philosophy "start with 'everything' and then remove only the things you know you don't need" while I tend to lean towards the philosophy "start with the bare minimum and only add the things you know that you need". Need I say that I have a less then positive view on bloatware, for example? :)
/Jimi
________________________________________
Från: Ron Wheeler [rwheeler@artifact-software.com]
Skickat: den 30 december 2010 15:48
Till: users@cxf.apache.org
Ämne: Re: minimum set of dependencies for a ws-* client to run - Found word(s) list error in the Text body
Is there any particular reason why this matters?
Only classes actually used will get instantiated.
It seems like a lot of work to save a few megabytes of disk space.
This can only save you a few cents per installation.
The savings during the startup of Tomcat can not be more than a few
milliseconds and a dozen or so disk IOs, if you use the cxf bundle.
Hardly seems worth spending a lot of time or any time on this aside from
removing the tools.
The ROI on this looks highly questionable.
Ron
On 30/12/2010 8:09 AM, John Franey wrote:
> Thanks for the reply. Very helpful. I had not seen that file. Thanks for
> pointing it out.
>
> However, the first jar in that list: cxf-${version}.jar appears to be an
> assembly of about 40 dependencies:
>
> cxf-api cxf-rt-core cxf-rt-transports-http
> cxf-tools-corba
> cxf-bundle cxf-rt-databinding-aegis
> cxf-rt-transports-http-jetty cxf-tools-java2ws
> cxf-common-schemas cxf-rt-databinding-jaxb
> cxf-rt-transports-http-osgi cxf-tools-misctools
> cxf-common-utilities cxf-rt-databinding-xmlbeans cxf-rt-transports-jms
> cxf-tools-validator
> cxf-rt-bindings-coloc cxf-rt-frontend-jaxrs cxf-rt-transports-local
> cxf-tools-wsdlto-core
> cxf-rt-bindings-corba cxf-rt-frontend-jaxws cxf-rt-ws-addr
> cxf-tools-wsdlto-databinding-jaxb
> cxf-rt-bindings-http cxf-rt-frontend-js cxf-rt-ws-policy
> cxf-tools-wsdlto-frontend-javascript
> cxf-rt-bindings-object cxf-rt-frontend-simple cxf-rt-ws-rm
> cxf-tools-wsdlto-frontend-jaxws
> cxf-rt-bindings-soap cxf-rt-javascript cxf-rt-ws-security
> cxf-rt-bindings-xml cxf-rt-management cxf-tools-common
>
> My client program needs only a subset of these. cxf-tools-* are for build
> time, not runtime. I don't need all bindings, frontends, databindings for
> now: osgi, jms, corba, aegis, .....
>
> Although, some of these are obviously not needed for my client, I have some
> uncertainty about which are needed. The tedious task ahead of me is to put
> all in the pom to make the client work, then pare it down until I discover
> the smallest set of required dependencies. I'm not looking forward to that
> exercise.
>
> Is there any of the above whose absence from the runtime classpath would
> cause an error in the security header processing?
>
> When the client side is unable to satisfy the security policy specified in
> the wsdl (due to missing plugins), it goes ahead and sends a message anyway,
> without even logging any kind of error or warning.
>
>
>
>
> Here is the message my client sends when it is broken (missing
> dependencies):
>
> Address: http://localhost:8080/cxf-seismic-scencr
> Encoding: UTF-8
> Content-Type: text/xml
> Headers: {SOAPAction=["urn:matchQuakes"], Accept=[*/*]}
> Payload:<soap:Envelope xmlns:soap="
> http://schemas.xmlsoap.org/soap/envelope/"><soap:Body><matchQuakes xmlns="
> http://ws.sosnoski.com/seismic/types
> "><min-date>2000-04-18T00:00:29.663Z</min-date><max-date>2000-08-11T20:25:04.773Z</max-date><min-long>-52.879272</min-long><max-long>31.870659</max-long><min-lat>6.8230515</min-lat><max-lat>48.050884</max-lat></matchQuakes></soap:Body></soap:Envelope>
>
>
> Here is the message my client sends when cxf-manifest.jar is on the
> classpath:
>
> Address: http://localhost:8080/cxf-seismic-scencr
> Encoding: UTF-8
> Content-Type: text/xml
> Headers: {SOAPAction=["
> http://docs.oasis-open.org/ws-sx/ws-trust/200512/RST/SCT"], Accept=[*/*]}
> Payload:<soap:Envelope xmlns:soap="
> http://schemas.xmlsoap.org/soap/envelope/" xmlns:xenc="
> http://www.w3.org/2001/04/xmlenc#"><soap:Header><Action xmlns="
> http://www.w3.org/2005/08/addressing">
> http://docs.oasis-open.org/ws-sx/ws-trust/200512/RST/SCT</Action><MessageID
> xmlns="http://www.w3.org/2005/08/addressing">urn:uuid:d26aaff1-f98a-4e1e-8a37-cfdadda2508b</MessageID><To
> xmlns="http://www.w3.org/2005/08/addressing">
> http://localhost:8080/cxf-seismic-scencr</To><ReplyTo xmlns="
> http://www.w3.org/2005/08/addressing"><Address>
> http://www.w3.org/2005/08/addressing/anonymous</Address></ReplyTo><wsse:Security
> xmlns:wsse="
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"
> soap:mustUnderstand="1"><xenc:EncryptedKey xmlns:xenc="
> http://www.w3.org/2001/04/xmlenc#"
> Id="EncKeyId-37F5DEC59F5E8A3EDC12937142163422"><xenc:EncryptionMethod
> Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5" /><ds:KeyInfo
> xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
> <wsse:SecurityTokenReference xmlns:wsse="
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"><wsse:KeyIdentifier
> EncodingType="
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary"
> ValueType="
> http://docs.oasis-open.org/wss/oasis-wss-soap-message-security-1.1#ThumbprintSHA1
> ">uYn3PK2wXheN2lLZr4n2mJjoWE0=</wsse:KeyIdentifier></wsse:SecurityTokenReference>
> </ds:KeyInfo><xenc:CipherData><xenc:CipherValue>XXnLFoxisXRu7LYRH9f89VeyCGFzdINtiTi0g6lq1L8Oi/RI20DcqfGz1hGMRADSaXHXaczqSpJZDPQkC6u0JaPRK/6u9MIGfxqHKtB7uDTAlQDIhii8eLninIVlCRRP7MwDZGTRRwXFk4i+ApdMr/kwVAnr6Ue2pkqrJthxEeQ=</xenc:CipherValue></xenc:CipherData></xenc:EncryptedKey><wsc:DerivedKeyToken
> xmlns:wsc="http://docs.oasis-open.org/ws-sx/ws-secureconversation/200512"
> xmlns:wsu="
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
> wsu:Id="derivedKeyId-1"><wsse:SecurityTokenReference xmlns:wsse="
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"><wsse:Reference
> xmlns:wsse="
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"
> URI="#EncKeyId-37F5DEC59F5E8A3EDC12937142163422" ValueType="
> http://docs.oasis-open.org/wss/oasis-wss-soap-message-security-1.1#EncryptedKey"
> /></wsse:SecurityTokenReference><wsc:Offset>0</wsc:Offset><wsc:Length>16</wsc:Length><wsc:Nonce>CjiosHDEJjItHXgdjZcBDg==</wsc:Nonce></wsc:DerivedKeyToken><xenc:ReferenceList><xenc:DataReference
> URI="#EncDataId-2"
> /></xenc:ReferenceList></wsse:Security></soap:Header><soap:Body xmlns:wsu="
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
> wsu:Id="Id-622596956"><xenc:EncryptedData xmlns:xenc="
> http://www.w3.org/2001/04/xmlenc#" Id="EncDataId-2" Type="
> http://www.w3.org/2001/04/xmlenc#Content"><xenc:EncryptionMethod Algorithm="
> http://www.w3.org/2001/04/xmlenc#aes128-cbc" /><ds:KeyInfo xmlns:ds="
> http://www.w3.org/2000/09/xmldsig#">
> <wsse:SecurityTokenReference xmlns:wsse="
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"><wsse:Reference
> xmlns:wsse="
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"
> URI="#derivedKeyId-1" /></wsse:SecurityTokenReference>
> </ds:KeyInfo><xenc:CipherData><xenc:CipherValue>24udu5/0tHCZw4GNAZN3Hnd8HyPq7VxAsMB7CSZ8FvBZRk+CYkUcV/NKpCwKy4BXHRr4+J1ECvhI
> ... many lines omitted....
> Km4tanAVH4y9/1DVmlX8s+1lBqTr6e9M1UFMZG0YJBs=</xenc:CipherValue></xenc:CipherData></xenc:EncryptedData></soap:Body></soap:Envelope>
>
> Thanks,
> John
>
>
> On Wed, Dec 29, 2010 at 10:23 PM, Freeman Fang<fr...@gmail.com>wrote:
>
>> Hi,
>>
>> Just a quick notes, please take a look at WHICH_JARS doc in cxf kit lib
>> folder.
>>
>> Freeman
>>
>> On 2010-12-30, at 上午9:56, John Franey wrote:
>>
>> How do I get to the minimal list of dependencies my cxf client needs to
>>> run?
>>>
>>> I have a client (from
>>> http://www.ibm.com/developerworks/java/library/j-jws17/index.html) whose
>>> build I have maven-ized. I'm trying to construct the correct runtime
>>> classpath so that maven would build a runnable client. The ant build from
>>> the article simply puts *everything* from ${cxf-root}/lib onto the
>>> classpath. I would like a classpath that has only what is needed to run.
>>>
>>> When I run the client from the article with only the build time
>>> dependencies
>>> on the classpath, I get a result that does not tell me which dependencies
>>> to
>>> add. Not a class-not-found exception, or a log message (I turned it up to
>>> 'trace' level). The error I get is on the server side log:
>>>
>>>
>>> Dec 29, 2010 8:16:00 PM
>>> org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor
>>> handleMessage
>>> WARNING: Request does not contain required Security header
>>> Dec 29, 2010 8:16:00 PM
>>> org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor
>>> handleMessage
>>> WARNING:
>>> org.apache.ws.security.WSSecurityException: An error was discovered
>>> processing the<wsse:Security> header
>>> at
>>>
>>> org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.handleMessage(WSS4JInInterceptor.java:229)
>>> at
>>>
>>> org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.handleMessage(WSS4JInInterceptor.java:78)
>>> at
>>>
>>> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:243)
>>> at
>>>
>>> org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:110)
>>> at
>>>
>>> org.apache.cxf.transport.servlet.ServletDestination.invoke(ServletDestination.java:98)
>>> at
>>>
>>> org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:423)
>>> at
>>>
>>> org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:178)
>>> at
>>>
>>> org.apache.cxf.transport.servlet.AbstractCXFServlet.invoke(AbstractCXFServlet.java:142)
>>> at
>>>
>>> org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:179)
>>> at
>>>
>>> org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:103)
>>> at javax.servlet.http.HttpServlet.service(HttpServlet.java:647)
>>> at
>>>
>>> org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:159)
>>> at
>>>
>>> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:269)
>>> .... (more details available, omitted for now)
>>>
>>>
>>> And the client receives a fault:
>>>
>>> javax.xml.ws.soap.SOAPFaultException: An error was discovered processing
>>> the
>>> <wsse:Security> header
>>> at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:146)
>>> at $Proxy42.matchQuakes(Unknown Source)
>>> at com.sosnoski.ws.seismic.cxf.CxfClient.runQuery(CxfClient.java:83)
>>> at
>>>
>>> com.sosnoski.ws.seismic.cxf.TestClient$TestRunnable.run(TestClient.java:210)
>>> at java.lang.Thread.run(Thread.java:662)
>>> Caused by: org.apache.cxf.binding.soap.SoapFault: An error was discovered
>>> processing the<wsse:Security> header
>>> ... (more details available, omitted for now)
>>>
>>>
>>>
>>>
>>> I think the right jar file on the runtime classpath would affect the
>>> content
>>> of the wsse:Security header, but I don't know which jar file.
>>>
>>>
>>> To discover the minimal list of dependencies, I ran a few experiments:
>>> 1) In eclipse, I launched the maven built project with all the jar files
>>> from ${cxf-root}/lib on the classpath. That works and so one-by-one, I
>>> removed the jars from the runtime classpath until I was left with the ones
>>> that work: only cxf-manifest.jar. The content of that jar is only a
>>> manifest and a maven pom. Does cxf read the pom to load the jar files
>>> from
>>> my local repository?
>>>
>>> But I also have a two experiments that conflict with that finding. 1)
>>> Putting cxf-distribution-manifest as a dependency in my maven project pom
>>> does not work. Also, 2) excluding cxf-manifest.jar from the article's ant
>>> build does not break the client.
>>>
>>> So, how do I discover the minimal runtime dependencies required on this
>>> client's classpath?
>>>
>>> cxf 2.2.8, linux ubuntu 10.10, jdk 1.6, tomcat 5.5.
>>>
>>> Thanks,
>>> John
>>>
>>
>> --
>> Freeman Fang
>>
>> ------------------------
>>
>> FuseSource: http://fusesource.com
>> blog: http://freemanfang.blogspot.com
>> twitter: http://twitter.com/freemanfang
>> Apache Servicemix:http://servicemix.apache.org
>> Apache Cxf: http://cxf.apache.org
>> Apache Karaf: http://karaf.apache.org
>> Apache Felix: http://felix.apache.org
>>
>>
Re: minimum set of dependencies for a ws-* client to run - Found word(s) list error in the Text body
Posted by Daniel Kulp <dk...@apache.org>.
Just to add another variable to the conversation: the JAX-WS spec kind of
dictates some of the deps that we MUST have setup for the jaxws frontend.
For example, the JAX-WS frontend needs to have the xml-resolver.jar there by
default as the JAX-WS spec mandates that catalogs work "out of the box". You
can exclude the jar and CXF would work (except for catalogs), but the spec
mandates that catalogs work in order to claim compliance.
Dan
On Thursday 30 December 2010 5:11:21 pm Jimi Hullegård wrote:
> I don't know how much it applies to the current situation, but nowadays
> with spring, and annotations and such alot of things can happen simply by
> having some "unused" jar files in the classpath. And there is always the
> risk of jar collisions (different versions of 3rd party jars). Don't you
> agree?
>
> While you seem to tend to lean towards the philosophy "start with
> 'everything' and then remove only the things you know you don't need"
> while I tend to lean towards the philosophy "start with the bare minimum
> and only add the things you know that you need". Need I say that I have a
> less then positive view on bloatware, for example? :)
>
> /Jimi
>
> ________________________________________
> Från: Ron Wheeler [rwheeler@artifact-software.com]
> Skickat: den 30 december 2010 15:48
> Till: users@cxf.apache.org
> Ämne: Re: minimum set of dependencies for a ws-* client to run - Found
> word(s) list error in the Text body
>
> Is there any particular reason why this matters?
> Only classes actually used will get instantiated.
>
> It seems like a lot of work to save a few megabytes of disk space.
> This can only save you a few cents per installation.
>
> The savings during the startup of Tomcat can not be more than a few
> milliseconds and a dozen or so disk IOs, if you use the cxf bundle.
>
> Hardly seems worth spending a lot of time or any time on this aside from
> removing the tools.
> The ROI on this looks highly questionable.
>
> Ron
>
> On 30/12/2010 8:09 AM, John Franey wrote:
> > Thanks for the reply. Very helpful. I had not seen that file. Thanks
> > for pointing it out.
> >
> > However, the first jar in that list: cxf-${version}.jar appears to be an
> > assembly of about 40 dependencies:
> >
> > cxf-api cxf-rt-core
> > cxf-rt-transports-http
> >
> > cxf-tools-corba
> >
> > cxf-bundle cxf-rt-databinding-aegis
> > cxf-rt-transports-http-jetty cxf-tools-java2ws
> > cxf-common-schemas cxf-rt-databinding-jaxb
> >
> > cxf-rt-transports-http-osgi cxf-tools-misctools
> >
> > cxf-common-utilities cxf-rt-databinding-xmlbeans
> > cxf-rt-transports-jms
> >
> > cxf-tools-validator
> >
> > cxf-rt-bindings-coloc cxf-rt-frontend-jaxrs
> > cxf-rt-transports-local
> >
> > cxf-tools-wsdlto-core
> >
> > cxf-rt-bindings-corba cxf-rt-frontend-jaxws cxf-rt-ws-addr
> >
> > cxf-tools-wsdlto-databinding-jaxb
> >
> > cxf-rt-bindings-http cxf-rt-frontend-js cxf-rt-ws-policy
> >
> > cxf-tools-wsdlto-frontend-javascript
> >
> > cxf-rt-bindings-object cxf-rt-frontend-simple cxf-rt-ws-rm
> >
> > cxf-tools-wsdlto-frontend-jaxws
> >
> > cxf-rt-bindings-soap cxf-rt-javascript cxf-rt-ws-security
> > cxf-rt-bindings-xml cxf-rt-management cxf-tools-common
> >
> > My client program needs only a subset of these. cxf-tools-* are for
> > build time, not runtime. I don't need all bindings, frontends,
> > databindings for now: osgi, jms, corba, aegis, .....
> >
> > Although, some of these are obviously not needed for my client, I have
> > some uncertainty about which are needed. The tedious task ahead of me
> > is to put all in the pom to make the client work, then pare it down
> > until I discover the smallest set of required dependencies. I'm not
> > looking forward to that exercise.
> >
> > Is there any of the above whose absence from the runtime classpath would
> > cause an error in the security header processing?
> >
> > When the client side is unable to satisfy the security policy specified
> > in the wsdl (due to missing plugins), it goes ahead and sends a message
> > anyway, without even logging any kind of error or warning.
> >
> >
> >
> >
> > Here is the message my client sends when it is broken (missing
> > dependencies):
> >
> > Address: http://localhost:8080/cxf-seismic-scencr
> > Encoding: UTF-8
> > Content-Type: text/xml
> > Headers: {SOAPAction=["urn:matchQuakes"], Accept=[*/*]}
> > Payload:<soap:Envelope xmlns:soap="
> > http://schemas.xmlsoap.org/soap/envelope/"><soap:Body><matchQuakes
> > xmlns=" http://ws.sosnoski.com/seismic/types
> > "><min-date>2000-04-18T00:00:29.663Z</min-date><max-date>2000-08-11T20:25
> > :04.773Z</max-date><min-long>-52.879272</min-long><max-long>31.870659</ma
> > x-long><min-lat>6.8230515</min-lat><max-lat>48.050884</max-lat></matchQua
> > kes></soap:Body></soap:Envelope>
> >
> >
> > Here is the message my client sends when cxf-manifest.jar is on the
> > classpath:
> >
> > Address: http://localhost:8080/cxf-seismic-scencr
> > Encoding: UTF-8
> > Content-Type: text/xml
> > Headers: {SOAPAction=["
> > http://docs.oasis-open.org/ws-sx/ws-trust/200512/RST/SCT"], Accept=[*/*]}
> > Payload:<soap:Envelope xmlns:soap="
> > http://schemas.xmlsoap.org/soap/envelope/" xmlns:xenc="
> > http://www.w3.org/2001/04/xmlenc#"><soap:Header><Action xmlns="
> > http://www.w3.org/2005/08/addressing">
> > http://docs.oasis-open.org/ws-sx/ws-trust/200512/RST/SCT</Action><Message
> > ID
> > xmlns="http://www.w3.org/2005/08/addressing">urn:uuid:d26aaff1-f98a-4e1e
> > -8a37-cfdadda2508b</MessageID><To
> > xmlns="http://www.w3.org/2005/08/addressing">
> > http://localhost:8080/cxf-seismic-scencr</To><ReplyTo xmlns="
> > http://www.w3.org/2005/08/addressing"><Address>
> > http://www.w3.org/2005/08/addressing/anonymous</Address></ReplyTo><wsse:S
> > ecurity xmlns:wsse="
> > http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext
> > -1.0.xsd" soap:mustUnderstand="1"><xenc:EncryptedKey xmlns:xenc="
> > http://www.w3.org/2001/04/xmlenc#"
> > Id="EncKeyId-37F5DEC59F5E8A3EDC12937142163422"><xenc:EncryptionMethod
> > Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5" /><ds:KeyInfo
> > xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
> > <wsse:SecurityTokenReference xmlns:wsse="
> > http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext
> > -1.0.xsd"><wsse:KeyIdentifier EncodingType="
> > http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-secu
> > rity-1.0#Base64Binary" ValueType="
> > http://docs.oasis-open.org/wss/oasis-wss-soap-message-security-1.1#Thumbp
> > rintSHA1
> > ">uYn3PK2wXheN2lLZr4n2mJjoWE0=</wsse:KeyIdentifier></wsse:SecurityTokenR
> > eference>
> > </ds:KeyInfo><xenc:CipherData><xenc:CipherValue>XXnLFoxisXRu7LYRH9f89Vey
> > CGFzdINtiTi0g6lq1L8Oi/RI20DcqfGz1hGMRADSaXHXaczqSpJZDPQkC6u0JaPRK/6u9MIGf
> > xqHKtB7uDTAlQDIhii8eLninIVlCRRP7MwDZGTRRwXFk4i+ApdMr/kwVAnr6Ue2pkqrJthxEe
> > Q=</xenc:CipherValue></xenc:CipherData></xenc:EncryptedKey><wsc:DerivedKe
> > yToken
> > xmlns:wsc="http://docs.oasis-open.org/ws-sx/ws-secureconversation/200512
> > " xmlns:wsu="
> > http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utilit
> > y-1.0.xsd" wsu:Id="derivedKeyId-1"><wsse:SecurityTokenReference
> > xmlns:wsse="
> > http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secex
> > t-1.0.xsd"><wsse:Reference xmlns:wsse="
> > http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext
> > -1.0.xsd" URI="#EncKeyId-37F5DEC59F5E8A3EDC12937142163422" ValueType="
> > http://docs.oasis-open.org/wss/oasis-wss-soap-message-security-1.1#Encryp
> > tedKey"
> > /></wsse:SecurityTokenReference><wsc:Offset>0</wsc:Offset><wsc:Length>16
> > </wsc:Length><wsc:Nonce>CjiosHDEJjItHXgdjZcBDg==</wsc:Nonce></wsc:Derived
> > KeyToken><xenc:ReferenceList><xenc:DataReference URI="#EncDataId-2"
> > /></xenc:ReferenceList></wsse:Security></soap:Header><soap:Body
> > xmlns:wsu="
> > http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utili
> > ty-1.0.xsd" wsu:Id="Id-622596956"><xenc:EncryptedData xmlns:xenc="
> > http://www.w3.org/2001/04/xmlenc#" Id="EncDataId-2" Type="
> > http://www.w3.org/2001/04/xmlenc#Content"><xenc:EncryptionMethod
> > Algorithm=" http://www.w3.org/2001/04/xmlenc#aes128-cbc" /><ds:KeyInfo
> > xmlns:ds=" http://www.w3.org/2000/09/xmldsig#">
> > <wsse:SecurityTokenReference xmlns:wsse="
> > http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext
> > -1.0.xsd"><wsse:Reference xmlns:wsse="
> > http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext
> > -1.0.xsd" URI="#derivedKeyId-1" /></wsse:SecurityTokenReference>
> > </ds:KeyInfo><xenc:CipherData><xenc:CipherValue>24udu5/0tHCZw4GNAZN3Hnd8H
> > yPq7VxAsMB7CSZ8FvBZRk+CYkUcV/NKpCwKy4BXHRr4+J1ECvhI ... many lines
> > omitted....
> > Km4tanAVH4y9/1DVmlX8s+1lBqTr6e9M1UFMZG0YJBs=</xenc:CipherValue></xenc:Cip
> > herData></xenc:EncryptedData></soap:Body></soap:Envelope>
> >
> > Thanks,
> > John
> >
> > On Wed, Dec 29, 2010 at 10:23 PM, Freeman
Fang<fr...@gmail.com>wrote:
> >> Hi,
> >>
> >> Just a quick notes, please take a look at WHICH_JARS doc in cxf kit lib
> >> folder.
> >>
> >> Freeman
> >>
> >> On 2010-12-30, at 上午9:56, John Franey wrote:
> >> How do I get to the minimal list of dependencies my cxf client needs
> >> to
> >>>
> >>> run?
> >>>
> >>> I have a client (from
> >>> http://www.ibm.com/developerworks/java/library/j-jws17/index.html)
> >>> whose build I have maven-ized. I'm trying to construct the correct
> >>> runtime classpath so that maven would build a runnable client. The
> >>> ant build from the article simply puts *everything* from
> >>> ${cxf-root}/lib onto the classpath. I would like a classpath that has
> >>> only what is needed to run.
> >>>
> >>> When I run the client from the article with only the build time
> >>> dependencies
> >>> on the classpath, I get a result that does not tell me which
> >>> dependencies to
> >>> add. Not a class-not-found exception, or a log message (I turned it up
> >>> to 'trace' level). The error I get is on the server side log:
> >>>
> >>>
> >>> Dec 29, 2010 8:16:00 PM
> >>> org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor
> >>> handleMessage
> >>> WARNING: Request does not contain required Security header
> >>> Dec 29, 2010 8:16:00 PM
> >>> org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor
> >>> handleMessage
> >>> WARNING:
> >>> org.apache.ws.security.WSSecurityException: An error was discovered
> >>> processing the<wsse:Security> header
> >>>
> >>> at
> >>>
> >>> org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.handleMessage(WSS4J
> >>> InInterceptor.java:229)
> >>>
> >>> at
> >>>
> >>> org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.handleMessage(WSS4J
> >>> InInterceptor.java:78)
> >>>
> >>> at
> >>>
> >>> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptor
> >>> Chain.java:243)
> >>>
> >>> at
> >>>
> >>> org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiat
> >>> ionObserver.java:110)
> >>>
> >>> at
> >>>
> >>> org.apache.cxf.transport.servlet.ServletDestination.invoke(ServletDesti
> >>> nation.java:98)
> >>>
> >>> at
> >>>
> >>> org.apache.cxf.transport.servlet.ServletController.invokeDestination(Se
> >>> rvletController.java:423)
> >>>
> >>> at
> >>>
> >>> org.apache.cxf.transport.servlet.ServletController.invoke(ServletContro
> >>> ller.java:178)
> >>>
> >>> at
> >>>
> >>> org.apache.cxf.transport.servlet.AbstractCXFServlet.invoke(AbstractCXFS
> >>> ervlet.java:142)
> >>>
> >>> at
> >>>
> >>> org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(Abst
> >>> ractHTTPServlet.java:179)
> >>>
> >>> at
> >>>
> >>> org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTT
> >>> PServlet.java:103)
> >>>
> >>> at javax.servlet.http.HttpServlet.service(HttpServlet.java:647)
> >>> at
> >>>
> >>> org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHT
> >>> TPServlet.java:159)
> >>>
> >>> at
> >>>
> >>> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applic
> >>> ationFilterChain.java:269) .... (more details available, omitted for
> >>> now)
> >>>
> >>>
> >>> And the client receives a fault:
> >>>
> >>> javax.xml.ws.soap.SOAPFaultException: An error was discovered
> >>> processing the
> >>> <wsse:Security> header
> >>> at
> >>> org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:146
> >>> ) at $Proxy42.matchQuakes(Unknown Source)
> >>> at com.sosnoski.ws.seismic.cxf.CxfClient.runQuery(CxfClient.java:83)
> >>> at
> >>>
> >>> com.sosnoski.ws.seismic.cxf.TestClient$TestRunnable.run(TestClient.java
> >>> :210) at java.lang.Thread.run(Thread.java:662)
> >>> Caused by: org.apache.cxf.binding.soap.SoapFault: An error was
> >>> discovered processing the<wsse:Security> header
> >>> ... (more details available, omitted for now)
> >>>
> >>>
> >>>
> >>>
> >>> I think the right jar file on the runtime classpath would affect the
> >>> content
> >>> of the wsse:Security header, but I don't know which jar file.
> >>>
> >>>
> >>> To discover the minimal list of dependencies, I ran a few experiments:
> >>> 1) In eclipse, I launched the maven built project with all the jar
> >>> files from ${cxf-root}/lib on the classpath. That works and so
> >>> one-by-one, I removed the jars from the runtime classpath until I was
> >>> left with the ones that work: only cxf-manifest.jar. The content of
> >>> that jar is only a manifest and a maven pom. Does cxf read the pom to
> >>> load the jar files from
> >>> my local repository?
> >>>
> >>> But I also have a two experiments that conflict with that finding. 1)
> >>> Putting cxf-distribution-manifest as a dependency in my maven project
> >>> pom does not work. Also, 2) excluding cxf-manifest.jar from the
> >>> article's ant build does not break the client.
> >>>
> >>> So, how do I discover the minimal runtime dependencies required on this
> >>> client's classpath?
> >>>
> >>> cxf 2.2.8, linux ubuntu 10.10, jdk 1.6, tomcat 5.5.
> >>>
> >>> Thanks,
> >>> John
> >>
> >> --
> >> Freeman Fang
> >>
> >> ------------------------
> >>
> >> FuseSource: http://fusesource.com
> >> blog: http://freemanfang.blogspot.com
> >> twitter: http://twitter.com/freemanfang
> >> Apache Servicemix:http://servicemix.apache.org
> >> Apache Cxf: http://cxf.apache.org
> >> Apache Karaf: http://karaf.apache.org
> >> Apache Felix: http://felix.apache.org
--
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog
Re: minimum set of dependencies for a ws-* client to run - Found
word(s) list error in the Text body
Posted by Ron Wheeler <rw...@artifact-software.com>.
On 30/12/2010 5:11 PM, Jimi Hullegård wrote:
> I don't know how much it applies to the current situation, but nowadays with spring, and annotations and such alot of things can happen simply by having some "unused" jar files in the classpath. And there is always the risk of jar collisions (different versions of 3rd party jars). Don't you agree?
This is a problem that we avoid using exclusions to ensure that we do
not get collisions.
I got tired of having to try to guess what version of commons-logging
Tomcat actually loaded from the 4 or 5 versions that the various
libraries pulled in as transitive dependencies.
> While you seem to tend to lean towards the philosophy "start with 'everything' and then remove only the things you know you don't need" while I tend to lean towards the philosophy "start with the bare minimum and only add the things you know that you need". Need I say that I have a less then positive view on bloatware, for example? :)
>
We try to eliminate all duplicate classes and ensure that transitive
dependencies do not accidentally load the wrong version of 3rd party
libraries.
I can not control the versions that the CXF developers use so I exclude
the transitive dependencies and put in the versions that I want.
Once we have done this once for each library, the developers do not have
to worry about it and our POMs are simple and our assemblies are trivial.
It is not trivial to build the aggregation poms since we look very
carefully at the transitive dependencies. Thank goodness for Eclipse/STS
and the nice Maven tools that let you switch tabs to exclude a
dependency and then see what happens to the transitive dependencies.
We do not have any extra 3rd party classes in our entire application.
The extra CXF classes that we do carry is caused by the fact that you
can not aggregate the CXF individual libraries with having problems with
the property files since the individual modules have different contents
in files with the same name so you will get runtime errors unless you
use the cxf-bundle.
Ron
> /Jimi
>
> ________________________________________
> Från: Ron Wheeler [rwheeler@artifact-software.com]
> Skickat: den 30 december 2010 15:48
> Till: users@cxf.apache.org
> Ämne: Re: minimum set of dependencies for a ws-* client to run - Found word(s) list error in the Text body
>
> Is there any particular reason why this matters?
> Only classes actually used will get instantiated.
>
> It seems like a lot of work to save a few megabytes of disk space.
> This can only save you a few cents per installation.
>
> The savings during the startup of Tomcat can not be more than a few
> milliseconds and a dozen or so disk IOs, if you use the cxf bundle.
>
> Hardly seems worth spending a lot of time or any time on this aside from
> removing the tools.
> The ROI on this looks highly questionable.
>
> Ron
>
> On 30/12/2010 8:09 AM, John Franey wrote:
>> Thanks for the reply. Very helpful. I had not seen that file. Thanks for
>> pointing it out.
>>
>> However, the first jar in that list: cxf-${version}.jar appears to be an
>> assembly of about 40 dependencies:
>>
>> cxf-api cxf-rt-core cxf-rt-transports-http
>> cxf-tools-corba
>> cxf-bundle cxf-rt-databinding-aegis
>> cxf-rt-transports-http-jetty cxf-tools-java2ws
>> cxf-common-schemas cxf-rt-databinding-jaxb
>> cxf-rt-transports-http-osgi cxf-tools-misctools
>> cxf-common-utilities cxf-rt-databinding-xmlbeans cxf-rt-transports-jms
>> cxf-tools-validator
>> cxf-rt-bindings-coloc cxf-rt-frontend-jaxrs cxf-rt-transports-local
>> cxf-tools-wsdlto-core
>> cxf-rt-bindings-corba cxf-rt-frontend-jaxws cxf-rt-ws-addr
>> cxf-tools-wsdlto-databinding-jaxb
>> cxf-rt-bindings-http cxf-rt-frontend-js cxf-rt-ws-policy
>> cxf-tools-wsdlto-frontend-javascript
>> cxf-rt-bindings-object cxf-rt-frontend-simple cxf-rt-ws-rm
>> cxf-tools-wsdlto-frontend-jaxws
>> cxf-rt-bindings-soap cxf-rt-javascript cxf-rt-ws-security
>> cxf-rt-bindings-xml cxf-rt-management cxf-tools-common
>>
>> My client program needs only a subset of these. cxf-tools-* are for build
>> time, not runtime. I don't need all bindings, frontends, databindings for
>> now: osgi, jms, corba, aegis, .....
>>
>> Although, some of these are obviously not needed for my client, I have some
>> uncertainty about which are needed. The tedious task ahead of me is to put
>> all in the pom to make the client work, then pare it down until I discover
>> the smallest set of required dependencies. I'm not looking forward to that
>> exercise.
>>
>> Is there any of the above whose absence from the runtime classpath would
>> cause an error in the security header processing?
>>
>> When the client side is unable to satisfy the security policy specified in
>> the wsdl (due to missing plugins), it goes ahead and sends a message anyway,
>> without even logging any kind of error or warning.
>>
>>
>>
>>
>> Here is the message my client sends when it is broken (missing
>> dependencies):
>>
>> Address: http://localhost:8080/cxf-seismic-scencr
>> Encoding: UTF-8
>> Content-Type: text/xml
>> Headers: {SOAPAction=["urn:matchQuakes"], Accept=[*/*]}
>> Payload:<soap:Envelope xmlns:soap="
>> http://schemas.xmlsoap.org/soap/envelope/"><soap:Body><matchQuakes xmlns="
>> http://ws.sosnoski.com/seismic/types
>> "><min-date>2000-04-18T00:00:29.663Z</min-date><max-date>2000-08-11T20:25:04.773Z</max-date><min-long>-52.879272</min-long><max-long>31.870659</max-long><min-lat>6.8230515</min-lat><max-lat>48.050884</max-lat></matchQuakes></soap:Body></soap:Envelope>
>>
>>
>> Here is the message my client sends when cxf-manifest.jar is on the
>> classpath:
>>
>> Address: http://localhost:8080/cxf-seismic-scencr
>> Encoding: UTF-8
>> Content-Type: text/xml
>> Headers: {SOAPAction=["
>> http://docs.oasis-open.org/ws-sx/ws-trust/200512/RST/SCT"], Accept=[*/*]}
>> Payload:<soap:Envelope xmlns:soap="
>> http://schemas.xmlsoap.org/soap/envelope/" xmlns:xenc="
>> http://www.w3.org/2001/04/xmlenc#"><soap:Header><Action xmlns="
>> http://www.w3.org/2005/08/addressing">
>> http://docs.oasis-open.org/ws-sx/ws-trust/200512/RST/SCT</Action><MessageID
>> xmlns="http://www.w3.org/2005/08/addressing">urn:uuid:d26aaff1-f98a-4e1e-8a37-cfdadda2508b</MessageID><To
>> xmlns="http://www.w3.org/2005/08/addressing">
>> http://localhost:8080/cxf-seismic-scencr</To><ReplyTo xmlns="
>> http://www.w3.org/2005/08/addressing"><Address>
>> http://www.w3.org/2005/08/addressing/anonymous</Address></ReplyTo><wsse:Security
>> xmlns:wsse="
>> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"
>> soap:mustUnderstand="1"><xenc:EncryptedKey xmlns:xenc="
>> http://www.w3.org/2001/04/xmlenc#"
>> Id="EncKeyId-37F5DEC59F5E8A3EDC12937142163422"><xenc:EncryptionMethod
>> Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5" /><ds:KeyInfo
>> xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
>> <wsse:SecurityTokenReference xmlns:wsse="
>> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"><wsse:KeyIdentifier
>> EncodingType="
>> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary"
>> ValueType="
>> http://docs.oasis-open.org/wss/oasis-wss-soap-message-security-1.1#ThumbprintSHA1
>> ">uYn3PK2wXheN2lLZr4n2mJjoWE0=</wsse:KeyIdentifier></wsse:SecurityTokenReference>
>> </ds:KeyInfo><xenc:CipherData><xenc:CipherValue>XXnLFoxisXRu7LYRH9f89VeyCGFzdINtiTi0g6lq1L8Oi/RI20DcqfGz1hGMRADSaXHXaczqSpJZDPQkC6u0JaPRK/6u9MIGfxqHKtB7uDTAlQDIhii8eLninIVlCRRP7MwDZGTRRwXFk4i+ApdMr/kwVAnr6Ue2pkqrJthxEeQ=</xenc:CipherValue></xenc:CipherData></xenc:EncryptedKey><wsc:DerivedKeyToken
>> xmlns:wsc="http://docs.oasis-open.org/ws-sx/ws-secureconversation/200512"
>> xmlns:wsu="
>> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
>> wsu:Id="derivedKeyId-1"><wsse:SecurityTokenReference xmlns:wsse="
>> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"><wsse:Reference
>> xmlns:wsse="
>> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"
>> URI="#EncKeyId-37F5DEC59F5E8A3EDC12937142163422" ValueType="
>> http://docs.oasis-open.org/wss/oasis-wss-soap-message-security-1.1#EncryptedKey"
>> /></wsse:SecurityTokenReference><wsc:Offset>0</wsc:Offset><wsc:Length>16</wsc:Length><wsc:Nonce>CjiosHDEJjItHXgdjZcBDg==</wsc:Nonce></wsc:DerivedKeyToken><xenc:ReferenceList><xenc:DataReference
>> URI="#EncDataId-2"
>> /></xenc:ReferenceList></wsse:Security></soap:Header><soap:Body xmlns:wsu="
>> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
>> wsu:Id="Id-622596956"><xenc:EncryptedData xmlns:xenc="
>> http://www.w3.org/2001/04/xmlenc#" Id="EncDataId-2" Type="
>> http://www.w3.org/2001/04/xmlenc#Content"><xenc:EncryptionMethod Algorithm="
>> http://www.w3.org/2001/04/xmlenc#aes128-cbc" /><ds:KeyInfo xmlns:ds="
>> http://www.w3.org/2000/09/xmldsig#">
>> <wsse:SecurityTokenReference xmlns:wsse="
>> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"><wsse:Reference
>> xmlns:wsse="
>> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"
>> URI="#derivedKeyId-1" /></wsse:SecurityTokenReference>
>> </ds:KeyInfo><xenc:CipherData><xenc:CipherValue>24udu5/0tHCZw4GNAZN3Hnd8HyPq7VxAsMB7CSZ8FvBZRk+CYkUcV/NKpCwKy4BXHRr4+J1ECvhI
>> ... many lines omitted....
>> Km4tanAVH4y9/1DVmlX8s+1lBqTr6e9M1UFMZG0YJBs=</xenc:CipherValue></xenc:CipherData></xenc:EncryptedData></soap:Body></soap:Envelope>
>>
>> Thanks,
>> John
>>
>>
>> On Wed, Dec 29, 2010 at 10:23 PM, Freeman Fang<fr...@gmail.com>wrote:
>>
>>> Hi,
>>>
>>> Just a quick notes, please take a look at WHICH_JARS doc in cxf kit lib
>>> folder.
>>>
>>> Freeman
>>>
>>> On 2010-12-30, at 上午9:56, John Franey wrote:
>>>
>>> How do I get to the minimal list of dependencies my cxf client needs to
>>>> run?
>>>>
>>>> I have a client (from
>>>> http://www.ibm.com/developerworks/java/library/j-jws17/index.html) whose
>>>> build I have maven-ized. I'm trying to construct the correct runtime
>>>> classpath so that maven would build a runnable client. The ant build from
>>>> the article simply puts *everything* from ${cxf-root}/lib onto the
>>>> classpath. I would like a classpath that has only what is needed to run.
>>>>
>>>> When I run the client from the article with only the build time
>>>> dependencies
>>>> on the classpath, I get a result that does not tell me which dependencies
>>>> to
>>>> add. Not a class-not-found exception, or a log message (I turned it up to
>>>> 'trace' level). The error I get is on the server side log:
>>>>
>>>>
>>>> Dec 29, 2010 8:16:00 PM
>>>> org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor
>>>> handleMessage
>>>> WARNING: Request does not contain required Security header
>>>> Dec 29, 2010 8:16:00 PM
>>>> org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor
>>>> handleMessage
>>>> WARNING:
>>>> org.apache.ws.security.WSSecurityException: An error was discovered
>>>> processing the<wsse:Security> header
>>>> at
>>>>
>>>> org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.handleMessage(WSS4JInInterceptor.java:229)
>>>> at
>>>>
>>>> org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.handleMessage(WSS4JInInterceptor.java:78)
>>>> at
>>>>
>>>> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:243)
>>>> at
>>>>
>>>> org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:110)
>>>> at
>>>>
>>>> org.apache.cxf.transport.servlet.ServletDestination.invoke(ServletDestination.java:98)
>>>> at
>>>>
>>>> org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:423)
>>>> at
>>>>
>>>> org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:178)
>>>> at
>>>>
>>>> org.apache.cxf.transport.servlet.AbstractCXFServlet.invoke(AbstractCXFServlet.java:142)
>>>> at
>>>>
>>>> org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:179)
>>>> at
>>>>
>>>> org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:103)
>>>> at javax.servlet.http.HttpServlet.service(HttpServlet.java:647)
>>>> at
>>>>
>>>> org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:159)
>>>> at
>>>>
>>>> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:269)
>>>> .... (more details available, omitted for now)
>>>>
>>>>
>>>> And the client receives a fault:
>>>>
>>>> javax.xml.ws.soap.SOAPFaultException: An error was discovered processing
>>>> the
>>>> <wsse:Security> header
>>>> at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:146)
>>>> at $Proxy42.matchQuakes(Unknown Source)
>>>> at com.sosnoski.ws.seismic.cxf.CxfClient.runQuery(CxfClient.java:83)
>>>> at
>>>>
>>>> com.sosnoski.ws.seismic.cxf.TestClient$TestRunnable.run(TestClient.java:210)
>>>> at java.lang.Thread.run(Thread.java:662)
>>>> Caused by: org.apache.cxf.binding.soap.SoapFault: An error was discovered
>>>> processing the<wsse:Security> header
>>>> ... (more details available, omitted for now)
>>>>
>>>>
>>>>
>>>>
>>>> I think the right jar file on the runtime classpath would affect the
>>>> content
>>>> of the wsse:Security header, but I don't know which jar file.
>>>>
>>>>
>>>> To discover the minimal list of dependencies, I ran a few experiments:
>>>> 1) In eclipse, I launched the maven built project with all the jar files
>>>> from ${cxf-root}/lib on the classpath. That works and so one-by-one, I
>>>> removed the jars from the runtime classpath until I was left with the ones
>>>> that work: only cxf-manifest.jar. The content of that jar is only a
>>>> manifest and a maven pom. Does cxf read the pom to load the jar files
>>>> from
>>>> my local repository?
>>>>
>>>> But I also have a two experiments that conflict with that finding. 1)
>>>> Putting cxf-distribution-manifest as a dependency in my maven project pom
>>>> does not work. Also, 2) excluding cxf-manifest.jar from the article's ant
>>>> build does not break the client.
>>>>
>>>> So, how do I discover the minimal runtime dependencies required on this
>>>> client's classpath?
>>>>
>>>> cxf 2.2.8, linux ubuntu 10.10, jdk 1.6, tomcat 5.5.
>>>>
>>>> Thanks,
>>>> John
>>>>
>>> --
>>> Freeman Fang
>>>
>>> ------------------------
>>>
>>> FuseSource: http://fusesource.com
>>> blog: http://freemanfang.blogspot.com
>>> twitter: http://twitter.com/freemanfang
>>> Apache Servicemix:http://servicemix.apache.org
>>> Apache Cxf: http://cxf.apache.org
>>> Apache Karaf: http://karaf.apache.org
>>> Apache Felix: http://felix.apache.org
>>>
>> >