Good question, and please check my reasoning, maybe I am making the wrong assumptions.
First, I am writing a client that is meant to run inside an enterprise application (ear). The stub will be called from a session bean (ejb), and so needs to be in the ear package. Second, I would like if the entirety of cxf were in the applications server's classloader, but it (probably) will not, so I think I need to bundle the dependencies up into the ear file. I would like to bundle up only what is needed, not the whole kitchen (and sink). Third, more than simply disk space is the consideration. There is value in being succinct. Unused libraries are simply noise. Its easier to isolate a problem is unneeded libs are simply not present in runtime. Also, if I don't know what all the libraries do and how they apply, what DO I know? Not much. For example, when another developer asks what these libraries do in the application, I am not satisified to say: "I don't know." Fourth, cxf is likely not in the applications server's classloader because: I'm using jboss-as 5.1. Although cxf can be deployed to jboss-as 5.1, the latest version available has a bug ( https://issues.apache.org/jira/browse/CXF-3218) which my client must be isolated from. Fifth, I also believe this menial task is way beyond the level of effort I want to perform. I don't think it unreasonable to ask if there is anyone who knows the answer so I can avoid this task. I expect someone knows and may be reading.. :) Call me crazy. Regards, John On Thu, Dec 30, 2010 at 9:48 AM, Ron Wheeler <[email protected] > wrote: > 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<[email protected] >> >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 >>> >>> >>> >
