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

Reply via email to