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

No, I had resolved that.  My problem currently is with the CodeType
entity, which is complains has no id attribute.  

David

On Wednesday 23 July 2008, David McCann wrote:
> David
>
> > 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.
>
> The problem here is that your base location is set to the xsd/maindoc
> directory, which means every schema location is resolved against it,
> unless absolute.  So the import in UBL-Common... is being resolved
> against the xsd/maindoc directory (as it should).  You would need to
> write your resolver to handle this, for example:
>     ...
>     if (schemaLocation.startsWith("../")) {
>
> setBaseSchemaLocation("file:///C:/EclipseLink/eclipse-main/sdo/bin/xsd/main
>doc/"); } else {
>
> setBaseSchemaLocation("file:///C:/EclipseLink/eclipse-main/sdo/bin/xsd/comm
>on/"); }
>     // resolve accordingly
>     ...
> --Dave
>
> David Goodenough wrote:
> > Did you manage to download the xsd files from oasis and try them, and
> > does the CodeType problem below make sense?  Any ideas as to how to
> > proceed?
> >
> > David
> >
> > On Friday 11 July 2008, David Goodenough wrote:
> >> 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:UnqualifiedDataTypesSchemaModu
> >>le: 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.unmarshalExc
> >>>>>>>e pt io n(X MLMarshalException.java:91) at
> >>>>>>> org.eclipse.persistence.internal.oxm.record.SAXUnmarshaller.unmarsh
> >>>>>>>a l( SA XUn marshaller.java:550) at
> >>>>>>> org.eclipse.persistence.internal.oxm.record.SAXUnmarshaller.unmarsh
> >>>>>>>a l( SA XUn marshaller.java:458) at
> >>>>>>> org.eclipse.persistence.oxm.XMLUnmarshaller.unmarshal(XMLUnmarshall
> >>>>>>>e r. ja va: 447) at
> >>>>>>> org.eclipse.persistence.sdo.helper.SDOTypesGenerator.getSchema(SDOT
> >>>>>>>y pe sG ene rator.java:2018) at
> >>>>>>> org.eclipse.persistence.sdo.helper.SDOTypesGenerator.getSchema(SDOT
> >>>>>>>y pe sG ene rator.java:2027) at
> >>>>>>> org.eclipse.persistence.sdo.helper.SDOTypesGenerator.getSchema(SDOT
> >>>>>>>y pe sG ene rator.java:1999) at
> >>>>>>> org.eclipse.persistence.sdo.helper.SDOTypesGenerator.define(SDOType
> >>>>>>>s Ge ne rat or.java:108) at
> >>>>>>> org.eclipse.persistence.sdo.helper.SDOClassGenerator.generate(SDOCl
> >>>>>>>a ss Ge ner ator.java:209) at
> >>>>>>> org.eclipse.persistence.sdo.helper.SDOClassGenerator.generate(SDOCl
> >>>>>>>a ss 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(
> >>>>>>>C us 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.
> >>>>>>>j av a: 270 ) at
> >>>>>>> sun.net.www.protocol.ftp.FtpURLConnection.getInputStream(FtpURLConn
> >>>>>>>e ct io n.j ava:352) at
> >>>>>>> com.sun.org.apache.xerces.internal.impl.XMLEntityManager.setupCurre
> >>>>>>>n tE nt ity (XMLEntityManager.java:653) at
> >>>>>>> com.sun.org.apache.xerces.internal.impl.XMLVersionDetector.determin
> >>>>>>>e Do 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(XMLParse
> >>>>>>>r .j av a:1 07) at
> >>>>>>> com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(
> >>>>>>>A bs 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(XMLRead
> >>>>>>>e r. ja va: 103) at
> >>>>>>> org.eclipse.persistence.internal.oxm.record.SAXUnmarshaller.unmarsh
> >>>>>>>a l( 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:CommonAggregateCo
> >>>>>>>>>>>>m po 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.MalformedU
> >>>>>>>>>>>>R LE 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.resol
> >>>>>>>>>>>>v eS ch e ma ( De faultSchemaResolver.java:55) at
> >>>>>>>>>>>> org.eclipse.persistence.sdo.helper.SchemaResolverWrapper.resol
> >>>>>>>>>>>>v eS ch e ma ( Sc hemaResolverWrapper.java:61) at
> >>>>>>>>>>>> org.eclipse.persistence.sdo.helper.SDOTypesGenerator.getRefere
> >>>>>>>>>>>>n ce 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(SD
> >>>>>>>>>>>>O Ty pe s Ge n er ator.java:108) at
> >>>>>>>>>>>> org.eclipse.persistence.sdo.helper.SDOClassGenerator.generate(
> >>>>>>>>>>>>S DO Cl a ss G en erator.java:209) at
> >>>>>>>>>>>> org.eclipse.persistence.sdo.helper.SDOClassGenerator.generate(
> >>>>>>>>>>>>S DO Cl a ss G en erator.java:175) at
> >>>>>>>>>>>> org.eclipse.persistence.sdo.helper.SDOClassGenerator.main(SDOC
> >>>>>>>>>>>>l as 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:
> >>>>>>>>>>>>I nv oi c e- 2 "
> >>>>>>>>>>>> xmlns="urn:oasis:names:specification:ubl:schema:xsd:Invoice-2"
> >>>>>>>>>>>>
> >>>>>>>>>>>> xmlns:cac="urn:oasis:names:specification:ubl:schema:xsd:Common
> >>>>>>>>>>>>A gg re g at e Co mponents-2"
> >>>>>>>>>>>>
> >>>>>>>>>>>> xmlns:cbc="urn:oasis:names:specification:ubl:schema:xsd:Common
> >>>>>>>>>>>>B as ic C om p on ents-2"
> >>>>>>>>>>>>
> >>>>>>>>>>>> xmlns:udt="urn:un:unece:uncefact:data:specification:Unqualifie
> >>>>>>>>>>>>d Da ta T yp e sS chemaModule:2"
> >>>>>>>>>>>> xmlns:ccts="urn:un:unece:uncefact:documentation:2"
> >>>>>>>>>>>>
> >>>>>>>>>>>> xmlns:ext="urn:oasis:names:specification:ubl:schema:xsd:Common
> >>>>>>>>>>>>E xt en s io n Co mponents-2"
> >>>>>>>>>>>>
> >>>>>>>>>>>> xmlns:qdt="urn:oasis:names:specification:ubl:schema:xsd:Qualif
> >>>>>>>>>>>>i ed 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:Common
> >>>>>>>>>>>>A gg re g at e Co mponents-2"
> >>>>>>>>>>>> schemaLocation="../common/UBL-CommonAggregateComponents-2.0.xs
> >>>>>>>>>>>>d "/
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> 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
> >>
> >> _______________________________________________
> >> 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