MalformedURLException in sdo-compiler

Thank you, I am happy to test any new code when it becomes available.

David

On Thursday 24 July 2008, David McCann wrote:

FYI,  I've updated the bug (240166
<https://bugs.eclipse.org/bugs/show_bug.cgi?id=240166>) with more
information.  There seems to be an issue processing complex types  with
an extension base that references a type with simple content.

--Dave
------------------------------------------------------------------------

David Goodenough wrote:

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/m
ain doc/"); } else {

setBaseSchemaLocation("file:///C:/EclipseLink/eclipse-main/sdo/bin/xsd/c
omm 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:UnqualifiedDataTypesSchemaMo
du 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.unmarshalE
xc e pt io n(X MLMarshalException.java:91) at
org.eclipse.persistence.internal.oxm.record.SAXUnmarshaller.unmar
sh a l( SA XUn marshaller.java:550) at
org.eclipse.persistence.internal.oxm.record.SAXUnmarshaller.unmar
sh a l( SA XUn marshaller.java:458) at
org.eclipse.persistence.oxm.XMLUnmarshaller.unmarshal(XMLUnmarsha
ll e r. ja va: 447) at
org.eclipse.persistence.sdo.helper.SDOTypesGenerator.getSchema(SD
OT y pe sG ene rator.java:2018) at
org.eclipse.persistence.sdo.helper.SDOTypesGenerator.getSchema(SD
OT y pe sG ene rator.java:2027) at
org.eclipse.persistence.sdo.helper.SDOTypesGenerator.getSchema(SD
OT y pe sG ene rator.java:1999) at
org.eclipse.persistence.sdo.helper.SDOTypesGenerator.define(SDOTy
pe s Ge ne rat or.java:108) at
org.eclipse.persistence.sdo.helper.SDOClassGenerator.generate(SDO
Cl a ss Ge ner ator.java:209) at
org.eclipse.persistence.sdo.helper.SDOClassGenerator.generate(SDO
Cl a ss Ge ner ator.java:175) at
uk.co.linkchoose.eclipselink.sdoCompiler.CustomClassGenerator.<in
it

(C us tom ClassGenerator.java:21) at

uk.co.linkchoose.eclipselink.sdoCompiler.CustomClassGenerator.mai
n( 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(FtpURLConnectio
n. j av a: 270 ) at
sun.net.www.protocol.ftp.FtpURLConnection.getInputStream(FtpURLCo
nn e ct io n.j ava:352) at
com.sun.org.apache.xerces.internal.impl.XMLEntityManager.setupCur
re n tE nt ity (XMLEntityManager.java:653) at
com.sun.org.apache.xerces.internal.impl.XMLVersionDetector.determ
in e Do cV ers ion(XMLVersionDetector.java:186) at
com.sun.org.apache.xerces.internal.parsers.XML11Configuration.par
se ( XM L1 1Co nfiguration.java:771) at
com.sun.org.apache.xerces.internal.parsers.XML11Configuration.par
se ( XM L1 1Co nfiguration.java:737) at
com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLPar
se r .j av a:1 07) at
com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.pars
e( A bs tr act SAXParser.java:1132) at
com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXPars
er . pa rs e(S AXParserImpl.java:533) at
org.eclipse.persistence.internal.oxm.record.XMLReader.parse(XMLRe
ad e r. ja va: 103) at
org.eclipse.persistence.internal.oxm.record.SAXUnmarshaller.unmar
sh 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:CommonAggregate
Co 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.Malforme
dU 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.res
ol v eS ch e ma ( De faultSchemaResolver.java:55) at
org.eclipse.persistence.sdo.helper.SchemaResolverWrapper.res
ol v eS ch e ma ( Sc hemaResolverWrapper.java:61) at
org.eclipse.persistence.sdo.helper.SDOTypesGenerator.getRefe
re n ce dS c he m a( SDOTypesGenerator.java:2056) at
org.eclipse.persistence.sdo.helper.SDOTypesGenerator.getSche
ma ( SD OT y pe s Ge nerator.java:2025) at
org.eclipse.persistence.sdo.helper.SDOTypesGenerator.getSche
ma ( 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.generat
e( S DO Cl a ss G en erator.java:209) at
org.eclipse.persistence.sdo.helper.SDOClassGenerator.generat
e( S DO Cl a ss G en erator.java:175) at
org.eclipse.persistence.sdo.helper.SDOClassGenerator.main(SD
OC 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:xs
d: 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:Comm
on A gg re g at e Co mponents-2"

xmlns:cbc="urn:oasis:names:specification:ubl:schema:xsd:Comm
on B as ic C om p on ents-2"

xmlns:udt="urn:un:unece:uncefact:data:specification:Unqualif
ie 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:Comm
on E xt en s io n Co mponents-2"

xmlns:qdt="urn:oasis:names:specification:ubl:schema:xsd:Qual
if 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:Comm
on 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@...
https://dev.eclipse.org/mailman/listinfo/eclipselink-users

_______________________________________________
eclipselink-users mailing list
eclipselink-users@...
https://dev.eclipse.org/mailman/listinfo/eclipselink-users

MalformedURLException in sdo-compiler

Re: MalformedURLException in sdo-compiler

Re: MalformedURLException in sdo-compiler