Thanks Daniel, I'm currently not at my development machine and probably will not be the rest of the day. Couple of questions/comments to make sure I understand everything correct and can continue tomorrow:
* Do I understand it correct that after you made the changes/fixes described in you mail the wsn-producer was able to sent the message and the wsn-consumer did receive the message correct in the accept()/process() methods of the ConsumerCapabilityImpl? * The fact that the XML was not loaded correctly when you ran the example is probably due to a difference in our setups. The messages I had in the first mail of the subject were logged by the producer and these did contain the content retrieved from the XML file. What version of JDK and ServletContainer/Appserver are you using? I was using JDK1.5_06 and Tomcat 5.5 on Ubuntu Dapper Drake. (6.06) * I'll check the schema compliance issues and move the file to WEB-INF/services/muse * I must confess that I had some trouble to include the content of the XML file in the message. I missed the helper methods on the XmlUtils class and suspect that they also will make live easier. Thanks for pointing these out to me. Regards, Gero -----Original Message----- From: Daniel Jemiolo [mailto:[EMAIL PROTECTED] Sent: Wed 10/18/2006 6:35 PM To: [email protected] Subject: Re: Messages not accepted by WSN Consumer I saw this error in the console when I tried to load the trouble ticket XML doc: java.net.MalformedURLException at java.net.URL.<init>(URL.java:601) at java.net.URL.<init>(URL.java:464) at java.net.URL.<init>(URL.java:413) at org.apache.xerces.impl.XMLEntityManager.setupCurrentEntity(Unknown So urce) at org.apache.xerces.impl.XMLVersionDetector.determineDocVersion(Unknown Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.XMLParser.parse(Unknown Source) at org.apache.xerces.parsers.DOMParser.parse(Unknown Source) at org.apache.xerces.jaxp.DocumentBuilderImpl.parse(Unknown Source) at org.apache.ws.muse.test.wsrf.MyCapabilityImpl$1.run(Unknown Source) There were two problems: 1. Your use of .class to get the XML doc in the classpath was failing. 2. Your XML document is not schema compliant. At any rate, this exception ends the thread, so no messages are ever published. That's why you see the consumer initialized but no XML ever sent. I threw the XML doc into Eclipse's XML editor and it pointed me to two issues: 1. Your xsi:schemaLocation attribute is not formatted properly. This attribute is two URIs separated by a space - first one for the schema namespace, second for the schema location. You only had the latter. 2. Once I fixed that, it started complaining that the <co:url/> element was not compliant with the Common XSD imported by the TroubleTicket XSD. First sub-problem was that you had quotes around the URI. I took those out and it was still complaining. Second sub-problem I figured out after looking at the Common XSD - the name of the element is <URL/>, not <url/> (case sensitivity). With those issues resolved, the trouble ticket XML fragment is compliant and is loaded by the parser. Once I fixed the schema compliance, there was the issue of loading the file itself. I think that the .class system is not workign because Axis2 has a separate class loader that overrides the J2EE class loader; because Axis2 is a platform on top of J2EE, it keeps its services separate - you're not supposed to share things through WEB-INF/classes. I moved the XML doc from WEB-INF/classes to WEB-INF/services/muse. Then I added the following code: File file = new File(getEnvironment().getRealDirectory(), "troubleTicketCreateEvent.xml"); Document doc = XmlUtils.createDocument(file); Element payload = XmlUtils.getFirstElement(doc); This allowed me to load the doc correctly, and now the messages are sent with your payload. getEnvironment().getRealDirectory() returns the File for WEB-INF/services/muse. To summarize: make the minor changes to make the doc schema compliant, move the doc to WEB-INF/services/muse, and then use the code above to access to it. Dan Dan Jemiolo IBM Corporation Research Triangle Park, NC +++ I'm an engineer. I make slides that people can't read. Sometimes I eat donuts. +++ Gero Vermaas <[EMAIL PROTECTED]> wrote on 10/18/2006 03:13:32 AM: > Daniel, > > Just curious, have you been able to reproduce the issue using the files > a provided? > > Regards, > Gero > > Gero Vermaas wrote: > > Mmm... that a tough question cause I refactored the examples to Maven > > based build, but... I reproduced the issue in the original samples, > > see attached the modified/added files. For completeness I also created > > a zip file containing both sample projects, this can be downloaded at > > http://gerodt.homeip.net/wsn-samples.zip (this file is ~45M, but the > > attached files should enable you to reproduce it). > > > > Changed in wsn-consumer: > > > > * Added 'run' target in build.xml > > > > Changed in wsn-producer: > > > > * Added file 'troubleTicketCreateEvent.xml' to root dir of the > > wsn-producer project (next to build.xml etc) > > * Added copy step to to build.xml include > > 'troubleTicketCreateEvent.xml' in WEB-INF/classes > > * Changed the run() method in > > src/org/apache/ws/muse/test/wsrf/MyCapabilityImpl.java to > > include the contents of 'troubleTicketCreateEvent.xml' in the > > notify message (and added imports) > > > > Build and deploy both wars (I used tomcat) and then do a 'ant run' for > > the wsn-consumer. > > > > If you take the original wsn-producer.war file you will see 'INFO: > > Received message:... ' messages in the catalina.out file of Tomcat. > > The messages are logged by the ConsumerCapabilityImpl class of the > > wsn-consumer. > > > > Once you deploy the modified wsn-producer that sends the contents of > > the 'troubleTicketCreateEvent.xml' as notification, the 'INFO: > > Received message:... ' messages will no longer be logged and the > > accept() and process() messages in the consumer are no longer being > > invoked. > > > > Thanks for looking into it. > > > > Regards, > > Gero > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
