[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [eclipselink-users] MalformedURLException in sdo-compiler
|
I would be quite surprised if OASIS were shipping XSD files that were wrong
as they are a standards body and these files have been around since
12/12/2006, but I suppose it is possible. The version I am using is the
updated version (updated in May this year) but there is no mention in
the updates document of an issue with IDREFs.
I am not very familiar with XSD, can you suggest what I should be looking
for - what is the format of an IDREF and if it looking for a CodeType object
what would it look like (then I can do a grep or the like and try to find the
culprit).
Obviously if I do find a problem with the XSD file I will feed it back to
OASIS.
David
On Thursday 24 July 2008, David McCann wrote:
> David,
>
> I understand that - I was explaining that the behavior wasn't bizarre or
> incorrect, but expected with your configuration. Regarding your current
> issue, the error typically indicates that there is an IDREF somewhere
> that references an element that does not have an ID element. I don't
> know if this is the case here, but worth checking out. If not, perhaps
> you can provide a simplified test case - one or two schemas with as few
> types/elements as possible in order to recreate the issue.
>
> --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@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
> >
> > _______________________________________________
> > eclipselink-users mailing list
> > eclipselink-users@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/eclipselink-users
