Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [eclipselink-users] MalformedURLException in sdo-compiler

Well this thing refuses to die.  

I noticed that it seems that it resolves relative URIs wrongly.  If I specify
the base location as file:///home/david/src/oasis/os-UBL-2.0/xsd/maindoc,
i.e. at the place where the Invoice document is, it fails complaining that
it can not find ..../maindoc/UBL-Common..., but if I point it at 
.../xsd/common it finds the included files properly.  Very bizaar.  But it 
means progress.

So I then get another problem.

Exception Description: Could not find ID element of type ID on type with uri 
[urn:un:unece:uncefact:data:specification:UnqualifiedDataTypesSchemaModule:2] 
and name [CodeType] .

CodeType does not have a type ID, nor an element ID as far as I can see.  
Any idea why it might be looking for one?

David
 
On Friday 11 July 2008, David McCann wrote:
> setBaseSchemaLocation(System.getProperty("user.dir")); won't work, because
> there is no protocol - you'll need to do the following:
>
> 	setBaseSchemaLocation("File:///" + System.getProperty("user.dir"));
>
> --Dave
>
> ------------------------------------------------------------------------
>
> David Goodenough wrote:
> > The Schemas can be downloaded from:-
> >
> > http://docs.oasis-open.org/ubl/os-UBL-2.0.zip
> >
> > In the xsd directory you will find the UBL-Invoice-2.0.xsd that I was
> > trying to load.
> >
> > I am running on Linux, so I set the base location to:-
> >
> >   setBaseSchemaLocation(System.getProperty("user.dir"));
> >
> > I did also try adding in a "/" on the end just in case.
> >
> > in the CustomClassGenerator just before I call:-
> >
> >   Source source = super.resolveSchema(sourceXSD, namespace,
> > schemaLocation);
> >
> > David
> >
> > On Thursday 10 July 2008, David McCann wrote:
> >> What are you setting as your base location?  Also, you may want to
> >> forward me the schemas you are trying to load.
> >>
> >> --Dave
> >>
> >> David Goodenough wrote:
> >>> Any thoughts on how to get around this problem?
> >>>
> >>> David
> >>>
> >>> On Wednesday 09 July 2008, David Goodenough wrote:
> >>>> Well we get a bit further, I now get:-
> >>>>
> >>>> Local Exception Stack:
> >>>> Exception [EclipseLink-25004] (Eclipse Persistence Services - 1.0
> >>>> (Build 1.0 - 20080707)):
> >>>> org.eclipse.persistence.exceptions.XMLMarshalException Exception
> >>>> Description: An error occurred unmarshalling the document Internal
> >>>> Exception: java.net.UnknownHostException: ..
> >>>>         at
> >>>> org.eclipse.persistence.exceptions.XMLMarshalException.unmarshalExcept
> >>>>io n(X MLMarshalException.java:91) at
> >>>> org.eclipse.persistence.internal.oxm.record.SAXUnmarshaller.unmarshal(
> >>>>SA XUn marshaller.java:550) at
> >>>> org.eclipse.persistence.internal.oxm.record.SAXUnmarshaller.unmarshal(
> >>>>SA XUn marshaller.java:458) at
> >>>> org.eclipse.persistence.oxm.XMLUnmarshaller.unmarshal(XMLUnmarshaller.
> >>>>ja va: 447) at
> >>>> org.eclipse.persistence.sdo.helper.SDOTypesGenerator.getSchema(SDOType
> >>>>sG ene rator.java:2018) at
> >>>> org.eclipse.persistence.sdo.helper.SDOTypesGenerator.getSchema(SDOType
> >>>>sG ene rator.java:2027) at
> >>>> org.eclipse.persistence.sdo.helper.SDOTypesGenerator.getSchema(SDOType
> >>>>sG ene rator.java:1999) at
> >>>> org.eclipse.persistence.sdo.helper.SDOTypesGenerator.define(SDOTypesGe
> >>>>ne rat or.java:108) at
> >>>> org.eclipse.persistence.sdo.helper.SDOClassGenerator.generate(SDOClass
> >>>>Ge ner ator.java:209) at
> >>>> org.eclipse.persistence.sdo.helper.SDOClassGenerator.generate(SDOClass
> >>>>Ge ner ator.java:175) at
> >>>> uk.co.linkchoose.eclipselink.sdoCompiler.CustomClassGenerator.<init>(C
> >>>>us tom ClassGenerator.java:21) at
> >>>> uk.co.linkchoose.eclipselink.sdoCompiler.CustomClassGenerator.main(Cus
> >>>>to mCl assGenerator.java:48) Caused by: java.net.UnknownHostException:
> >>>> .. at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:177) at
> >>>> java.net.Socket.connect(Socket.java:519)
> >>>>         at java.net.Socket.connect(Socket.java:469)
> >>>>         at sun.net.NetworkClient.doConnect(NetworkClient.java:157)
> >>>>         at sun.net.NetworkClient.openServer(NetworkClient.java:118)
> >>>>         at sun.net.ftp.FtpClient.openServer(FtpClient.java:488)
> >>>>         at sun.net.ftp.FtpClient.openServer(FtpClient.java:475)
> >>>>         at
> >>>> sun.net.www.protocol.ftp.FtpURLConnection.connect(FtpURLConnection.jav
> >>>>a: 270 ) at
> >>>> sun.net.www.protocol.ftp.FtpURLConnection.getInputStream(FtpURLConnect
> >>>>io n.j ava:352) at
> >>>> com.sun.org.apache.xerces.internal.impl.XMLEntityManager.setupCurrentE
> >>>>nt ity (XMLEntityManager.java:653) at
> >>>> com.sun.org.apache.xerces.internal.impl.XMLVersionDetector.determineDo
> >>>>cV ers ion(XMLVersionDetector.java:186) at
> >>>> com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XM
> >>>>L1 1Co nfiguration.java:771) at
> >>>> com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XM
> >>>>L1 1Co nfiguration.java:737) at
> >>>> com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.j
> >>>>av a:1 07) at
> >>>> com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(Abs
> >>>>tr act SAXParser.java:1132) at
> >>>> com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.pa
> >>>>rs e(S AXParserImpl.java:533) at
> >>>> org.eclipse.persistence.internal.oxm.record.XMLReader.parse(XMLReader.
> >>>>ja va: 103) at
> >>>> org.eclipse.persistence.internal.oxm.record.SAXUnmarshaller.unmarshal(
> >>>>SA XUn marshaller.java:544) ... 10 more
> >>>>
> >>>> lots of times.
> >>>>
> >>>> David
> >>>>
> >>>> On Wednesday 09 July 2008, David McCann wrote:
> >>>>> Please let me know if my workaround suggestion helped.  I am looking
> >>>>> into your issue regarding our default resolver now, and will update
> >>>>> the bug shortly.
> >>>>>
> >>>>> --dave
> >>>>>
> >>>>> ---------------------------------------------------------------------
> >>>>>-- -
> >>>>>
> >>>>> David Goodenough wrote:
> >>>>>> That is to say how do I do this using the command sdo-compiler.sh?
> >>>>>>
> >>>>>> Also why does the else below (and that in the default one) use new
> >>>>>> URL when surely it should use new URI?
> >>>>>>
> >>>>>> David
> >>>>>>
> >>>>>> On Wednesday 09 July 2008, David Goodenough wrote:
> >>>>>>> How do I use this in the sdo-compiler?
> >>>>>>>
> >>>>>>> David
> >>>>>>>
> >>>>>>> On Wednesday 09 July 2008, David McCann wrote:
> >>>>>>>> Hey David,
> >>>>>>>>
> >>>>>>>> To handle this scenario you will need to implement a
> >>>>>>>> SchemaResolver (org.eclipse.persistence.sdo.helper package) that
> >>>>>>>> can load the doc based on the relative path.  To do this, you can
> >>>>>>>> simply extend the default resolver we provide
> >>>>>>>> (org.eclipse.persistence.sdo.helper.DefaultSchemaResolver) and
> >>>>>>>> override the resolveSchema(Source, String, String) method to
> >>>>>>>> handle this case. Note that the schema resolver is passed in as a
> >>>>>>>> parameter in the define method on the delegator.
> >>>>>>>>
> >>>>>>>> Here's an example of a custom resolver:
> >>>>>>>>
> >>>>>>>>     public class CyclicSchemaResolver extends
> >>>>>>>> DefaultSchemaResolver { public Source resolveSchema(Source
> >>>>>>>> sourceXSD, String namespace, String schemaLocation) {
> >>>>>>>>             if (schemaLocation != null &&
> >>>>>>>> !schemaLocation.equals("")) { return
> >>>>>>>> super.resolveSchema(sourceXSD, namespace, schemaLocation); }
> >>>>>>>>             schemaLocation = namespace.equals("uri") ?
> >>>>>>>> "Cyclic1.xsd"
> >>>>>>>>
> >>>>>>>> : "Cyclic2.xsd";
> >>>>>>>>
> >>>>>>>>             URL schemaUrl = null;
> >>>>>>>>             try {
> >>>>>>>>                 if (getBaseSchemaLocation() != null) {
> >>>>>>>>                     // Attempt to resolve the schema location
> >>>>>>>> against the base location
> >>>>>>>>                     URI baseUri = new
> >>>>>>>> URI(getBaseSchemaLocation()); URI resolvedUri =
> >>>>>>>> baseUri.resolve(schemaLocation); schemaUrl = resolvedUri.toURL();
> >>>>>>>>                 } else {
> >>>>>>>>                     schemaUrl = new URL(schemaLocation);
> >>>>>>>>                 }
> >>>>>>>>             } catch (Exception e) {
> >>>>>>>>                 return null;
> >>>>>>>>             }
> >>>>>>>>             return new StreamSource(schemaUrl.toExternalForm());
> >>>>>>>>         }
> >>>>>>>>     }
> >>>>>>>>
> >>>>>>>> Please let me know if you have any questions.
> >>>>>>>>
> >>>>>>>> --Dave
> >>>>>>>> ------------------------------------------------------------------
> >>>>>>>>-- - -- -
> >>>>>>>>
> >>>>>>>> David Goodenough wrote:
> >>>>>>>>> I am trying to run the sdo-compiler against some of the OASIS xsd
> >>>>>>>>> files but when I try I get a MalformedURLException when resolving
> >>>>>>>>> schemas.
> >>>>>>>>>
> >>>>>>>>> This is using 1.0M11.
> >>>>>>>>>
> >>>>>>>>> The first exception I get is:-
> >>>>>>>>>
> >>>>>>>>> [EL Warning]: 2008.07.09
> >>>>>>>>> 11:41:48.932--Thread(Thread[main,5,main])--An
> >>>>>>>>> java.net.MalformedURLException occurred processing referenced
> >>>>>>>>> schema with uri
> >>>>>>>>> urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateCompo
> >>>>>>>>>ne n ts - 2 with schemaLocation
> >>>>>>>>> ../common/UBL-CommonAggregateComponents-2.0.xsd. [EL Finest]:
> >>>>>>>>> 2008.07.09
> >>>>>>>>> 11:41:48.947--Thread(Thread[main,5,main])--java.net.MalformedURLE
> >>>>>>>>>xc e pt i on
> >>>>>>>>>
> >>>>>>>>> : no protocol: ../common/UBL-CommonAggregateComponents-2.0.xsd
> >>>>>>>>>
> >>>>>>>>>         at java.net.URL.<init>(URL.java:567)
> >>>>>>>>>         at java.net.URL.<init>(URL.java:464)
> >>>>>>>>>         at java.net.URL.<init>(URL.java:413)
> >>>>>>>>>         at
> >>>>>>>>> org.eclipse.persistence.sdo.helper.DefaultSchemaResolver.resolveS
> >>>>>>>>>ch e ma ( De faultSchemaResolver.java:55) at
> >>>>>>>>> org.eclipse.persistence.sdo.helper.SchemaResolverWrapper.resolveS
> >>>>>>>>>ch e ma ( Sc hemaResolverWrapper.java:61) at
> >>>>>>>>> org.eclipse.persistence.sdo.helper.SDOTypesGenerator.getReference
> >>>>>>>>>dS c he m a( SDOTypesGenerator.java:2056) at
> >>>>>>>>> org.eclipse.persistence.sdo.helper.SDOTypesGenerator.getSchema(SD
> >>>>>>>>>OT y pe s Ge nerator.java:2025) at
> >>>>>>>>> org.eclipse.persistence.sdo.helper.SDOTypesGenerator.getSchema(SD
> >>>>>>>>>OT y pe s Ge nerator.java:1999) at
> >>>>>>>>> org.eclipse.persistence.sdo.helper.SDOTypesGenerator.define(SDOTy
> >>>>>>>>>pe s Ge n er ator.java:108) at
> >>>>>>>>> org.eclipse.persistence.sdo.helper.SDOClassGenerator.generate(SDO
> >>>>>>>>>Cl a ss G en erator.java:209) at
> >>>>>>>>> org.eclipse.persistence.sdo.helper.SDOClassGenerator.generate(SDO
> >>>>>>>>>Cl a ss G en erator.java:175) at
> >>>>>>>>> org.eclipse.persistence.sdo.helper.SDOClassGenerator.main(SDOClas
> >>>>>>>>>sG e ne r at or.java:111)
> >>>>>>>>>
> >>>>>>>>> Looking at the relevant line in the xsd file, it starts:-
> >>>>>>>>>
> >>>>>>>>> <?xml version="1.0" encoding="UTF-8"?>
> >>>>>>>>> <!--
> >>>>>>>>>   Document Type:     Invoice
> >>>>>>>>>   Generated On:      Tue Oct 03 2:26:38 P3 2006
> >>>>>>>>>
> >>>>>>>>> -->
> >>>>>>>>> <!-- ===== xsd:schema Element With Namespaces Declarations =====
> >>>>>>>>> --> <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema";
> >>>>>>>>>
> >>>>>>>>> targetNamespace="urn:oasis:names:specification:ubl:schema:xsd:Inv
> >>>>>>>>>oi c e- 2 "
> >>>>>>>>> xmlns="urn:oasis:names:specification:ubl:schema:xsd:Invoice-2"
> >>>>>>>>>
> >>>>>>>>> xmlns:cac="urn:oasis:names:specification:ubl:schema:xsd:CommonAgg
> >>>>>>>>>re g at e Co mponents-2"
> >>>>>>>>>
> >>>>>>>>> xmlns:cbc="urn:oasis:names:specification:ubl:schema:xsd:CommonBas
> >>>>>>>>>ic C om p on ents-2"
> >>>>>>>>>
> >>>>>>>>> xmlns:udt="urn:un:unece:uncefact:data:specification:UnqualifiedDa
> >>>>>>>>>ta T yp e sS chemaModule:2"
> >>>>>>>>> xmlns:ccts="urn:un:unece:uncefact:documentation:2"
> >>>>>>>>>
> >>>>>>>>> xmlns:ext="urn:oasis:names:specification:ubl:schema:xsd:CommonExt
> >>>>>>>>>en s io n Co mponents-2"
> >>>>>>>>>
> >>>>>>>>> xmlns:qdt="urn:oasis:names:specification:ubl:schema:xsd:Qualified
> >>>>>>>>>Da t at y pe s-2" elementFormDefault="qualified"
> >>>>>>>>>     attributeFormDefault="unqualified"
> >>>>>>>>>     version="2.0">
> >>>>>>>>> <!-- ===== Imports ===== -->
> >>>>>>>>>   <xsd:import
> >>>>>>>>> namespace="urn:oasis:names:specification:ubl:schema:xsd:CommonAgg
> >>>>>>>>>re g at e Co mponents-2"
> >>>>>>>>> schemaLocation="../common/UBL-CommonAggregateComponents-2.0.xsd"/
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> and I think it is complaining about schemaLocation.
> >>>>>>>>>
> >>>>>>>>> I guess this is because of the lack of a protocol.
> >>>>>>>>>
> >>>>>>>>> I am using Sun Java 6 on linux, using its default XML code.
> >>>>>>>>>
> >>>>>>>>> Perhaps the code in DefaultSchemaResolver needs to trap this
> >>>>>>>>> exception and try adding file:/// to the front of the URL.  I do
> >>>>>>>>> not know whether this is really a fault with the OASIS xsd file
> >>>>>>>>> but they have been in the field for a while and I am sure of XML
> >>>>>>>>> parsers generally objected to this it would have been picked up
> >>>>>>>>> as a problem.
> >>>>>>>>>
> >>>>>>>>> In fact looking at the code, should DefaultSchemaResolver.java
> >>>>>>>>> line 55 which currently reads:-
> >>>>>>>>>
> >>>>>>>>>                 schemaUrl = new URL(schemaLocation);
> >>>>>>>>>
> >>>>>>>>> read instead:-
> >>>>>>>>>
> >>>>>>>>> 		schemaUrl = new URI(schemaLocation).toUrl();
> >>>>>>>>>
> >>>>>>>>> as the javadoc for URI says that it can handle this kind of
> >>>>>>>>> specification without a protocol.
> >>>>>>>>>
> >>>>>>>>> David
> >>>>>>>>> _______________________________________________
> >>>>>>>>> eclipselink-users mailing list
> >>>>>>>>> eclipselink-users@xxxxxxxxxxx
> >>>>>>>>> https://dev.eclipse.org/mailman/listinfo/eclipselink-users
> >>>>>>>
> >>>>>>> _______________________________________________
> >>>>>>> eclipselink-users mailing list
> >>>>>>> eclipselink-users@xxxxxxxxxxx
> >>>>>>> https://dev.eclipse.org/mailman/listinfo/eclipselink-users
> >>>>>>
> >>>>>> _______________________________________________
> >>>>>> eclipselink-users mailing list
> >>>>>> eclipselink-users@xxxxxxxxxxx
> >>>>>> https://dev.eclipse.org/mailman/listinfo/eclipselink-users
> >>>>
> >>>> _______________________________________________
> >>>> eclipselink-users mailing list
> >>>> eclipselink-users@xxxxxxxxxxx
> >>>> https://dev.eclipse.org/mailman/listinfo/eclipselink-users
> >>>
> >>> _______________________________________________
> >>> eclipselink-users mailing list
> >>> eclipselink-users@xxxxxxxxxxx
> >>> https://dev.eclipse.org/mailman/listinfo/eclipselink-users
> >
> > _______________________________________________
> > eclipselink-users mailing list
> > eclipselink-users@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/eclipselink-users




Back to the top