The Author Online Book Forums are Moving

The Author Online Book Forums will soon redirect to Manning's liveBook and liveVideo. All book forum content will migrate to liveBook's discussion forum and all video forum content will migrate to liveVideo. Log in to liveBook or liveVideo with your Manning credentials to join the discussion!

Thank you for your engagement in the AoF over the years! We look forward to offering you a more enhanced forum experience.

Don Stadler (74) [Avatar] Offline
#1
Tjis,

I have an environment issue which is preventing the Mule top-down target from compiling. When I first tried to run the example the build could not find dir="${lib.home}/apache-cxf-2.0.5-incubator/modules">

Looking at the libraries directory I noted that what was available was apache-cxf-2.0.7, so I changed the two cxf directories to point to this and went on. Later I could not compile the Mule top-down example because it was unable to find the getOriginalPayload() method on line 43 of WSAddressingTransformer. Looking at the cource code for CxfMessageAdapter I can clearly see the method, but I don't think that ant is using the same CxfMessageAdapter class - I think it's probably getting it out of a jar in the cxf.2.0.7 distribution, and that the cxf.2.0.5-incubator (or an updated version) is what I need. Looking at the source code for CxfMessageAdapter I don't think switching to getPayload will work as it returns an Object, not the payload, and seems to do something entirely different within the body of the method.

I moved the CxfMessageAdapter,java source file into the esb.chapter7 package and renamed it as CxfAltMessageAdapter, which satisfied the build, although eclipse now cannot resolve it, probably a classpath issue. But my fix probably broke something in the WSDL or the xbean.xml files, because I got tons of 'could not find delegate' exceptions on Mule startup.

Is it possible to get the correct environment or another fix?

MessageImpl msg = (MessageImpl) ((CxfMessageAdapter)adapter).getOriginalPayload(); // getOriginalPayload could not be resolved

Message was edited by:
Don Stadler
Don Stadler (74) [Avatar] Offline
#2
Missing 'delegate'
I have had another look at the latter issue I encountered last night (the missing delegate) that Mule could not find. The final error in the trace is:

[java] * A Fatal error has occurred while the server was running:
*
[java] * Invalid property 'delegate' of bean class
*
[java] * [org.esb.opensource.coc.CoCPortTypeImpl]: No property 'delegate' f
ound *
[java] * (org.springframework.beans.InvalidPropertyException)
*
[java] *
*
[java] * The error is fatal, the system must shutdown

This smells like a Spring injection error to me, my best guess was that the class CoCPortTypeImpl didn't have a 'delegate' attribute to be injected. This is one of the generated classes (under src-generated).

Tracing WHY it's getting generated this way gets a little surreal, because I then discovered that eclipse seems to be corrupted, that the view eclipse is showing is not what is actually on the file system, Eclipse thnks that there are two directories named wsdl-bottom-up and wsdl-top-down under resourceschapter7, while the file system has two directories named provide-wsdl-bottom-up and provide-wsdl-top-down. In provide-wsdl-top-down there is a file named wsdl-first.xml which is not shown at all in eclipse, but eclipse shows directories named cxf and cxf-se under wsdl-top-down, with CoC.wsdl. An eclipse search DOES find the wsdl-first.xml file, which appears to be injecting a class named esb.chapter7.ChamberOfCommerceServiceImpl into the generated class org.esb.opensource.coc.CoCPortTypeImpl. Both classes exist, but the generated CoCPortTypeImpl.java has no property named 'delegate' and no 'setDelegate' method as I would expect to see.

Another problem is that eclipse cannot seem to synchronize with the version of the ch7-build.xml on disk. I have refreshed the resource directory and the file itself, and eclipse persists in believing that it has not been refreshed. I think this hppened because I edited and changed the ch7-build.xml file using vim and then tried to refresh from eclipse - eclipse is failing to refresh for some reason.

I think the root cause of the problem is I have a bad result from the cxf-generate-service-stubs operation on page 252 of the book, which results from the fact that the downloaded environment had apache-cxf-2.0.7 instead of apache-cxf-2.0.5-incubator

