This new error means something the references are now being resolved properly. You'll have to find out why you are getting this new error, but it looks like 2 of your artifacts are compiling/referencing WS-ResourceProperties.wsdl Best of luck, -jacobd
On Wed, May 13, 2009 at 12:31 AM, Michael Xenakis <michael....@gmail.com> wrote: > 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 <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 >> >> >> > > > --------------------------------------------------------------------- > 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