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
