We recently upgraded to JBoss 4.0.4 with the JBossWS stack and are noticing
what may be a bug in JBossWS.
When it comes to defining faults in our messages, all instances of the fault
name must be EXACTLY the same in our XSD and all points in our WSDL.
For example. This works.
OurService.xsd
I have 2 projects in my Eclipse IDE that are both required to run our
application, but should be managed as separate projects.
To run them together, the build output of our .java files should go to the same
directory where our JBoss server picks it up.
However, if I configure each project to ha
Correction on the end of my previous post...
The xsd directory is a CHILD of the wsdl directory, NOT a sibling.
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3948562#3948562
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply
Using the wstools shipped with the JBossWS stack in JBoss 4.0.4.GA (and using
Java 1.5.0_06), we can successfully generate artifacts for our WSDL if the XSD
it references contains every xs:complexType therein.
However, we want to reuse many XML structures. Hence we have put our
re-useable xs:c
As Java EE 5 is scheduled for release Q1 '06, is there a target release date
for a fully Java EE 5-certified version of JBoss AS?
If not, what is the best approach for implementing the Java EE 5 specifications
for Web Services technologies (i.e. JAXB 2.0, JAX-WS 2.0, StAX, Web Services
Metadat
As Java EE 5 is scheduled for release Q1 '06, is there a target release date
for a fully Java EE 5-certified version of JBoss AS?
If not, what is the best approach for implementing the Java EE 5 specifications
for Web Services technologies (i.e. JAXB 2.0, JAX-WS 2.0, StAX, Web Services
Metadata
Did you ever get a resolution to this? I'm seeing the same thing (used
JavaService 2.0.9 for our install). The out.log has shows
FileNotFoundExceptions for all files our application tries to load...for
example...
java.io.FileNotFoundException:
C:\dev\jboss\JBoss-4.0.3SP1_Tomcat-5.5_SSL\serve
I actually figured it out. A 3rd party XML/HTML parser (cyberneko) was
installed in our codebase, and it was being picked up instead of the default
Xerces parser because it was configured in the META-INF/services directory to
do so. Looks like JBoss and Xerces were doing there job just fine.
I have installed a minimal JBoss 4.0.3SP1 server and have added just the
minimal amount of components to run our needs (i.e. for data source, Web Apps
and not much else).
When I try to parse an XML document using standard JDOM SAXBuilder code (this
has been running successfully years on other a
