What do you mean by "to change sth on the namespaces "?
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. -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 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? Have you tried setting the source names? Did that solve your problem? -jacobd On Tue, May 12, 2009 at 2:01 PM, Michael Xenakis <michael....@gmail.com> 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 <michael....@gmail.com> >> 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 <jacob.dan...@gmail.com> >>>> 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 >>>>> <michael....@gmail.com> >>>>> 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 >>>>>>> <michael....@gmail.com> >>>>>>> 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 >>>>>>>>> <michael....@gmail.com> >>>>>>>>> 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 >>>>>>>>>>> <michael....@gmail.com> >>>>>>>>>>> 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: user-unsubscr...@xmlbeans.apache.org >>>>>>>>>>>> For additional commands, e-mail: user-h...@xmlbeans.apache.org >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> --------------------------------------------------------------------- >>>>>>>>>>> To unsubscribe, e-mail: user-unsubscr...@xmlbeans.apache.org >>>>>>>>>>> For additional commands, e-mail: user-h...@xmlbeans.apache.org >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> --------------------------------------------------------------------- >>>>>>>>>> To unsubscribe, e-mail: user-unsubscr...@xmlbeans.apache.org >>>>>>>>>> For additional commands, e-mail: user-h...@xmlbeans.apache.org >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> --------------------------------------------------------------------- >>>>>>>>> To unsubscribe, e-mail: user-unsubscr...@xmlbeans.apache.org >>>>>>>>> For additional commands, e-mail: user-h...@xmlbeans.apache.org >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> --------------------------------------------------------------------- >>>>>>>> To unsubscribe, e-mail: user-unsubscr...@xmlbeans.apache.org >>>>>>>> For additional commands, e-mail: user-h...@xmlbeans.apache.org >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> --------------------------------------------------------------------- >>>>>>> To unsubscribe, e-mail: user-unsubscr...@xmlbeans.apache.org >>>>>>> For additional commands, e-mail: user-h...@xmlbeans.apache.org >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> To unsubscribe, e-mail: user-unsubscr...@xmlbeans.apache.org >>>>>> For additional commands, e-mail: user-h...@xmlbeans.apache.org >>>>>> >>>>>> >>>>>> >>>>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: user-unsubscr...@xmlbeans.apache.org >>>> For additional commands, e-mail: user-h...@xmlbeans.apache.org >>>> >>>> >>>> >>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: user-unsubscr...@xmlbeans.apache.org >>> For additional commands, e-mail: user-h...@xmlbeans.apache.org >>> >>> >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: user-unsubscr...@xmlbeans.apache.org >> For additional commands, e-mail: user-h...@xmlbeans.apache.org >> >> >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: user-unsubscr...@xmlbeans.apache.org > For additional commands, e-mail: user-h...@xmlbeans.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: user-unsubscr...@xmlbeans.apache.org For additional commands, e-mail: user-h...@xmlbeans.apache.org
