cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jimi Hullegård <jimi.hulleg...@mogul.com>
Subject Re: minimum set of dependencies for a ws-* client to run - Found word(s) list error in the Text body
Date Thu, 30 Dec 2010 22:11:21 GMT
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<freeman.fang@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
>>
>>
Mime
View raw message