Bug 779722 - (SOA-2084) EBWS: deployment fails with xsd in nested locations and <xs:import ../>
EBWS: deployment fails with xsd in nested locations and <xs:import ../>
Product: JBoss Enterprise SOA Platform 5
Classification: JBoss
Component: JBossESB (Show other bugs)
5.0.0 GA
Unspecified Unspecified
high Severity high
: ---
: 5.0.2
Assigned To: Kevin Conner
Depends On:
  Show dependency treegraph
Reported: 2010-05-14 06:00 EDT by Martin Weiler
Modified: 2010-06-11 00:05 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2010-05-28 09:16:18 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
publish_as_webservice_soa50.zip (11.98 KB, application/zip)
2010-05-14 06:03 EDT, Martin Weiler
no flags Details

External Trackers
Tracker ID Priority Status Summary Last Updated
JBoss Issue Tracker SOA-2084 Major Closed EBWS: deployment fails with xsd in nested locations and <xs:import ../> 2013-05-14 09:27:50 EDT

  None (edit)
Description Martin Weiler 2010-05-14 06:00:27 EDT
Date of First Response: 2010-05-20 08:47:40
Help Desk Ticket Reference: https://enterprise.redhat.com/issue-tracker/871863
project_key: SOA

Deployment of the following EBWS fails if the referenced xsd file contains a <xs:import ../> element:

            <actions  inXsd="/META-INF/request.xsd" outXsd="/META-INF/response.xsd" faultXsd="/META-INF/fault.xsd" validate="true">
                   <action name="action" class="org.jboss.soa.esb.samples.quickstart.publishAsWebservice.ESBWSListenerAction" process="displayMessage"/>  

The same action works if
- the xsd files are in the root of the *.esb archive OR
- the xsd files do not contain further import statements

Deployment failure:
Caused by: java.lang.IllegalArgumentException: Cannot resolve imported resource: vfsmemory://publish_as_webservice_WSDL/META-INF/types/custom-request-type.xsd
Comment 1 Martin Weiler 2010-05-14 06:03:38 EDT
Attaching a modified version of the publish_as_webservice quickstart of SOA-P 5 to reproduce this issue. The *.xsd files have been moved into the META-INF folder, and the inXsd/outXsd/faultXsd have been modified accordingly, eg. inXsd="/META-INF/request.xsd".
Comment 2 Martin Weiler 2010-05-14 06:03:38 EDT
Attachment: Added: publish_as_webservice_soa50.zip
Comment 3 Kevin Conner 2010-05-20 07:51:51 EDT
Link: Added: This issue depends JBESB-3322
Comment 4 Kevin Conner 2010-05-20 08:47:40 EDT
Updated in the ESB codebase, will be in the next merge.
Comment 5 Boris Belovic 2010-05-28 09:16:17 EDT
Verified in SOA-P 5.0.2 CR1, production profile.
Deployment of the ESB service is successful, all imported XSD files (including nested imports) can be resolved without any problems.
Comment 6 Dana Mison 2010-06-09 01:48:59 EDT
Added to the SOA 5.0.2 release notes as resolved:

ESB archives would fail to deploy if they referenced xsd files that contained <xs:import ../> element:s. 
When the deployment was attempted an exception IllegalArgumentException.would be thrown.
This has been fixed and all all imported XSD files (including nested imports) can be resolved without any problems.

Comment 7 Kevin Conner 2010-06-09 04:40:57 EDT
The import will only fail if the original schema was not in the top level of the deployment, for example included in the META-INF directory, as the referenced imports/includes would be made from the top level rather than where the schema was located.
Comment 8 Dana Mison 2010-06-11 00:05:24 EDT
udpated release note content:

ESB archives could fail to deploy if they contained XSD files that were not in the root directory of the archive. If the XSD file was in a sub-directory of the archive and contained <xs:import ../> statements, deployment would fail and thrown an exception (IllegalArgumentException). This was because the paths for import elements where resolved from the root of the archive and not from the location of the XSD file. This has been fixed and the paths for imported XSD files (including nested imports) are resolved correctly. 

Note You need to log in before you can comment on or make changes to this bug.