This is pretty frustrating, I seem to be chasing my tail now. The apache-cxf-2.0.5-incubator seems to contain a hacked verison of CxfMessageAdapter. I could potentially 'fix' this by finding the jar where the class is located, unjarring it, and replacing the class file in the jar with the compiled class from src-override, then rejarring.

But I'm getting a strong whiff of other differences between apache-cxf-2.0.5-incubator and apache-cxf-2.0.7 - I see no reason why CxfMessageAdapter would cause the generator to generate CoCPortTypeImpl sans delegate.

So at this point I'm going to give up and wait for input from you, Tjis.
Don Stadler (74) [Avatar] Offline
#3
I checked on Apache CXF.....
Apache CXF currently offers version 2.0.9 on the 2.0 release tree, and doesn't seem to allow downloads of any older versions, much less 2.0.5-incubator. So the chapter 7 examples seem to be dependent upon an unobtainable older variant of Apache CXF.

Hmmm, found something else on the CXF website which could be related:

Can CXF run with JDK 1.6?

JDK 1.6 incorporates the JAXB reference implementation. However, it incorporates an old version of the RI. CXF does not support this version. As of 1.6_04, this is easy to deal with: you must put the versions of JAXB RI (the 'impl' and 'xjc' jars) that we include with CXF in your classpath. As of this writing, these are version 2.1.6.

I am using JDK 1.6_07. Ok, so where is the flaming classpath getting set?

The other thing that strikes me as a bit weird is that this seems to work with JDK 1.5.*, but JDK 1.6.* uses an 'old version' of JAXB?!!!!

Message was edited by:
Don Stadler
Don Stadler (74) [Avatar] Offline
#4
Re: I checked on Apache CXF.....
Ok, I just had a look at the ch7-build.xml file:

<target name="cxf-generate-server-stubs" depends="init" description="generate the server stubs">

<path id="cxf.path">
<fileset dir="${lib.home}/apache-cxf-2.0.7/modules">
<include name="*.jar" />
</fileset>
<fileset dir="${lib.home}/apache-cxf-2.0.7/lib">
<include name="*.jar" />
</fileset>
</path>


<java classname="org.apache.cxf.tools.wsdlto.WSDLToJava" fork="true">
<arg value="-server" />
<arg value="-impl" />
<arg value="-d" />
<arg value="${workspace.home}/src-generated" />
<arg value="${chapter.home}/wsdl-top-down/cxf/wsdl/CoC.wsdl" />
<classpath>
<path refid="cxf.path" />
</classpath>
</java>

The jar files jaxb-xjc-2.0.0.jar and jaxb-impl.2.0.5 are in osesbinactionlibrariesapache-cxf-2.0.7lib. Looking at the buildfile definition above it seems to me that these jar files are in the classpath.

Ok, I just downloaded and unzipped CXF version 2.0.9, looked at the jars - they are the same version as in 2.0.7. Not the 2.1.6 versions he mentions. He must be referring to CXF 2.1.3 which is the other release tree.

The inescapble conclusion is that in order to run this example I must regress to Java 5. Grrrrrrr!
Don Stadler (74) [Avatar] Offline
#5
Auto-generated CoCPortTypeImpl must be changed?
I've been digging into the description of CoCPortTypeImpl on page 253. At the bottom of the first paragraph abover Listing 7.8, is written:

"We don't show you the complete stub implementation but focus only on the parts which need to be changed"

That explains why I'm having the delegate problem, particularly when one looks at the text below Listing 7.8, which seem to imply that this is referring to the unmodified stub code, not modified code. At no point is it unambigous that the generated stub needs to be changed.

Later .....

I modified the CoCPortTypeImpl class to use the delegate and it seems to be working to the pont where I have Mule started up correctly.
Don Stadler (74) [Avatar] Offline
#6
Mule top-down & consume-ws not working together
When following the instructions on page 264 I tried to run ant -f ch7-build.xml chapter7-top-down. This target does not exit in ch7-build.xml, but another target named chapter7-top-down-provide exists, so I substituted this target, which starts Mule.

