You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by "Johan Andersson (JIRA)" <ji...@apache.org> on 2006/03/08 20:04:38 UTC
[jira] Created: (AXIS2-484) Relative SchemaLocations for Xml Schema
Imports in WSDL
Relative SchemaLocations for Xml Schema Imports in WSDL
-------------------------------------------------------
Key: AXIS2-484
URL: http://issues.apache.org/jira/browse/AXIS2-484
Project: Apache Axis 2.0 (Axis2)
Type: Bug
Components: wsdl
Versions: 0.94
Environment: WinXP, Tomcat 4, 5, Websphere 6
Reporter: Johan Andersson
If an xml schema import (xsd:import) is added in the WSDL, Axis2 will go looking for that import in locations the developer has no control over.
It seems that Axis2 parses the WSDL into an object structure server side when the service is first loaded.
If a relative schema import is in the WSDL the parser (WSDL4J) will try to load the import off the filesystem relative to where the jvm (application server) started.
Then this fails the WSDL will not be available for download/consumption from the Axis2 server.
It seems (not sure) a possible solution could be to set a context root for WSDL4J to work with.
Preferably this would be the logical "services" context in the webapp so that the relative path would work for both WSDL4J parsing the WSDL serverside and for a webservice consumer downloading the WSDL and imports.
--
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
[jira] Resolved: (AXIS2-484) Relative SchemaLocations for Xml
Schema Imports in WSDL
Posted by "Ajith Harshana Ranabahu (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/AXIS2-484?page=all ]
Ajith Harshana Ranabahu resolved AXIS2-484:
-------------------------------------------
Resolution: Fixed
Verified to work with the WSDL in Axis2-557
The following work flow was successful
* Generate server side code with the given WSDL
* compile and build the aar with ant jar.server target
* host that aar in Axis2
* go to service?wsdl link and give that URL as the URL for the codegen
* generate client side code from the WSDL hosted in the service
* build the client jar by ant jar.client
> Relative SchemaLocations for Xml Schema Imports in WSDL
> -------------------------------------------------------
>
> Key: AXIS2-484
> URL: http://issues.apache.org/jira/browse/AXIS2-484
> Project: Apache Axis 2.0 (Axis2)
> Type: Bug
> Components: wsdl
> Versions: 0.94
> Environment: WinXP, Tomcat 4, 5, Websphere 6
> Reporter: Johan Andersson
>
> If an xml schema import (xsd:import) is added in the WSDL, Axis2 will go looking for that import in locations the developer has no control over.
> It seems that Axis2 parses the WSDL into an object structure server side when the service is first loaded.
> If a relative schema import is in the WSDL the parser (WSDL4J) will try to load the import off the filesystem relative to where the jvm (application server) started.
> Then this fails the WSDL will not be available for download/consumption from the Axis2 server.
> It seems (not sure) a possible solution could be to set a context root for WSDL4J to work with.
> Preferably this would be the logical "services" context in the webapp so that the relative path would work for both WSDL4J parsing the WSDL serverside and for a webservice consumer downloading the WSDL and imports.
--
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
[jira] Commented: (AXIS2-484) Relative SchemaLocations for Xml
Schema Imports in WSDL
Posted by "Johan Andersson (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/AXIS2-484?page=comments#action_12372980 ]
Johan Andersson commented on AXIS2-484:
---------------------------------------
The problem is not the need to include the referenced schemas (in my case they are already on the server), it's getting WSDL4J to actually locate them in the file system.
Consider this example:
Axis2 is deployed in Tomcat in the c:\tomcat\webapps\axis2 folder.
Tomcat is started from the command line using a startup.bat script located in c:\tomcat\bin
A service specifying a schema import with the schemaLocation attribute set to "../schemas/schema_to_include.xsd" is deployed.
Axis2/WSDL4J (not sure which) will now try to load the included schema off the filesystem relative to the path where the JVM started.
So schemaLocation "../schemas/schema_to_include.xsd" is resolved to c:\tomcat\bin\../schemas/my_included_schema.xsd and the WSDL cannot be loaded due to not being able to resolve the import (I have no interest in putting schema files in the tomcat installation directory).
In Websphere this gets even more ugly.
I suggest to either load included schemas through http so a wsdl located at "http://myhost/axis2/services/MyService?wsdl" including a schema at relative location "../schemas/schema_to_include.xsd" would go looking for the schema at "http://myhost/axis2/schemas/schema_to_include.xsd".
Or if a similar behaviour could be achieved when loading schemas from the filesystem through specifying a root from which relative import will be resolved, preferably the WEB-INF folder.
Hope this clear things up.
If not I can try to dig through the code and come up with a fix
> Relative SchemaLocations for Xml Schema Imports in WSDL
> -------------------------------------------------------
>
> Key: AXIS2-484
> URL: http://issues.apache.org/jira/browse/AXIS2-484
> Project: Apache Axis 2.0 (Axis2)
> Type: Bug
> Components: wsdl
> Versions: 0.94
> Environment: WinXP, Tomcat 4, 5, Websphere 6
> Reporter: Johan Andersson
>
> If an xml schema import (xsd:import) is added in the WSDL, Axis2 will go looking for that import in locations the developer has no control over.
> It seems that Axis2 parses the WSDL into an object structure server side when the service is first loaded.
> If a relative schema import is in the WSDL the parser (WSDL4J) will try to load the import off the filesystem relative to where the jvm (application server) started.
> Then this fails the WSDL will not be available for download/consumption from the Axis2 server.
> It seems (not sure) a possible solution could be to set a context root for WSDL4J to work with.
> Preferably this would be the logical "services" context in the webapp so that the relative path would work for both WSDL4J parsing the WSDL serverside and for a webservice consumer downloading the WSDL and imports.
--
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
[jira] Commented: (AXIS2-484) Relative SchemaLocations for Xml
Schema Imports in WSDL
Posted by "Davanum Srinivas (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/AXIS2-484?page=comments#action_12375932 ]
Davanum Srinivas commented on AXIS2-484:
----------------------------------------
When u fix this bug, please use the test case with nested imports AXIS2-557 works.
Thanks,
dims
> Relative SchemaLocations for Xml Schema Imports in WSDL
> -------------------------------------------------------
>
> Key: AXIS2-484
> URL: http://issues.apache.org/jira/browse/AXIS2-484
> Project: Apache Axis 2.0 (Axis2)
> Type: Bug
> Components: wsdl
> Versions: 0.94
> Environment: WinXP, Tomcat 4, 5, Websphere 6
> Reporter: Johan Andersson
>
> If an xml schema import (xsd:import) is added in the WSDL, Axis2 will go looking for that import in locations the developer has no control over.
> It seems that Axis2 parses the WSDL into an object structure server side when the service is first loaded.
> If a relative schema import is in the WSDL the parser (WSDL4J) will try to load the import off the filesystem relative to where the jvm (application server) started.
> Then this fails the WSDL will not be available for download/consumption from the Axis2 server.
> It seems (not sure) a possible solution could be to set a context root for WSDL4J to work with.
> Preferably this would be the logical "services" context in the webapp so that the relative path would work for both WSDL4J parsing the WSDL serverside and for a webservice consumer downloading the WSDL and imports.
--
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
[jira] Commented: (AXIS2-484) Relative SchemaLocations for Xml
Schema Imports in WSDL
Posted by "Davanum Srinivas (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/AXIS2-484?page=comments#action_12372500 ]
Davanum Srinivas commented on AXIS2-484:
----------------------------------------
Please try the experimental feature in 0.95:
http://marc.theaimsgroup.com/?l=axis-dev&m=114249501112589&w=2
> Relative SchemaLocations for Xml Schema Imports in WSDL
> -------------------------------------------------------
>
> Key: AXIS2-484
> URL: http://issues.apache.org/jira/browse/AXIS2-484
> Project: Apache Axis 2.0 (Axis2)
> Type: Bug
> Components: wsdl
> Versions: 0.94
> Environment: WinXP, Tomcat 4, 5, Websphere 6
> Reporter: Johan Andersson
>
> If an xml schema import (xsd:import) is added in the WSDL, Axis2 will go looking for that import in locations the developer has no control over.
> It seems that Axis2 parses the WSDL into an object structure server side when the service is first loaded.
> If a relative schema import is in the WSDL the parser (WSDL4J) will try to load the import off the filesystem relative to where the jvm (application server) started.
> Then this fails the WSDL will not be available for download/consumption from the Axis2 server.
> It seems (not sure) a possible solution could be to set a context root for WSDL4J to work with.
> Preferably this would be the logical "services" context in the webapp so that the relative path would work for both WSDL4J parsing the WSDL serverside and for a webservice consumer downloading the WSDL and imports.
--
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
[jira] Commented: (AXIS2-484) Relative SchemaLocations for Xml
Schema Imports in WSDL
Posted by "Jens Schumann (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/AXIS2-484?page=comments#action_12373716 ]
Jens Schumann commented on AXIS2-484:
-------------------------------------
Hi Johan,
using absolute instead of relative urls does work for me (http://myhost/axis2/foo/bar"). However this is not the way to go, because you need to know your public endpoint url at build time. While this workaround ket me going forward one can hardly assume that the given absolute endpoint url will be the same for public access and the deployed archive.
Dims:
It seems the overall issue of imports and includes in WSDL/schemas is not solved by using http. Everything works as expected if you disable load-on-startup for your AxisServlet. If you enable it, Axis deployment will fail since it can't access its own web archive yet (SRV.9.12 Web Application Deployment ... servlet spec). Below my stack trace using load-on-startup on tomcat 5.5.
Retrieving schema at 'http://localhost:8080/foo/xsd/bar.xsd'.
WSDLException (at /wsdl:definitions/wsdl:types/xs:schema): faultCode=OTHER_ERROR: An error occurred trying to resolve schema referenced at 'http://localhost:8080/foo/xsd/bar.xsd'.: This file was not found: http://localhost:8080/foo/xsd/bar.xsd: java.io.FileNotFoundException: This file was not found: http://localhost:8080/foo/xsd/bar.xsd
at com.ibm.wsdl.util.StringUtils.getContentAsInputStream(Unknown Source)
at com.ibm.wsdl.xml.WSDLReaderImpl.parseSchema(Unknown Source)
at com.ibm.wsdl.xml.WSDLReaderImpl.parseSchema(Unknown Source)
at com.ibm.wsdl.xml.WSDLReaderImpl.parseTypes(Unknown Source)
at com.ibm.wsdl.xml.WSDLReaderImpl.parseDefinitions(Unknown Source)
at com.ibm.wsdl.xml.WSDLReaderImpl.readWSDL(Unknown Source)
at com.ibm.wsdl.xml.WSDLReaderImpl.readWSDL(Unknown Source)
at com.ibm.wsdl.xml.WSDLReaderImpl.readWSDL(Unknown Source)
at org.apache.axis2.deployment.AxisServiceBuilder.getAxisService(AxisServiceBuilder.java:136)
at org.apache.axis2.deployment.repository.util.ArchiveReader.processWSDLFile(ArchiveReader.java:187)
at org.apache.axis2.deployment.repository.util.ArchiveReader.processWSDLs(ArchiveReader.java:253)
at org.apache.axis2.deployment.DeploymentEngine.doDeploy(DeploymentEngine.java:423)
at org.apache.axis2.deployment.repository.util.WSInfoList.update(WSInfoList.java:195)
at org.apache.axis2.deployment.RepositoryListener.update(RepositoryListener.java:195)
at org.apache.axis2.deployment.RepositoryListener.checkServices(RepositoryListener.java:145)
at org.apache.axis2.deployment.DeploymentEngine.load(DeploymentEngine.java:571)
at org.apache.axis2.deployment.FileSystemConfigurator.getAxisConfiguration(FileSystemConfigurator.java:59)
at org.apache.axis2.context.ConfigurationContextFactory.createConfigurationContext(ConfigurationContextFactory.java:33)
at org.apache.axis2.context.ConfigurationContextFactory.createConfigurationContextFromFileSystem(ConfigurationContextFactory.java:82)
at org.apache.axis2.transport.http.AxisServlet.initConfigContext(AxisServlet.java:237)
at org.apache.axis2.transport.http.AxisServlet.init(AxisServlet.java:204)
at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1105)
at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:932)
at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:3917)
at org.apache.catalina.core.StandardContext.start(StandardContext.java:4197)
at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:759)
at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:739)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:524)
at org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:809)
at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:497)
at org.apache.catalina.startup.HostConfig.check(HostConfig.java:1189)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.apache.commons.modeler.BaseModelMBean.invoke(BaseModelMBean.java:503)
at com.sun.jmx.mbeanserver.DynamicMetaDataImpl.invoke(DynamicMetaDataImpl.java:213)
at com.sun.jmx.mbeanserver.MetaDataImpl.invoke(MetaDataImpl.java:220)
at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:815)
at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:784)
at org.apache.catalina.manager.ManagerServlet.check(ManagerServlet.java:1377)
at org.apache.catalina.manager.ManagerServlet.deploy(ManagerServlet.java:636)
at org.apache.catalina.manager.ManagerServlet.doPut(ManagerServlet.java:423)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:712)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:524)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664)
at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)
at java.lang.Thread.run(Thread.java:613)
at com.ibm.wsdl.xml.WSDLReaderImpl.parseSchema(Unknown Source)
at com.ibm.wsdl.xml.WSDLReaderImpl.parseSchema(Unknown Source)
at com.ibm.wsdl.xml.WSDLReaderImpl.parseTypes(Unknown Source)
at com.ibm.wsdl.xml.WSDLReaderImpl.parseDefinitions(Unknown Source)
at com.ibm.wsdl.xml.WSDLReaderImpl.readWSDL(Unknown Source)
at com.ibm.wsdl.xml.WSDLReaderImpl.readWSDL(Unknown Source)
at com.ibm.wsdl.xml.WSDLReaderImpl.readWSDL(Unknown Source)
at org.apache.axis2.deployment.AxisServiceBuilder.getAxisService(AxisServiceBuilder.java:136)
at org.apache.axis2.deployment.repository.util.ArchiveReader.processWSDLFile(ArchiveReader.java:187)
at org.apache.axis2.deployment.repository.util.ArchiveReader.processWSDLs(ArchiveReader.java:253)
at org.apache.axis2.deployment.DeploymentEngine.doDeploy(DeploymentEngine.java:423)
at org.apache.axis2.deployment.repository.util.WSInfoList.update(WSInfoList.java:195)
at org.apache.axis2.deployment.RepositoryListener.update(RepositoryListener.java:195)
at org.apache.axis2.deployment.RepositoryListener.checkServices(RepositoryListener.java:145)
at org.apache.axis2.deployment.DeploymentEngine.load(DeploymentEngine.java:571)
at org.apache.axis2.deployment.FileSystemConfigurator.getAxisConfiguration(FileSystemConfigurator.java:59)
at org.apache.axis2.context.ConfigurationContextFactory.createConfigurationContext(ConfigurationContextFactory.java:33)
at org.apache.axis2.context.ConfigurationContextFactory.createConfigurationContextFromFileSystem(ConfigurationContextFactory.java:82)
at org.apache.axis2.transport.http.AxisServlet.initConfigContext(AxisServlet.java:237)
at org.apache.axis2.transport.http.AxisServlet.init(AxisServlet.java:204)
at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1105)
at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:932)
at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:3917)
at org.apache.catalina.core.StandardContext.start(StandardContext.java:4197)
at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:759)
at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:739)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:524)
at org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:809)
at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:497)
at org.apache.catalina.startup.HostConfig.check(HostConfig.java:1189)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.apache.commons.modeler.BaseModelMBean.invoke(BaseModelMBean.java:503)
at com.sun.jmx.mbeanserver.DynamicMetaDataImpl.invoke(DynamicMetaDataImpl.java:213)
at com.sun.jmx.mbeanserver.MetaDataImpl.invoke(MetaDataImpl.java:220)
at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:815)
at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:784)
at org.apache.catalina.manager.ManagerServlet.check(ManagerServlet.java:1377)
at org.apache.catalina.manager.ManagerServlet.deploy(ManagerServlet.java:636)
at org.apache.catalina.manager.ManagerServlet.doPut(ManagerServlet.java:423)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:712)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:524)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664)
at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)
at java.lang.Thread.run(Thread.java:613)
> Relative SchemaLocations for Xml Schema Imports in WSDL
> -------------------------------------------------------
>
> Key: AXIS2-484
> URL: http://issues.apache.org/jira/browse/AXIS2-484
> Project: Apache Axis 2.0 (Axis2)
> Type: Bug
> Components: wsdl
> Versions: 0.94
> Environment: WinXP, Tomcat 4, 5, Websphere 6
> Reporter: Johan Andersson
>
> If an xml schema import (xsd:import) is added in the WSDL, Axis2 will go looking for that import in locations the developer has no control over.
> It seems that Axis2 parses the WSDL into an object structure server side when the service is first loaded.
> If a relative schema import is in the WSDL the parser (WSDL4J) will try to load the import off the filesystem relative to where the jvm (application server) started.
> Then this fails the WSDL will not be available for download/consumption from the Axis2 server.
> It seems (not sure) a possible solution could be to set a context root for WSDL4J to work with.
> Preferably this would be the logical "services" context in the webapp so that the relative path would work for both WSDL4J parsing the WSDL serverside and for a webservice consumer downloading the WSDL and imports.
--
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