Jacob Danner wrote:
What do you mean by "to change sth on the namespaces "?
When i parse ( with WSDL4J ) a WSDL document from a specified URL i copy the
namespaces from WSDL <definitions> because some of the prefixes that are
used in the xsds encapsulated in <types> are not resolved...So, i get the
<definitions> namespaces that are absent from <schema> contained in <types>
and put them to the schemas. (i hope you understand)
Okay so a couple of things...
-You are parsing String representations of schemas which is why you
are having trouble resolving references. If you parsed the files, this
probably wouldn't be an issue.
I can't parse a file.Everything is parsing runtime and online from a
specified URL.
-You are having these troubles because there is no way for your
initial wsdl/xsd compile to resolve the schemaLocation field since
there is no path or source information associated your initial xsd.
-Why are you specifying:
opts = opts.setCompileDownloadUrls(); ?
None of the schemaLocations have a point of reference in your
wsdl/xsd? Since you aren't compiling from the filesystem or URL
I have this xmloption because there are xsds that have imports and on my
tests without this option it couldn't compile the schemas.
So, when there is an import it downloads and "put" it's components on my
schema.
Additionally, you mention...
The problem is that inside the xsd, the imports have not well formed url
as
<import namespace="x" SchemaLocation="./../blah/blah.xsd">
These are valid imports with valid URLs in the schemaLocation field.
The schemaLocation values appear to resolve properly on the file
system and the URL. XMLBeans isn't doing anything wrong here and is
actually processing the schema correctly
So, in other words take the following example (excuse the poor
incorrect xml grammar, this is for example only):
String a_xsd = "<schema targetNamespace="DnaCopy"
elementFormDefault="qualified" attributeFormDefault="unqualified">
<import namespace="b" schemaLocation="../a/b/c.xsd"/>
<complexType name="baz">
// model group, etc...
<element type="b:foo" />
</schema>";
String c_xsd =<schema targetNamespace="DnaCopy"
elementFormDefault="qualified" attributeFormDefault="unqualified">
<element name="foo" type="xs:string" />
</schema>";
// PLEASE ANSWER
// a) looking at a_xsd, how/where does ../a/b/c.xsd resolve to?
// b) what is the absolute path of the schemaLocation in a_xsd
// so you are trying
ArrayList<XMLObject> al;
al.add(XMLObject.Factory.parse(a_xsd));
al.add(XMLObject.Factory.parse(c_xsd));
// correct?
// do you understand why these schemaLocations aren't resolving?
This part of code is correct.
Why?
Because every schema doesn't have a specified source name (a base URI or
something )?
Have you tried setting the source names? Did that solve your problem?
I tried to setSourceName on every Schema with the documentBaseURI and there
was a change on the output error:
org.apache.xmlbeans.XmlException:
http://linuxcomp64.wustl.edu:9880/wsrf/share/schema/wsrf/properties/WS-ResourceProperties.wsdl:0:
error: sch-props-correct.2: Duplicate global type:
resourceunknownfaultt...@http://docs.oasis-open.org/wsrf/2004/06/wsrf-WS-ResourceProperties-1.2-draft-01.xsd
(Original global type found in file:
URI_SHA_1_D21B615216D90E442798637B7BBCAEE503228906/WS-ResourceProperties.wsdl)
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)
-jacobd
On Tue, May 12, 2009 at 2:01 PM, Michael Xenakis <[email protected]>
wrote:
Actually, i am going to tell you exactly what i do...
compilationObject is ArrayList<XmlObject> and contains all my schemas,
but
before adding all the schemas to the ArrayList i take the string
representation of every xmlobject (schema) to change sth on the
namespaces
section and again parse them to take the xmlobject representation of the
schema. (I hope it's clear )
now, the code....
XmlOptions opts = new XmlOptions();
opts = opts.setCompileDownloadUrls(); /*opts =
opts.setLoadUseDefaultResolver(); */
sts = XmlBeans.compileXsd(compilationObjects.toArray(new
XmlObject[compilationObjects.size()]),XmlBeans.getBuiltinTypeSystem(),opts);
as i stated before the wsdl i gave on the first post of this thread had
multiple import layers (like baboushka dolls) and one of those layers
(wsdl
documents actually) had the <types> section, i took the xsds as
xmlobjects
from the <types> element casted to string to manipulate a little bit the
namespaces of each xsd and then back to xmlobject with parse method.
With this as statements, i try to compile all the schemas together to get
a
SchemaTypeSystem with the components of all schemas retrieved from the
wsdl(s).
The problem is that inside the xsd, the imports have not well formed url
as
<import namespace="x" SchemaLocation="./../blah/blah.xsd">
i can't parse the "./../X/Y/Z/SchemaExample.xsd" as new File because it
is
in the xsd and inside the imports....i have to find a way to change the
form
of the imports (or make xmlbeans understand thoroughly the above import
form) before (or maybe at compile time)
If u want more infos/code from my project to understand the problem i can
cp
more code, no prob!
Thanks
Michael
Jacob Danner wrote:
Okay, taking your example from above
<import namespace="http://blahblahzdoing.com";
SchemaLocation="./../X/Y/Z/SchemaExample.xsd"/>
You are probably doing something like this to load SchemaExample.xsd
XMLObject xo = XMLObject.Factory.parse(<StringOfSchemaExample.xsd>);
you might be able to do something like
XMLObject xo = XMLObject.Factory.parse(new
File("./../X/Y/Z/SchemaExample.xsd"));
and/or
xo.getDocumentProperties().setSourceName("./../X/Y/Z/SchemaExample.xsd");
HTH,
-jacobd
On Tue, May 12, 2009 at 1:35 PM, Michael Xenakis <[email protected]>
wrote:
Ok, but the schemaLocations are attributes of the import elements...how
could i manipulate every import and "correct" it , in order to compile?
Every import could have different namespace and schemaLocation
fields....
With setSourceName you just set the url of the whole schema...
Could you please give a little bit more infos?
Thanks again,
Michael
Jacob Danner wrote:
If been a while since I've tinkered with these APIs, but I would try
setting the
sourceName value to the value of the schemaLocation
ie, setSourceName("../foo.xsd");
Let the list know how this turns out.
-jacobd
On Tue, May 12, 2009 at 10:34 AM, Jacob Danner
<[email protected]>
wrote:
You can't skip an error like this. It's valid. If I'm understanding
your case properly, the error message is telling you the imported
schemas cannot be found.
I would start by looking at how you are creating your XMLObject
array.
What is the value of
XMLObject.getDocumentProperties().getSourceName(). Is it null?
I think there might be a couple of examples of this in the xmlbeans
test compile directory.
-jacobd
On Tue, May 12, 2009 at 8:44 AM, Michael Xenakis
<[email protected]>
wrote:
Hey Jacob,
Yes, i'm doing the compilation programmatically with compileXSD
method...and
that was a "compileXSD" error apparently.
I've checked the xmloptions to find a way to skip this error but
nothing.
Jacob Danner wrote:
Hi Michael,
I did just convert the wsdl imports by hand because it was the
quickest and easiest way for me to.
There shouldn't be a problem using the relative URLs so long as the
schemaLocation values are all correct (point to proper files) once
the
scomp is run.
Are you doing your compilation programmatically or via the scomp
tool?
If you are doing it programmatically this might be one of the
reasons
you are having difficulty resolving the paths during compile time.
-jacobd
On Tue, May 12, 2009 at 8:27 AM, Michael Xenakis
<[email protected]>
wrote:
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]
---------------------------------------------------------------------
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]
---------------------------------------------------------------------
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]