Then I ran ant -f ch7-build.xml chapter7-consum-ws, and it produced the following output:

chapter7-consume-ws:

gn:init:
[echo] Mule home is set to C:osesbinactionesbmule-2.0.2.
[echo] Workspace home is set to C:osesbinactionworkspaceworkspace-mule.

gn:run-mule-with-xmlconfig:
[java] FATAL ERROR in native method: JDWP No transports initialized, jvmtiE
rror=JVMTI_ERROR_INTERNAL(113)
[java] ERROR: transport error 202: bind failed: Address already in use ["tr
ansport.c",L41]
[java] ERROR: JDWP Transport dt_socket failed to initialize, TRANSPORT_INIT
(510) ["debugInit.c",L500]
[java] JDWP exit error JVMTI_ERROR_INTERNAL(113): No transports initialized

[java] Java Result: 1

BUILD SUCCESSFUL
Total time: 1 second


It appears to be failing because the top-down-provide target is binding to the same address as consume-ws is. What am I supposed to be doing here?

What is the 'test-file' you refer to? There are two candidates in consume-wsdl, the query1.xml and consume-wsdl.xml. Is the target directory under esbmule-2.0.2 or under the resourceschapter7 directory. I would assume the former (under mule) except that there is no existing directory of that name under mule, nor under resources either.

As a general comment, I am having considerable difficulty with the mismatch between the book instructions and what I'm seeing in my environment. Some of it is due to my own mistakes, not understanding subtle hints in the book text, but some of it is simply that targets do not exist or are renamed. And in this case I'm guessing that 'top-down' is not at all the same thing as 'top-down-provide', and if that is true the book's instructions really don't give a clear idea how to run the examples.

I had hopes of finishing chapter 7 last night or today at the latest, instead I find myself at an impass on the first example after spending most of the day troubleshooting. It's pretty frustrating...
tijs.rademakers (494) [Avatar] Offline
#7
Re: Mule top-down & consume-ws not working together
Hi Don,

First, your comments really help to make the example descriptions better for every reader and points me to the examples that probably needed better explanation.

Second, please understand that we chose to use a lot of different tools and frameworks in the book's examples to make it really useful for readers. It's difficult to offer an plug and play working environment for this full set of tools. So we gave it a try, and for some parts we succeeded, other parts need improvement. But please keep the questions and comments coming and we'll deal with them rightaway.

I've committed a few updates to the Mule examples in Google code. So you can update the Mule code with a SVN client (Subclipse). The error message you described with the JDWP no transports initialized is now solved. Also note that the generated source code for the web service is already present in the provided Mule source code (so with the delegate attribute). So you can go back to the original version and you can run the examples rightaway.

Note that to run the WS-Security examples, you also need to copy the bouncycastle jar to the lib/user directory. You can download the jar from http://www.bouncycastle.org/latest_releases.html.

Let me know if this solves your problems. Hope you still have the same enthusiasm as before chapter 7!

Best regards,

Tijs
Don Stadler (74) [Avatar] Offline
#8
Re: Mule top-down & consume-ws not working together
Tjis,

Sorry if my tone was a bit over the top when I wrote that yesterday. Over the past 24 hours I had been tilting at windmills all day. No sooner had Don Quioxte vanquished one arm of the windmill than another hit him in the back and unhorsed him! Again and again and again.

When that happens there is a real tendency to blame oneself for your idiocy or to think that something is really fundamentally wrong.

Given all the "I'm not finding this and that and the other thing' errors I was getting yesterday I think I have to redo the environment again. Because I'm not seeing what you are seeing - my environment can't seem to run anything in Chapter 7 without falling over and repeated patch jobs.
Don Stadler (74) [Avatar] Offline
#9
bouncycastle?
Tjis, there were a bunch of jars. I copied the 6 which seemd to go with Java 1.6 into the lib/user. I hope it works tomorrow.
Don Stadler (74) [Avatar] Offline
#10
No response in outbox when run in test client.
This time there seems to be little or nothing in the trace logs to indicate something going wrong.

I do note that the the test client has username, password, and realm text boxes.

I have been ignoring these boxes because the test instuctions in the book are merely to 'run the test' using SoapUI or the test client, no mention of name-password, or realm that I can see. Unless it's buried in the text back somewhere.

Later: Ok, I've pored through the top-down descriptions for the Mule and Servicemix top-down and also looked at appendix F to see whether there exists a clue on how to run this test. Nothing about the username, password, or realm that I can see. So if this rare bird exists it is caged elsewhere.

Que?!!!! Traces follow:

13-Dec-2008 21:47:02 osesbtestclient.OsesbtestclientView closeAllConnections
INFO: Switching example, closing all active listeners
message <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelop <br /> e/" xmlns:coc="http://opensource.esb.org/CoC/">
<soapenv:Header/>
<soapenv:Body>
<coc:getCompany>
<companyName>Holthouse Carlin & Van Tright LLP (HCVT)</companyName>

</coc:getCompany>
</soapenv:Body>
</soapenv:Envelope>
13-Dec-2008 21:47:04 org.apache.commons.httpclient.HttpMethodBase getResponseBod
y
WARNING: Going to buffer response body of large or unknown size. Using getRespon
seBodyAsStream instead is recommended.
message <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelop <br /> e/" xmlns:coc="http://opensource.esb.org/CoC/">
<soapenv:Header/>
<soapenv:Body>
<coc:getCompany>
<companyName>Holthouse Carlin & Van Tright LLP (HCVT)</companyName>

</coc:getCompany>
</soapenv:Body>
</soapenv:Envelope>
13-Dec-2008 21:47:29 org.apache.commons.httpclient.HttpMethodBase getResponseBod
y
WARNING: Going to buffer response body of large or unknown size. Using getRespon
seBodyAsStream instead is recommended.




C:osesbinactionworkspaceworkspace-mulemule esourceschapter7>ant -f ch7-bui
ld.xml chapter7-top-down-provide
Buildfile: ch7-build.xml

gn:init:
[echo] Mule home is set to C:osesbinactionesbmule-2.0.2.
[echo] Workspace home is set to C:osesbinactionworkspaceworkspace-mule.

chapter7-top-down-provide:

gn:init:
[echo] Mule home is set to C:osesbinactionesbmule-2.0.2.
[echo] Workspace home is set to C:osesbinactionworkspaceworkspace-mule.

gn:compile-classes:
[javac] Compiling 17 source files to C:osesbinactionworkspaceworkspace-mu
lemuleclasses
[javac] Note: C:osesbinactionworkspaceworkspace-mulemulesrcesbchapter
7TestPwdCallback.java uses unchecked or unsafe operations.
[javac] Note: Recompile with -Xlint:unchecked for details.
[jar] Building jar: C:osesbinactionesbmule-2.0.2libuserchapter7-topd
own.jar

gn:init:
[echo] Mule home is set to C:osesbinactionesbmule-2.0.2.
[echo] Workspace home is set to C:osesbinactionworkspaceworkspace-mule.

gn:run-mule-with-xmlconfig:
[echo] Compiling classes

gn:init:
[echo] Mule home is set to C:osesbinactionesbmule-2.0.2.
[echo] Workspace home is set to C:osesbinactionworkspaceworkspace-mule.

gn:compile-generated-classes:
[java] Listening for transport dt_socket at address: 8000
[java] INFO - MuleServer - Mule Server initializing...

[java] INFO - MuleApplicationContext - Refreshing org.mule.config.
spring.MuleApplicationContext@1cc5d23: display name [org.mule.config.spring.Mule
ApplicationContext@1cc5d23]; startup date [Sat Dec 13 21:45:51 GMT 2008]; root o
f context hierarchy
[java] INFO - MuleApplicationContext - Bean factory for applicatio
n context [org.mule.config.spring.MuleApplicationContext@1cc5d23]: org.springfra
mework.beans.factory.support.DefaultListableBeanFactory@f2ff9b
[java] INFO - CxfConnector - Initialising: CxfConnector{
this=1fe0dcb, started=false, initialised=false, name='connector.cxf.0', disposed
=false, numberOfConcurrentTransactedReceivers=4, createMultipleTransactedReceive
rs=true, connected=false, supportedProtocols=[cxf, cxf:http, cxf:https, cxf:jms,
cxf:vm, cxf:servlet], serviceOverrides=null}
[java] 13-Dec-2008 21:45:53 org.apache.cxf.bus.spring.BusApplicationContext
getConfigResources
[java] INFO: No cxf.xml configuration file detected, relying on defaults.
[java] INFO - DefaultExceptionStrategy - Initialising exception list
ener: org.mule.DefaultExceptionStrategy@1271a80
[java] INFO - DefaultJavaComponent - Initialising: org.mule.comp
onent.DefaultJavaComponent component for: null
[java] INFO - AutoConfigurationBuilder - Configured Mule using "org.
mule.config.spring.SpringXmlConfigurationBuilder" with configuration resource(s)
: "[ConfigResource{resourceName='wsdl-first.xml'}]"
[java] INFO - AutoConfigurationBuilder - Configured Mule using "org.
mule.config.builders.AutoConfigurationBuilder" with configuration resource(s): "
[ConfigResource{resourceName='wsdl-first.xml'}]"
[java] INFO - MuleServer - Mule Server starting...
[java] INFO - CxfConnector - Starting: CxfConnector{this
=1fe0dcb, started=false, initialised=true, name='connector.cxf.0', disposed=fals
e, numberOfConcurrentTransactedReceivers=4, createMultipleTransactedReceivers=tr
ue, connected=true, supportedProtocols=[cxf, cxf:http, cxf:https, cxf:jms, cxf:v
m, cxf:servlet], serviceOverrides=null}
[java] INFO - CxfConnector - Started: CxfConnector{this=
1fe0dcb, started=true, initialised=true, name='connector.cxf.0', disposed=false,
numberOfConcurrentTransactedReceivers=4, createMultipleTransactedReceivers=true
, connected=true, supportedProtocols=[cxf, cxf:http, cxf:https, cxf:jms, cxf:vm,
cxf:servlet], serviceOverrides=null}
[java] INFO - CxfConnector - Connected: CxfConnector{thi
s=1fe0dcb, started=true, initialised=true, name='connector.cxf.0', disposed=fals
e, numberOfConcurrentTransactedReceivers=4, createMultipleTransactedReceivers=tr
ue, connected=true, supportedProtocols=[cxf, cxf:http, cxf:https, cxf:jms, cxf:v
m, cxf:servlet], serviceOverrides=null}
[java] INFO - DefaultJavaComponent - Starting: org.mule.componen
t.DefaultJavaComponent component for: cocService
[java] INFO - CxfConnector - Registering listener: cocSe
rvice on endpointUri: http://localhost:8080/services/coc
[java] 13-Dec-2008 21:45:55 org.apache.cxf.service.factory.ReflectionServic
eFactoryBean buildServiceFromWSDL
[java] INFO: Creating Service {http://opensource.esb.org/CoC/}CoCService fr
om WSDL: CoC.wsdl
[java] 13-Dec-2008 21:45:57 org.apache.cxf.endpoint.ServerImpl initDestinat
ion
[java] INFO: Setting the server's publish address to be http://localhost:80
80/services/coc
[java] INFO - HttpConnector - Initialising: HttpConnector
{this=3b2558, started=false, initialised=false, name='connector.http.0', dispose
d=false, numberOfConcurrentTransactedReceivers=4, createMultipleTransactedReceiv
ers=true, connected=false, supportedProtocols=[http], serviceOverrides=null}
[java] INFO - DefaultExceptionStrategy - Initialising exception list
ener: org.mule.DefaultExceptionStrategy@1568c61
[java] INFO - HttpConnector - Starting: HttpConnector{thi
s=3b2558, started=false, initialised=true, name='connector.http.0', disposed=fal
se, numberOfConcurrentTransactedReceivers=4, createMultipleTransactedReceivers=t
rue, connected=true, supportedProtocols=[http], serviceOverrides=null}
[java] INFO - HttpConnector - Started: HttpConnector{this
=3b2558, started=true, initialised=true, name='connector.http.0', disposed=false
, numberOfConcurrentTransactedReceivers=4, createMultipleTransactedReceivers=tru
e, connected=true, supportedProtocols=[http], serviceOverrides=null}
[java] INFO - HttpConnector - Connected: HttpConnector{th
is=3b2558, started=true, initialised=true, name='connector.http.0', disposed=fal
se, numberOfConcurrentTransactedReceivers=4, createMultipleTransactedReceivers=t
rue, connected=true, supportedProtocols=[http], serviceOverrides=null}
[java] INFO - DefaultTransportServiceDescriptor - Loading default response
transformer: org.mule.transport.http.transformers.MuleMessageToHttpResponse
[java] INFO - CxfMessageReceiver - Connected: CxfMessageReceiv
er{this=44e906, receiverKey=http://localhost:8080/services/coc, endpoint=http://
localhost:8080/services/coc}
[java] INFO - SedaService - Service cocService has been
started successfully
[java] INFO - TransactionalQueueManager - Starting ResourceManager
[java] INFO - TransactionalQueueManager - Started ResourceManager
[java] INFO - DefaultMuleContext -
[java] ********************************************************************
**
[java] * Mule ESB and Integration Platform
*
[java] * Version: 2.0.2 Build: 12377
*
[java] * MuleSource, Inc.
*
[java] * For more information go to http://mule.mulesource.org
*
[java] *
*
[java] * Server started: 13/12/08 21:45
*
[java] * Server ID: 692bff6c-c95f-11dd-9fec-ad44101f1b7c
*
[java] * JDK: 1.6.0_07 (mixed mode)
*
[java] * OS: Windows Vista - Service Pack 1 (6.0, x86)
*
[java] * Host: Don-PC (192.168.1.64)
*
[java] *
*
[java] * Agents Running: None
*
[java] ********************************************************************
**
[java] INFO - DefaultJavaComponent - Initialising: org.mule.comp
onent.DefaultJavaComponent component for: _cxfServiceComponent{http://opensource
.esb.org/CoC/}CoCService1683664
[java] INFO - DefaultJavaComponent - Starting: org.mule.componen
t.DefaultJavaComponent component for: _cxfServiceComponent{http://opensource.esb
.org/CoC/}CoCService1683664
[java] INFO - HttpConnector - Registering listener: _cxfS
erviceComponent{http://opensource.esb.org/CoC/}CoCService1683664 on endpointUri:
http://localhost:8080/services/coc
[java] INFO - HttpMessageReceiver - Connected: HttpMessageRecei
ver{this=4a4890, receiverKey=http://localhost:8080/services/coc, endpoint=http:/
/localhost:8080/services/coc}
[java] INFO - SedaService - Service _cxfServiceComponen
t{http://opensource.esb.org/CoC/}CoCService1683664 has been started successfully

[java] INFO - HttpMessageReceiver - Closing HTTP connection.
[java] INFO - HttpMessageReceiver - Closing HTTP connection.

Message was edited by:
Don Stadler
tijs.rademakers (494) [Avatar] Offline
#11
Re: No response in outbox when run in test client.
You are right to ignore the username, password and realm text boxes, they are only necessary for the examples of chapter 8. Based on the output you mentioned here, I think the web service call has executed well. In the Swing test client you'll see that the input box, actually consists of two boxes. When you expand it a bit you'll see. The web service response is shown in the second box of the input section.
But you're right, there's not a lot of logging that shows the web service call has executed well. What you can do, is set the logging level of Mule to debug, then you'll see quite a lot more logging messages.

Best regards,

Tijs
Don Stadler (74) [Avatar] Offline
#12
Ok, it worked.
I ran this test with the in window expanded so I could see the other window and saw the message go out.
Don Stadler (74) [Avatar] Offline
#13
Chapter 7 Mule bottom-up example also worked....
Just ran it and the response looks good.