Thanks fore the effort Daniel, I got it to work now. Using the XmlUtils
class to load the XML and moving the xml file to services/muse was
already enough to get it to work (i'll look into the XML compliance also).
Gero
Daniel Jemiolo wrote:
1. Yes, the accept/process were called and the messages logged to the
console.
2. I was using JDK 1.5.0 on Tomcat 5.0 on WinXP SP2.
3. org.apache.muse.util.xml contains a lot of XML utilities that were
essential to building Muse, and I suspect a lot of users will find them
useful. It seems every Java project that uses XML has such a set of
DOM-based utilities - might as well reuse when possible. I will open a
JIRA item for documentation of XmlUtils in the manual. In the meantime,
the JavaDoc for that class is quite comprehensive.
Dan
"Gero Vermaas" <[EMAIL PROTECTED]> wrote on 10/18/2006 01:30:43 PM:
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
