Hi Jacob and thank you for your answer,
The think is that i can't pull out the WSDL4j from my code because my
work is a part of a bigger project that uses WSDL4j.
Could you tell me please the way to convert the relative URLs on the
imports to absolute URLs?I hope u did that by xmloptions or sth and not
"by hand"...
Is there any way to convert automatically all the relative URLs to
absolute in runtime(compileXSD time)?
Thanks in Advance for your answers,
Michael
Jacob Danner wrote:
Hmm, I think you are making it too hard on yourself with all of the
WSDL4J to pull out the types element. XMLBeans' scomp tool can be run
on wsdls. Have/can you give this a try?
I ran the following from the command line without much of a problem.
#> scomp
http://linuxcomp64.wustl.edu:9880/wsrf/share/schema/DnaCopy/DnaCopy.wsdl
-dl
and got the following output
http://linuxcomp64.wustl.edu:9880/wsrf/share/schema/DnaCopy/edu.wustl.icr.asrv1.
dnacopy.xsd:34:25: warning: p-props-correct.2.2: maxOccurs must be
greater than or equal to 1.
Time to build schema type system: 5.344 seconds
Time to generate code: 1.453 seconds
Time to compile code: 7.844 seconds
Compiled types to: xmltypes.jar
relative URLs (../some.xsd) can be tricky, and I'd suggest making them
absolute where ever possible. I don't see any issues with the XSDs
referenced, but didn't verify the path was correct for all of them.
I went ahead and made the paths absolute and verified I could compile
the wsdl with scomp locally. Can you try the same.
Thanks,
-jacobd
On Mon, May 11, 2009 at 11:55 PM, Michael Xenakis <[email protected]> wrote:
Hi Jacob and thanks for the reply,
Let's start from scratch. I have WSDL files with WSDL imports. I use WSDL4j
to parse the wsdl files...so, when i get the <types> section of the WSDL
document i hold on a Xmlobject array all the XSDs from the <types> element.
After doing this procedure to store the xsds i compile the xsds (all
together), and the problem rises on this part. To specify a little bit the
problem just look on this wsdl document as an example,
http://linuxcomp64.wustl.edu:9880/wsrf/share/schema/DnaCopy/DnaCopy.wsdl
and check how the imports are...on the first one i get "error: URL
"../wsrf/faults/WS-BaseFaults.xsd" is not well formed ".
some import examples that their URLs are not well formed:
<import
namespace="http://docs.oasis-open.org/wsrf/2004/06/wsrf-WS-BaseFaults-1.2-draft-01.xsd";
schemaLocation="../wsrf/faults/WS-BaseFaults.xsd"/>
<import namespace="gme://caGrid.proposed/1.0/graph.transfer"
schemaLocation="./graphtransfer.xsd"/>
<import namespace="gme://caGrid.caBIG/1.0/gov.nih.nci.cagrid.metadata"
schemaLocation="./xsd/cagrid/types/caGridMetadata.xsd"/>
<import namespace="http://transfer.cagrid.org/Transfer";
schemaLocation="./caGrid_Transfer.xsd"/>
<import namespace="gme://caB2B.icr/1.0/edu.wustl.icr.asrv1.cnat.ext"
schemaLocation="./edu.wustl.icr.asrv1.cnat.ext.xsd"/>
<import namespace="gme://caB2B.icr/1.0/edu.wustl.icr.asrv1.dnacopy"
schemaLocation="./edu.wustl.icr.asrv1.dnacopy.xsd"/>
<import namespace="gme://caB2B.icr/1.0/edu.wustl.icr.asrv1.common"
schemaLocation="./edu.wustl.icr.asrv1.common.xsd"/>
<import
namespace="gme://caGrid.caBIG/1.0/gov.nih.nci.cagrid.metadata.security"
schemaLocation="./xsd/cagrid/types/security/security.xsd"/>
The problem (I suppose) is the "call" on the import due to the URI format
with the dots etc... and the xmlbeans doesn't understand the "./../" so
thats why i was studying the entityresolver.
I hope u can fully understand what's the problem,
thanks in advance,
Michael
Jacob Danner wrote:
Maybe I'm missing something in your scenario, but whenever I've seen
that error it has meant something is wrong with something in my XML.
With your error message, I'd suggest looking at
../X/Y/SchemaExample.xsd
as a starting point.
Is this file well-formed?
What makes you think its an issue that requires entity resolvers?
-jacobd
On Mon, May 11, 2009 at 3:15 PM, Michael Xenakis <[email protected]>
wrote:
Hi everybody,
i get the error on the Subject with the above details:
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:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:616)
at org.apache.xmlbeans.XmlBeans.compileXmlBeans(XmlBeans.java:667)
at org.apache.xmlbeans.XmlBeans.compileXsd(XmlBeans.java:553)
My problem is that i have a lot of XSDs that have imports with the above
format:
<import namespace="http://blahblahzdoing.com";
SchemaLocation="./../X/Y/Z/SchemaExample.xsd"/>
is there any way i can solve this problem?I've studied a little bit the
EntityResolver but i don't think that it could help me (and by the way i
can't fully understand the way it works- (stupid :-( ) ). Is there any
XmlOptions (or something ) that can solve my problem? By the way, i've
already used the "setLoadUseDefaultResolver()" before the
XmlBeans.compileXsd(compilationObjects.toArray(ArrayOfSchemas[],XmlBeans.getBuiltinTypeSystem(),Xmloptions)
method... but nothing...
Also, this feature is mandatory for my project and it's urgent , so i
would
be thankful for quick and right answers!
Thanks in Advance,
Mike
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
