Bug 779722 (SOA-2084) - EBWS: deployment fails with xsd in nested locations and <xs:import ../>
Summary: EBWS: deployment fails with xsd in nested locations and <xs:import ../>
Keywords:
Status: CLOSED NEXTRELEASE
Alias: SOA-2084
Product: JBoss Enterprise SOA Platform 5
Classification: JBoss
Component: JBossESB
Version: 5.0.0 GA
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: ---
: 5.0.2
Assignee: Kevin Conner
QA Contact:
URL: http://jira.jboss.org/jira/browse/SOA...
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-05-14 10:00 UTC by Martin Weiler
Modified: 2010-06-11 04:05 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-05-28 13:16:18 UTC
Type: Bug
Embargoed:


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


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker SOA-2084 0 Major Closed EBWS: deployment fails with xsd in nested locations and <xs:import ../> 2013-05-14 13:27:50 UTC

Description Martin Weiler 2010-05-14 10:00:27 UTC
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"/>  
            </actions>

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 10:03:38 UTC
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 10:03:38 UTC
Attachment: Added: publish_as_webservice_soa50.zip


Comment 3 Kevin Conner 2010-05-20 11:51:51 UTC
Link: Added: This issue depends JBESB-3322


Comment 4 Kevin Conner 2010-05-20 12:47:40 UTC
Updated in the ESB codebase, will be in the next merge.

Comment 5 Boris Belovic 2010-05-28 13:16:17 UTC
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 05:48:59 UTC
Added to the SOA 5.0.2 release notes as resolved:

JBESB-3322
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 08:40:57 UTC
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 04:05:24 UTC
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.