On 30/12/2010 11:58 AM, John Franey wrote:
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.
There are certainly people with a lot more knowledge that I have. :-)
Perhaps they are on vacation, so I will burden you with more of my thoughts.
We took the easy way out in a Tomcat environment.
We decided to share the CXF library for all the client's and services.
We created a maven pom to create just the CXF jar that we wanted by
excluding all of the transitive dependencies that we are providing
through other libraries.
We install this library (and about 10 others that we build for
JasperReports, FSF, Spring-Hibernate-MySQL, etc.) in Tomcat's shareable
../lib folder.
We use only the cxf-bundle since we found out that the property files of
the individual CXF modules conflict with each other if you try to
aggregate them.
It also reduces the dependency list to 1 cxf library plus velocity which
we also wanted to control and force CXF to use our choice of version of
velocity.
We have both clients and services that share this library.
This reduces the size of the clients and the services to almost nothing
since they only include our classes.
This makes the whole build, test, deploy cycle a lot cleaner and quicker.
It also makes it easier to be sure that all modules are using the same
CXF version.
I am not sure how this translates into a jboss environment but you might
be able to do the same thing.
In case you are a Maven user, the dependency section of the POM is
included below
<properties>
<cxf-bundle.version>2.2.5</cxf-bundle.version>
<velocity-pom.version>${lms-project.version}</velocity-pom.version>
</properties>
<dependencies>
<dependency>
<groupId>org.apache.cxf</groupId>
<artifactId>cxf-bundle</artifactId>
<version>${cxf-bundle.version}</version>
<exclusions>
<exclusion>
<artifactId>spring-beans</artifactId>
<groupId>org.springframework</groupId>
</exclusion>
<exclusion>
<artifactId>spring-context</artifactId>
<groupId>org.springframework</groupId>
</exclusion>
<exclusion>
<artifactId>aopalliance</artifactId>
<groupId>aopalliance</groupId>
</exclusion>
<exclusion>
<artifactId>commons-logging</artifactId>
<groupId>commons-logging</groupId>
</exclusion>
<exclusion>
<artifactId>spring-core</artifactId>
<groupId>org.springframework</groupId>
</exclusion>
<exclusion>
<artifactId>spring-jms</artifactId>
<groupId>org.springframework</groupId>
</exclusion>
<exclusion>
<artifactId>spring-context-support</artifactId>
<groupId>org.springframework</groupId>
</exclusion>
<exclusion>
<artifactId>spring-web</artifactId>
<groupId>org.springframework</groupId>
</exclusion>
<exclusion>
<artifactId>commons-lang</artifactId>
<groupId>commons-lang</groupId>
</exclusion>
<exclusion>
<artifactId>oro</artifactId>
<groupId>oro</groupId>
</exclusion>
<exclusion>
<artifactId>commons-collections</artifactId>
<groupId>commons-collections</groupId>
</exclusion>
<exclusion>
<artifactId>spring-tx</artifactId>
<groupId>org.springframework</groupId>
</exclusion>
<exclusion>
<artifactId>dom4j</artifactId>
<groupId>dom4j</groupId>
</exclusion>
<exclusion>
<artifactId>commons-codec</artifactId>
<groupId>commons-codec</groupId>
</exclusion>
<exclusion>
<artifactId>antlr</artifactId>
<groupId>antlr</groupId>
</exclusion>
<exclusion>
<artifactId>velocity</artifactId>
<groupId>org.apache.velocity</groupId>
</exclusion>
<exclusion>
<artifactId>xercesImpl</artifactId>
<groupId>xerces</groupId>
</exclusion>
<exclusion>
<artifactId>xml-apis</artifactId>
<groupId>xml-apis</groupId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>com.artifact_software.lms</groupId>
<artifactId>lms-pom-velocity</artifactId>
<version>${velocity-pom.version}</version>
<type>pom</type>
</dependency>
</dependencies>
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
