[ 
http://issues.apache.org/jira/browse/AXIS2-1885?page=comments#action_12459652 ] 
            
Amila Chinthaka Suriarachchi commented on AXIS2-1885:
-----------------------------------------------------

As I saw the problem is with the entity resolver. Entity Resolver has a method 
called 
 public InputSource resolveEntity(String publicId, String systemId) throws 
SAXException, IOException { 
which has two parameters. whenever xmlbeans wants to get an input source for an 
schma it calls this method with the publicId and the systemId. when calling it 
always appends an  project:local prefix to the internally imported schemas. so 
when call for the message.xsd it uses two systemIds.

this is your xsd in wsdl
<xs:schema 
targetNamespace="http://service.foobar.com/provider/testprovider/test/"; 
xmlns="http://service.foobar.com/provider/testprovider/test/"; 
xmlns:xs="http://www.w3.org/2001/XMLSchema"; 
xmlns:msg="http://service.foobar.com/entity/message/"; 
xmlns:runtest="http://service.foobar.com/provider/testprovider/test/runtest/";>
                        <xs:import 
namespace="http://service.foobar.com/entity/message/"; 
schemaLocation="../../../entity/message/message.xsd"/>
                        <xs:import 
namespace="http://service.foobar.com/provider/testprovider/test/runtest/"; 
schemaLocation="runTest.xsd"/>
                </xs:schema>

but anyway, if you remove the message.xsd from here every thing works fine. So 
to avoid this problem we can refrain from importing the internally refered 
schemas in the wsdl.

> WSDL2Java with XMLBeans binding codegen fails with "Duplicate global type" 
> when schema is imported from WSDL file and another schema file.
> ------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: AXIS2-1885
>                 URL: http://issues.apache.org/jira/browse/AXIS2-1885
>             Project: Apache Axis 2.0 (Axis2)
>          Issue Type: Bug
>          Components: codegen
>    Affects Versions: 1.1, nightly
>         Environment: Windows XP, JDK 1.4.  Tested on nightly snapshot of 
> December 18, 2006.
>            Reporter: Michael Krumpus
>            Priority: Critical
>         Attachments: axis2bug.zip
>
>
> WSDL2Java fails with the following error when a schema is imported from a 
> WSDL file and also imported from another schema:
> ...
> Caused by: org.apache.xmlbeans.XmlException: 
> project://local/../../../entity/message/message.xsd:6:1: error: 
> sch-props-correct.2: Duplicate global type: [EMAIL 
> PROTECTED]://service.foobar.com/entity/message/ (Original global type found 
> in file: ../../../entity/message/message.xsd)
>       at 
> org.apache.xmlbeans.impl.schema.SchemaTypeSystemCompiler.compile(SchemaTypeSystemCompiler.java:225)
>       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:324)
>       at org.apache.xmlbeans.XmlBeans.compileXmlBeans(XmlBeans.java:667)
>       at 
> org.apache.axis2.xmlbeans.CodeGenerationUtility.processSchemas(CodeGenerationUtility.java:160)
> The problem here seems to be that when message.xsd is imported in the WSDL 
> file *and* imported in another schema that is also imported in the WSDL file, 
> the code generation process does not realize that they are the same schema, 
> thus leading it to believe that the type MessageContext_Type is a duplicate 
> global type when it is not.  I will attach an example that demonstrates the 
> problem clearly.
> This problem does NOT occur when XMLBeans 'scomp' is used as a standalone 
> tool.
> Of particular interest is the behavior of the method baseURLForDoc() in 
> org.apache.xmlbeans.impl.schema.StscImporter.  When running scomp as a 
> standalone utility, fully qualified absolute paths are passed into this 
> method, but when using WSDL2Java, relative paths are passed in.

-- 
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to