[prev in list] [next in list] [prev in thread] [next in thread]
List: xmlbeans-user
Subject: RE: scomp error - incompatible return type
From: "Radu Preotiuc-Pietro" <radup () bea ! com>
Date: 2008-03-15 1:48:35
Message-ID: BF6B6CA032BA0A429BD924F96765147DA7C03C () repbex02 ! amer ! bea ! com
[Download RAW message or body]
Exactly, in your original example the Schema is invalid and XMLBeans has
a bug for not reporting the condition sooner. This is the paragraph of
the spec that I was referring to:
http://www.w3.org/TR/xmlschema-1/#cos-ct-extends
Clause 1.5 is clearly not satisfied by your original example. If the
Schema in error comes from a 3rd party you can easily point out to them
(politely :-) that the Schema is invalid, if you have the chance (and in
the meantime, you need to use a local modified copy). If you control one
of the Schemas involved, then you need to change the Schema that you do
control.
The "shape" example on the other hand, I believe it's all right, because
the "radius" element has the same type (xsd:double) in both places and
the minOccurs="1" in the derived type is a restriction of minOccurs="0"
in the original type.
I know this is not the easiest part of XMLSchema to understand, but if
you think about it, I believe it makes sense.
Hope this helps,
Radu
________________________________
From: Ash Lux [mailto:ashlux@gmail.com]
Sent: Friday, March 14, 2008 6:14 PM
To: user@xmlbeans.apache.org
Subject: Re: scomp error - incompatible return type
Thank you Jacob and Radu for the help.
Unfortunately I'm not the one who controls the schema - it's one
of "define a schema by a large committee thing". I'm sure that explains
a lot. :-) I'll certainly try and get the schema fixed, but I don't
want to accuse them of having a bad schema when XMLBeans has a bug.
Radu is tihs what you're talking about being invalid?:
<xsd:element name="shape" type="shape"/>
<xsd:complexType name="shape" abstract="true">
<xsd:sequence>
<xsd:element name="length" type="xsd:double" minOccurs="0"/>
<xsd:element name="width" type="xsd:double" minOccurs="0"/>
<xsd:element name="radius" type="xsd:double" minOccurs="0"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="circle_restrict" abstract="true">
<xsd:complexContent>
<xsd:restrict base="shape">
</xsd:restrict>
</xsd:complexContent>
</xsd:complexType>
<xsd:complexType name="circle">
<xsd:complexContent>
<xsd:extension base="circle_restrict">
<xsd:element name="radius" type="xsd:double" minOccurs="1"
maxOccurs="1"/>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
I am doing something similar to this with a schema I do control.
When using XMLBeans, the Circle class will have getters and setters for
radius, length, and width but if you try to set anything other than
radius the object will not validate (actually XMLBeans might throw an
exception, I don't quite remember). This seems to be the correct
behavior from what I understand (which might not be much).
In the above example, XMLBeans overrides Circle_Restrict's
getRadius method and replaces it with its own.
So in my original example the ArrestingGearTimeSliceType class
is trying to override AbstractGMLType's getDescription method (with a
int return type) as implement it's own getDescription (with a string
return type).
It looks to me XMLBeans has a bug one way or another - either
the schema is valid and XMLBeans is blowing up on compile or XMLBeans
isn't catching the invalid schema and blowing up on compile. If this is
a valid schema, there's not really a pretty solution XMLBeans can use..
On 3/13/08, Radu Preotiuc-Pietro <radup@bea.com> wrote:
Having an element called "description" of type "int"
does sound fishy to
me, so I suggest you change that to "string".
I seem to vaguely remember that there is a Schema rule
according to
which you can't remove an element by restriction and
then in a
subsequent derivation step, add it back by extension,
which is what is
happening here. If my recollection is correct, then
there is a bug in
XMLBeans for not catching this error sooner. If not,
then it is just a
Java limitation (are you compiling with jdk1.5 or 1.4?)
Radu
On Thu, 2008-03-13 at 11:00 -0700, Jacob Danner wrote:
> As far as whats going on, ArrestingGearTimeSlice has 2
description
> elements defined
> 1 from xs:extension
base="AbstractAIXMTimeSliceBaseType" which refers
> to the top level description as an int
> and the other from <xs:group
ref="ArrestingGearPropertyGroup"/> which
> refers to its local type description as a string.
>
> I'm not really sure whats intended by the aixm group
here, but it
> appears to be a valid error (one I would expect) from
the schema
> snippet you posted.
> You may want to contact aixm about it.
> If you can tell us what is expected from that type,
maybe we can hack
> up a real workaround for you, but the simplest thing I
would suggest
> is to change those types to match.
> -jacobd
>
> On Thu, Mar 13, 2008 at 6:06 AM, Ash Lux
<ashlux@gmail.com> wrote:
> > I've been trying to use a third party's XSD with
XMLBeans (specifically
> > something called AIXM - http://www.aixm.aero/).
> >
> > I'm unsure if the problem lies with XMLBeans or with
the schema. I was able
> > to replicate the problem with this test XSD:
> >
> > <xs:schema
xmlns:xs="http://www.w3.org/2001/XMLSchema"
> > elementFormDefault="qualified"
> > attributeFormDefault="unqualified">
> >
> > <xs:element name="ArrestingGearTimeSlice"
> > type="ArrestingGearTimeSliceType">
> > </xs:element>
> >
> > <xs:complexType name="ArrestingGearTimeSliceType">
> > <xs:complexContent>
> > <xs:extension
base="AbstractAIXMTimeSliceBaseType">
> > <xs:sequence>
> > <xs:group
ref="ArrestingGearPropertyGroup"/>
> > </xs:sequence>
> > </xs:extension>
> > </xs:complexContent>
> > </xs:complexType>
> >
> > <xs:group name="ArrestingGearPropertyGroup">
> > <xs:sequence>
> > <xs:element name="description"
type="xs:string" nillable="true"
> > minOccurs="0"/>
> > </xs:sequence>
> > </xs:group>
> >
> > <xs:complexType
name="AbstractAIXMTimeSliceBaseType" abstract="true">
> > <xs:complexContent>
> > <xs:restriction base="AbstractGMLType">
> > </xs:restriction>
> > </xs:complexContent>
> > </xs:complexType>
> >
> > <xs:complexType name="AbstractGMLType"
abstract="true">
> > <xs:sequence>
> > <xs:group ref="StandardObjectProperties"/>
> > </xs:sequence>
> > </xs:complexType>
> >
> > <xs:group name="StandardObjectProperties">
> > <xs:sequence>
> > <xs:element ref="description" minOccurs="0"/>
> > </xs:sequence>
> > </xs:group>
> >
> > <xs:element name="description" type="xs:int"/>
> >
> > </xs:schema>
> >
> > This is my output from scomp:
> >
> > ashlux@ashlux-work:~/Desktop$
~/java/xmlbeans-2.3.0/bin/scomp test.xsd
> > Time to build schema type system: 2.25 seconds
> > Time to generate code: 0.621 seconds
> >
/tmp/xbean41513.d/src/noNamespace/ArrestingGearTimeSliceType.java:29:
> > xgetDescription() in
noNamespace.ArrestingGearTimeSliceType clashes with
> > xgetDescription() in noNamespace.AbstractGMLType;
attempting to use
> > incompatible return type
> > found : org.apache.xmlbeans.XmlString
> > required: org.apache.xmlbeans.XmlInt
> > org.apache.xmlbeans.XmlString xgetDescription();
> > ^
> >
/tmp/xbean41513.d/src/noNamespace/ArrestingGearTimeSliceType.java:24:
> > getDescription() in
noNamespace.ArrestingGearTimeSliceType clashes with
> > getDescription() in noNamespace.AbstractGMLType;
attempting to use
> > incompatible return type
> > found : java.lang.String
> > required: int
> > java.lang.String getDescription();
> > ^
> >
/tmp/xbean41513.d/src/noNamespace/impl/ArrestingGearTimeSliceTypeImpl.ja
va:47:
> > xgetDescription() in
noNamespace.impl.ArrestingGearTimeSliceTypeImpl cannot
> > implement xgetDescription() in
noNamespace.AbstractGMLType; attempting to
> > use incompatible return type
> > found : org.apache.xmlbeans.XmlString
> > required: org.apache.xmlbeans.XmlInt
> > public org.apache.xmlbeans.XmlString
xgetDescription()
> > ^
> >
/tmp/xbean41513.d/src/noNamespace/impl/ArrestingGearTimeSliceTypeImpl.ja
va:29:
> > getDescription() in
noNamespace.impl.ArrestingGearTimeSliceTypeImpl cannot
> > implement getDescription() in
noNamespace.AbstractGMLType; attempting to use
> > incompatible return type
> > found : java.lang.String
> > required: int
> > public java.lang.String getDescription()
> > ^
> > Note: Some input files use or override a deprecated
API.
> > Note: Recompile with -Xlint:deprecation for details.
> > 4 errors
> >
> > BUILD FAILED
> > ashlux@ashlux-work:~/Desktop$
> >
> > It appears as if the schema is violating the unique
particle attribution
> > rule, but I'm not sure because of the restriction
tag. If I do not use the
> > group tag, I get the unique particle attribution
rule.
> >
> > Got any thoughts on what's going on? Any thoughts
on workarounds or hacks?
> >
>
>
>
Notice: This email message, together with any
attachments, may contain information of BEA Systems, Inc., its
subsidiaries and affiliated entities, that may be confidential,
proprietary, copyrighted and/or legally privileged, and is intended
solely for the use of the individual or entity named in this message. If
you are not the intended recipient, and have received this message in
error, please immediately return this by email and then delete it.
---------------------------------------------------------------------
To unsubscribe, e-mail:
user-unsubscribe@xmlbeans.apache.org
For additional commands, e-mail:
user-help@xmlbeans.apache.org
Notice: This email message, together with any attachments, may contain information \
of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be \
confidential, proprietary, copyrighted and/or legally privileged, and is intended \
solely for the use of the individual or entity named in this message. If you are not \
the intended recipient, and have received this message in error, please immediately \
return this by email and then delete it.
[Attachment #3 (text/html)]
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=us-ascii">
<META content="MSHTML 6.00.2900.3268" name=GENERATOR></HEAD>
<BODY>
<DIV dir=ltr align=left><SPAN class=937262601-15032008><FONT face=Arial
color=#0000ff size=2>Exactly, in your original example the Schema is
invalid and XMLBeans has a bug for not reporting the condition sooner. This is
the paragraph of the spec that I was referring to:</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=937262601-15032008><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=937262601-15032008><FONT face=Arial
color=#0000ff size=2><A
href="http://www.w3.org/TR/xmlschema-1/#cos-ct-extends">http://www.w3.org/TR/xmlschema-1/#cos-ct-extends</A></FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=937262601-15032008><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=937262601-15032008><FONT face=Arial
color=#0000ff size=2>Clause 1.5 is clearly not satisfied by your original
example. If the Schema in error comes from a 3rd party you can easily point out
to them (politely :-) that the Schema is invalid, if you have the chance (and in
the meantime, you need to use a local modified copy). If you control one of the
Schemas involved, then you need to change the Schema that you do
control.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=937262601-15032008><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=937262601-15032008><FONT face=Arial
color=#0000ff size=2>The "shape" example on the other hand, I believe it's all
right, because the "radius" element has the same type (xsd:double) in both
places and the minOccurs="1" in the derived type is a restriction of
minOccurs="0" in the original type.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=937262601-15032008><FONT face=Arial
color=#0000ff size=2></FONT></SPAN><SPAN class=937262601-15032008><FONT
face=Arial color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=937262601-15032008><FONT face=Arial
color=#0000ff size=2>I know this is not the easiest part of XMLSchema to
understand, but if you think about it, I believe it makes
sense.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=937262601-15032008><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=937262601-15032008><FONT face=Arial
color=#0000ff size=2>Hope this helps,</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=937262601-15032008><FONT face=Arial
color=#0000ff size=2>Radu</FONT></SPAN></DIV><BR>
<BLOCKQUOTE
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; \
MARGIN-RIGHT: 0px"> <DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left>
<HR tabIndex=-1>
<FONT face=Tahoma size=2><B>From:</B> Ash Lux [mailto:ashlux@gmail.com]
<BR><B>Sent:</B> Friday, March 14, 2008 6:14 PM<BR><B>To:</B>
user@xmlbeans.apache.org<BR><B>Subject:</B> Re: scomp error - incompatible
return type<BR></FONT><BR></DIV>
<DIV></DIV>Thank you Jacob and Radu for the help.<BR><BR>Unfortunately I'm not
the one who controls the schema - it's one of "define a schema by a large
committee thing". I'm sure that explains a lot. :-) I'll certainly
try and get the schema fixed, but I don't want to accuse them of having a bad
schema when XMLBeans has a bug.<BR><BR>Radu is tihs what you're talking about
being invalid?:<BR><BR><xsd:element name="shape"
type="shape"/><BR><BR><xsd:complexType name="shape"
abstract="true"><BR> <xsd:sequence><BR>
<xsd:element name="length" type="xsd:double"
minOccurs="0"/><BR> <xsd:element name="width"
type="xsd:double" minOccurs="0"/><BR> <xsd:element
name="radius" type="xsd:double" minOccurs="0"/><BR>
</xsd:sequence><BR></xsd:complexType><BR><BR><xsd:complexType
name="circle_restrict" abstract="true"><BR>
<xsd:complexContent><BR> <xsd:restrict
base="shape"><BR> </xsd:restrict><BR>
</xsd:complexContent><BR></xsd:complexType><BR><BR><xsd:complexType
name="circle"><BR> <xsd:complexContent><BR>
<xsd:extension base="circle_restrict"><BR>
<xsd:element name="radius" type="xsd:double" minOccurs="1"
maxOccurs="1"/><BR> </xsd:extension><BR>
</xsd:complexContent><BR></xsd:complexType><BR><BR>I am doing
something similar to this with a schema I do control. When using
XMLBeans, the Circle class will have getters and setters for radius, length,
and width but if you try to set anything other than radius the object will not
validate (actually XMLBeans might throw an exception, I don't quite
remember). This seems to be the correct behavior from what I understand
(which might not be much).<BR><BR>In the above example, XMLBeans overrides
Circle_Restrict's getRadius method and replaces it with its own.<BR><BR>So in
my original example the ArrestingGearTimeSliceType class is trying to override
AbstractGMLType's getDescription method (with a int return type) as implement
it's own getDescription (with a string return type).<BR><BR>It looks to me
XMLBeans has a bug one way or another - either the schema is valid and
XMLBeans is blowing up on compile or XMLBeans isn't catching the invalid
schema and blowing up on compile. If this is a valid schema, there's not
really a pretty solution XMLBeans can use..<BR><BR>
<DIV><SPAN class=gmail_quote>On 3/13/08, <B class=gmail_sendername>Radu
Preotiuc-Pietro</B> <<A href="mailto:radup@bea.com">radup@bea.com</A>>
wrote:</SPAN>
<BLOCKQUOTE class=gmail_quote
style="PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: rgb(204,204,204) \
1px solid">Having an element called "description" of type "int" does sound fishy \
to<BR>me, so I suggest you change that to "string".<BR><BR>I seem to vaguely \
remember that there is a Schema rule according to<BR>which you can't remove an
element by restriction and then in a<BR>subsequent derivation step, add it
back by extension, which is what is<BR>happening here. If my recollection is
correct, then there is a bug in<BR>XMLBeans for not catching this error
sooner. If not, then it is just a<BR>Java limitation (are you compiling with
jdk1.5 or 1.4?)<BR><BR>Radu<BR><BR><BR>On Thu, 2008-03-13 at 11:00 -0700,
Jacob Danner wrote:<BR>> As far as whats going on, ArrestingGearTimeSlice
has 2 description<BR>> elements defined<BR>> 1 from xs:extension
base="AbstractAIXMTimeSliceBaseType" which refers<BR>> to the top level
description as an int<BR>> and the other from <xs:group
ref="ArrestingGearPropertyGroup"/> which<BR>> refers to its local type
description as a string.<BR>><BR>> I'm not really sure whats intended
by the aixm group here, but it<BR>> appears to be a valid error (one I
would expect) from the schema<BR>> snippet you posted.<BR>> You may
want to contact aixm about it.<BR>> If you can tell us what is expected
from that type, maybe we can hack<BR>> up a real workaround for you, but
the simplest thing I would suggest<BR>> is to change those types to
match.<BR>> -jacobd<BR>><BR>> On Thu, Mar 13, 2008 at 6:06 AM, Ash
Lux <<A href="mailto:ashlux@gmail.com">ashlux@gmail.com</A>>
wrote:<BR>> > I've been trying to use a third party's XSD with
XMLBeans (specifically<BR>> > something called AIXM - <A
href="http://www.aixm.aero/">http://www.aixm.aero/</A>).<BR>>
><BR>> > I'm unsure if the problem lies with XMLBeans or with the
schema. I was able<BR>> > to replicate the problem with
this test XSD:<BR>> ><BR>> > <xs:schema xmlns:xs="<A
href="http://www.w3.org/2001/XMLSchema">http://www.w3.org/2001/XMLSchema</A>"<BR>> \
> elementFormDefault="qualified"<BR>> \
> attributeFormDefault="unqualified"><BR>> \
><BR>> > <xs:element
name="ArrestingGearTimeSlice"<BR>> >
type="ArrestingGearTimeSliceType"><BR>> >
</xs:element><BR>> ><BR>> > <xs:complexType
name="ArrestingGearTimeSliceType"><BR>> >
<xs:complexContent><BR>>
> <xs:extension
base="AbstractAIXMTimeSliceBaseType"><BR>>
>
<xs:sequence><BR>>
>
<xs:group ref="ArrestingGearPropertyGroup"/><BR>>
>
</xs:sequence><BR>> >
</xs:extension><BR>>
> </xs:complexContent><BR>>
> </xs:complexType><BR>> ><BR>>
> <xs:group name="ArrestingGearPropertyGroup"><BR>>
> <xs:sequence><BR>>
> <xs:element name="description"
type="xs:string" nillable="true"<BR>> > minOccurs="0"/><BR>>
> </xs:sequence><BR>>
> </xs:group><BR>> ><BR>> >
<xs:complexType name="AbstractAIXMTimeSliceBaseType"
abstract="true"><BR>> >
<xs:complexContent><BR>> >
<xs:restriction base="AbstractGMLType"><BR>>
> </xs:restriction><BR>> \
> </xs:complexContent><BR>>
> </xs:complexType><BR>> ><BR>>
> <xs:complexType name="AbstractGMLType"
abstract="true"><BR>> >
<xs:sequence><BR>> >
<xs:group ref="StandardObjectProperties"/><BR>>
> </xs:sequence><BR>>
> </xs:complexType><BR>> ><BR>>
> <xs:group name="StandardObjectProperties"><BR>>
> <xs:sequence><BR>>
> <xs:element ref="description"
minOccurs="0"/><BR>>
> </xs:sequence><BR>>
> </xs:group><BR>> ><BR>> >
<xs:element name="description" type="xs:int"/><BR>> ><BR>>
> </xs:schema><BR>> ><BR>> > This is my output from
scomp:<BR>> ><BR>> > ashlux@ashlux-work:~/Desktop$
~/java/xmlbeans-2.3.0/bin/scomp test.xsd<BR>> > Time to
build schema type system: 2.25 seconds<BR>> > Time to generate code:
0.621 seconds<BR>> >
/tmp/xbean41513.d/src/noNamespace/ArrestingGearTimeSliceType.java:29:<BR>>
> xgetDescription() in noNamespace.ArrestingGearTimeSliceType clashes
with<BR>> > xgetDescription() in noNamespace.AbstractGMLType;
attempting to use<BR>> > incompatible return type<BR>>
> found : org.apache.xmlbeans.XmlString<BR>>
> required: org.apache.xmlbeans.XmlInt<BR>>
> org.apache.xmlbeans.XmlString
xgetDescription();<BR>>
> \
\
^<BR>> >
/tmp/xbean41513.d/src/noNamespace/ArrestingGearTimeSliceType.java:24:<BR>>
> getDescription() in noNamespace.ArrestingGearTimeSliceType clashes
with<BR>> > getDescription() in noNamespace.AbstractGMLType;
attempting to use<BR>> > incompatible return type<BR>>
> found : java.lang.String<BR>> > required:
int<BR>> > java.lang.String
getDescription();<BR>>
> ^<BR>> \
>
/tmp/xbean41513.d/src/noNamespace/impl/ArrestingGearTimeSliceTypeImpl.java:47:<BR>> \
> xgetDescription() in noNamespace.impl.ArrestingGearTimeSliceTypeImpl
cannot<BR>> > implement xgetDescription() in
noNamespace.AbstractGMLType; attempting to<BR>> > use incompatible
return type<BR>> > found :
org.apache.xmlbeans.XmlString<BR>> > required:
org.apache.xmlbeans.XmlInt<BR>> > public
org.apache.xmlbeans.XmlString xgetDescription()<BR>>
> \
&n \
bsp; ^<BR>> \
>
/tmp/xbean41513.d/src/noNamespace/impl/ArrestingGearTimeSliceTypeImpl.java:29:<BR>> \
> getDescription() in noNamespace.impl.ArrestingGearTimeSliceTypeImpl
cannot<BR>> > implement getDescription() in
noNamespace.AbstractGMLType; attempting to use<BR>> > incompatible
return type<BR>> > found :
java.lang.String<BR>> > required: int<BR>>
> public java.lang.String
getDescription()<BR>>
> \
\
^<BR>> > Note: Some input files use or override a deprecated
API.<BR>> > Note: Recompile with -Xlint:deprecation for
details.<BR>> > 4 errors<BR>> ><BR>> > BUILD
FAILED<BR>> > ashlux@ashlux-work:~/Desktop$<BR>> ><BR>> >
It appears as if the schema is violating the unique particle
attribution<BR>> > rule, but I'm not sure because of the restriction
tag. If I do not use the<BR>> > group tag, I get the unique
particle attribution rule.<BR>> ><BR>> > Got any thoughts on
what's going on? Any thoughts on workarounds or hacks?<BR>>
><BR>><BR>><BR>><BR><BR><BR>Notice: This email
message, together with any attachments, may contain
information of BEA
Systems, Inc., its
subsidiaries and affiliated entities, that
may be
confidential, proprietary, copyrighted and/or
legally privileged, and is intended solely for the use of the individual or
entity named in this message. If you are not the intended recipient, and
have received this message in error, please immediately return this by email
and then delete
it.<BR><BR><BR>---------------------------------------------------------------------<BR>To \
unsubscribe, e-mail: <A
href="mailto:user-unsubscribe@xmlbeans.apache.org">user-unsubscribe@xmlbeans.apache.org</A><BR>For \
additional commands, e-mail: <A
href="mailto:user-help@xmlbeans.apache.org">user-help@xmlbeans.apache.org</A><BR><BR></BLOCKQUOTE></DIV><BR></BLOCKQUOTE></BODY></HTML>
<br>
Notice: This email message, together with any attachments, may contain information \
of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be \
confidential, proprietary, copyrighted and/or legally privileged, and is intended \
solely for the use of the individual or entity named in this message. If you are not \
the intended recipient, and have received this message in error, please immediately \
return this by email and then delete it.
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic