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.f...@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
