axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mauro Molinari (JIRA)" <>
Subject [jira] Commented: (AXIS2-3354) Allow for sharing XSD schemas between services
Date Wed, 28 Nov 2007 14:13:43 GMT


Mauro Molinari commented on AXIS2-3354:

I just debugged the servlet to identify the problem.

When I ask for:
this is the stack trace (released Axis 1.3 codebase against Tomcat 5.5.23):
- AxisServlet.doGet(HttpServletRequest, HttpServletResponse) line: 229	
- ListingAgent.processListService(HttpServletRequest, HttpServletResponse) line: 313	
- URLClassLoader(ClassLoader).getResourceAsStream(String) line: 1159	
here, the requested resource name is: META-INF/../../AccessService_Schema.xsd
This seems fine, but this classloader delegates to its parent, which also delegates to its
parent... and so on, until we get to:
- WebappClassLoader.getResource(String) line: 1068	
here a call to findResource(name) is executed, where name is still: META-INF/../../AccessService_Schema.xsd
This delegates to findResourceInternal(name, name), where name is still: META-INF/../../AccessService_Schema.xsd
- WebappClassLoader.findResourceInternal(String, String) line: 1917	
here, a "fullPath" is composed, which evaluates to: /WEB-INF/classes/META-INF/../../AccessService_Schema.xsd
and is composed by the concatenation of the only "repository" in "repositories" array and
the name of the requested resource.

In other words, it seems that Axis2 asks to the classloader for the file to return, passing
it a path which is relative to the service folder. But the classloader in use delegates to
its parent and, eventually, the webapp classloader is used, which is based on WEB-INF/classes
folder, not on the service folder. So the research fails.

> Allow for sharing XSD schemas between services
> ----------------------------------------------
>                 Key: AXIS2-3354
>                 URL:
>             Project: Axis 2.0 (Axis2)
>          Issue Type: Improvement
>    Affects Versions: 1.3
>            Reporter: Mauro Molinari
>            Priority: Critical
> Suppose I have the following structure:
> The WSDLs for MyService1 and MyService2 are in the following folders, respectively:
> contextpath/WEB-INF/services/MyService1/META-INF/
> contextpath/WEB-INF/services/MyService2/META-INF/
> I want them to share Common.xsd: as of now, it seems that there's no way to get this
to work.
> If I put it here:
> contextpath/WEB-INF/services/
> and the xsd:import schemaLocation in the WSDLs points to "../../Common.xsd", Axis2 can
find the XSD and processes the services correctly, but when it substitutes the link to it
in the WSDLs, it generates the following links:
> MyService1?xsd=../../Common.xsd (in MyService1 WSDL)
> MyService2?xsd=../../Common.xsd (in MyService2 WSDL)
> The problem is that from an HTTP client point of view, this translates to path contextpath/Common.xsd:
in fact, if you try to write the link:
> http://server:8080/contextpath/services/MyService1?xsd=../../Common.xsd
> a "file not found" error is given.
> Another clue is that if I try to generate a client pointing to
> http://server:8080/contextpath/services/MyService1?wsdl, WSDL2Java says that it cannot
retrieve the schema.
> By manually typing:
> http://server:8080/contextpath/services/MyService1?xsd=../Common.xsd
> I see that the schema can actually be found; but if I replace the xsd:import in the original
WSDL so that the schemaLocation points to "../Common.xsd", then Axis2 can't find it anymore,
because it searches for it in contextpath/WEB-INF/services/MyService1/ and the generation
of the WSDL fails.
> So, my request is this: add a supported way to share schemas (and maybe WSDLs portions)
between services.
> Maybe the system should allow a default common repository where shared schemas and WSDLs
can be placed? Or should the way in which Axis2 rewrites the schemaLocation link in the WSDL
when imported resources are mapped to file outside the current folder simply fixed?

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:
For additional commands, e-mail:

View raw message