[jira] Commented: (AXIS2-748) AARWSDLLocator incorrect logic - may load incorrect files under certain scenarios

["Dave MacLean (JIRA)" <ji...@apache.org>]

    [ http://issues.apache.org/jira/browse/AXIS2-748?page=comments#action_12412416 ] 

Dave MacLean commented on AXIS2-748:
------------------------------------

Further comment on another related bug (the first bug mentioned below is the one originally logged, but is included for context for the second):

It looks like may be 2 problems with the way schema imports are loaded from the aar files.

The first, is that when the AARFileBasedURIResolver is searching for a given (relative) location, it only matches beginning and end.  That is, if I'm importing a schema at relative location "xsd/my_schema.xsd", then the resolver is going to match any files in the aar that have a path starting with "meta-inf" and ending with "xsd/my_schema.xsd".

So, if my aar file structure looks like:

meta-inf/my_wsdl.wsdl  (has the import of xsd/my_schema.xsd) 
meta-inf/xsd/my_schema.xsd 
meta-inf/some_other_bad_but_useful_xsd/my_schema.xsd

Then, in some cases the second xsd will get loaded, which can cause some problems.


For the second, assume the same scenario as above, with my_wsdl.wsdl importing xsd/my_schema.xsd.

Now, if my_schema.xsd imports another xsd, using a relative location of "my_schema2.xsd", then I don't think the resolver takes the relative path into consideration.  It ends up searching for a file starting with "meta-inf" and ending with "my_schema2.xsd".

It just happens that this will match meta-inf/xsd/my_schema2.xsd (which is what we want), but it will also match a lot of other files incorrectly (meta-inf/some_other_bad_but_useful_xsd/my_schema2.xsd, meta-inf/foobar/my_schema2.xsd, etc).

Is my understanding of how relative imports should work correct?  That if xsd/my_schema.xsd imports a file at location "my_schema2.xsd", then 
it should be found, and only be found, at xsd/my_schema2.xsd?

I think one way to fix this would be to update the baseUri passed into AARFileBasedURIResolver.resolveEntity to include the "path found so far", and then modify the filename checking if-clause to be a little more strict.


> AARWSDLLocator incorrect logic - may load incorrect files under certain scenarios
> ---------------------------------------------------------------------------------
>
>          Key: AXIS2-748
>          URL: http://issues.apache.org/jira/browse/AXIS2-748
>      Project: Apache Axis 2.0 (Axis2)
>         Type: Bug

>   Components: deployment
>     Versions: 1.0
>  Environment: win32_x86 (windows xp sp2), tomcat 5.1, eclipse 3.2 with tomcat plugin, axis 2.0 1.0, Intel P4 2.8Ghz, 2.00GB RAM
>     Reporter: Dave MacLean
>     Priority: Minor

>
> The following code in AARWSDLLocator.java will fail in a certain scenario (described below):
> ...
>             while ((entry = zin.getNextEntry()) != null) {
>                 String entryName = entry.getName();
>                 if ((entryName.startsWith(DeploymentConstants.META_INF.toLowerCase())
>                         || entryName.startsWith(DeploymentConstants.META_INF))
>                         && entryName.endsWith(importLocation)) {
> ...
> If I have a wsdl file that has an import like:
> <s:import namespace="some_namespace" schemaLocation="xsd/some_namespace.xsd"/>
> And then, in my aar file, I have the files:
> META-INF/xsd/some_namespace.xsd
> META-INF/some_bad_other_xsd/some_namespace.xsd
> The locator seems to try and load both files.  At the very least, the if condition is met, and later down the line, an XMLSchemaException is thrown as follows:
> Error: org.apache.axis2.deployment.DeploymentException: java.lang.RuntimeException: org.apache.ws.commons.schema.XmlSchemaException: No namespace found in given base simple content type
> If you remove the excess xsd file, the problem goes away.  So...I think the if statement here needs to be fixed to not include directories that happen to end with the import location.
> Marking as minor since I can change my directory strutcure, but would be major for someone who was unable to change the stucture of their files.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org