[
https://issues.apache.org/jira/browse/AXIS2-2584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12491340
]
Steven E. Harris commented on AXIS2-2584:
-----------------------------------------
Keith, yes, the problem arises with at least two levels of importing: my WSDL
imports one XML Schema file, which in turn imports three other XML Schema files.
Per my comment about the JAR URIs above, I'm not sure we can blame the
ws-commons's DefaultURIResolver. It's trying to do the right thing; I think the
problem lies with the JRE's treatment of JAR-scheme URIs being opaque, and not
doing anything with URI.resolve() other than returning the given relative URI
back as the resolved URI.
I found this discussion about a special URI class used in the Eclipse project's
EMF:
http://www.brandonwerner.com/2007/04/19/eclipse-modeling-framework-examination-and-that-mean-websphere-error/
http://help.eclipse.org/help32/index.jsp?topic=/org.eclipse.emf.doc/references/javadoc/org/eclipse/emf/common/util/URI.html
Check out the paragraph that starts as follows:
"The other enhancement provides support for the almost-hierarchical form used
for files within archives, such as the JAR scheme, defined for the Java
Platform in the documentation for JarURLConnection."
Eclipse introduced a whole new class to deal -- at least in part -- with this
archive URI resolution problem.
> AAR deployment fails with a WSDL 2 document due to spaces in path to AAR file
> (interpreted as a URI)
> ----------------------------------------------------------------------------------------------------
>
> Key: AXIS2-2584
> URL: https://issues.apache.org/jira/browse/AXIS2-2584
> Project: Axis 2.0 (Axis2)
> Issue Type: Bug
> Components: deployment
> Affects Versions: nightly
> Environment: Windows XP, Apache Tomcat 6
> Reporter: Steven E. Harris
> Assigned To: Keith Godwin Chapman
> Attachments: ArchiveReader.java.diff
>
>
> The class org.apache.axis2.deployment.repository.util.ArchiveReader attempts
> to construct a JAR-based URI in its processWSDLFile() method:
> } else if (axisServiceBuilder instanceof
> WSDL20ToAxisServiceBuilder) {
> // trying to use the jar scheme as the base URI. I think
> this can be used to handle
> // wsdl 1.1 as well without using a custome URI resolver.
> Need to look at it later.
> axisServiceBuilder.setBaseUri(
> "jar:file://" +
> serviceArchiveFile.getAbsolutePath() + "!/" + baseURI);
> }
> The call to "serviceArchiveFile.getAbsolutePath()" creates a path string with
> embedded spaces and backslashes (on Windows). The java.net.URI constructor
> rejects such a path, emitting an error such as:
> INFO: Trouble processing wsdl file :Illegal character in opaque part at index
> 13: jar:file://C:\Program
> Files\\apache-tomcat-6.0.10\webapps\axis2\WEB-INF\services\my.service.aar!/META-INF/myservice.wsdl
> Note that it's complaining about the backslash after the "C:' part.
> The fix is simple: build the new URI from yet another URI:
> axisServiceBuilder.setBaseUri(
> "jar:" + serviceArchiveFile.toURI() + "!/" +
> baseURI);
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
