btw. the real live genericOperation is three inheritance levels down from operation,
and as the name suggests is not the end of the line.
operation <- rasterOperation <- leveledOperation <- genericOperation
They are all in one package but derivates may not be.
And also they are in the operation package, there are also packages for items,
geometry structures and raster definitions.
So do I need to know what derived types are going to be present at runtime, or write a
resolver that finds all classes in given packages?
e.g.
cdr.resolveAll("my.data.package");
Users/other developpers can add operation types. Maybe this is not a bug but a feature
request.
any ideas?
> -----Original Message-----
> From: Keith Visco [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, October 10, 2002 11:37 AM
> To: [EMAIL PROTECTED]
> Subject: Re: [castor-dev] xsi:type not unmarshaled proper
>
>
>
>
>
>
> [EMAIL PROTECTED] wrote:
> >
> > Wow, this is five layers deep in a structure containing
> other things. I don't actually call anything on these objects.
> > Can the generated objects be made to use that unmarshaller
> if i construct one like you describe?
>
> OK, so the operation element is not the root. If the operation is not
> the root then it should be working properly as is. I'll have to take a
> look into it here. If you have a test case you can send me, then
> perfect, otherwise I'll try to create one in the morning.
> Right now it's
> well past my bedtime..the birds will be up before I even get
> to bed! :-)
>
> --Keith
>
>
> >
> > > -----Original Message-----
> > > From: Keith Visco [mailto:[EMAIL PROTECTED]]
> > > Sent: Thursday, October 10, 2002 11:00 AM
> > > To: [EMAIL PROTECTED]
> > > Subject: Re: [castor-dev] xsi:type not unmarshaled proper
> > >
> > >
> > >
> > >
> > >
> > >
> > > [EMAIL PROTECTED] wrote:
> > > >
> > > > On the object.
> > >
> > > If you use Operation.unmarshal(...) then that's the problem.
> > > The objects
> > > unmarshal method will pass in unmarshal(Operation.class, reader);
> > >
> > > Castor will try to use the Operation class as the root element.
> > >
> > > However this won't work since you're trying to unmarshal a
> > > subclass that
> > > has extensions into it's super class.
> > >
> > > Try the following:
> > >
> > > import org.exolab.castor.xml.util.ClassDescriptorResolverImpl;
> > > import org.exolab.castor.xml.Unmarshaller;
> > >
> > > ...
> > >
> > > ClassDescriptorResolverImpl cdr = new
> ClassDescriptorResolverImpl();
> > > cdr.resolve(Operation.class);
> > > cdr.resolve(GenericOperation.class);
> > >
> > > Unmarshaller unm = new Unmarshaller((Class)null);
> > > unm.setResolver(cdr);
> > >
> > > Operation op = (Operation)unm.unmarshal(reader);
> > >
> > > op should be an instanceof GenericOperation.
> > >
> > > --Keith
> > >
> > >
> > >
> > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Keith Visco [mailto:[EMAIL PROTECTED]]
> > > > > Sent: Thursday, October 10, 2002 10:29 AM
> > > > > To: [EMAIL PROTECTED]
> > > > > Subject: Re: [castor-dev] xsi:type not unmarshaled proper
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > Daan,
> > > > >
> > > > > How are you calling the Unmarshaller, this will help me
> > > in determining
> > > > > if it's a bug or not.
> > > > >
> > > > > Thanks,
> > > > >
> > > > > --Keith
> > > > >
> > > > > [EMAIL PROTECTED] wrote:
> > > > > >
> > > > > > this is an old issue I think.
> > > > > > Please bear my handicap with me; I have only email at my
> > > > > workstation and no http connection to the outside world
> > > > > >
> > > > > > I have a class Operation which is generated from a
> > > > > complexType operation. It is marshaled as GenericOperation,
> > > > > which is an extension of operation. see schema
> fragments below.
> > > > > >
> > > > > > this is the marshaled fragment:
> > > > > > <operation name="LOS" xsi:type="genericOperation"
> > > > > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";>
> > > > > > <site minScale="1.0E-10" maxScale="1.0">
> > > > > > <ns7:position lon="-26.68666666666667"
> > > > > > lat="58.76666666666667"
> > > > > xmlns:ns7="itemlib.xsd"/>
> > > > > > </site>
> > > > > > </operation>
> > > > > >
> > > > > > and this is what happens if I unmarshal it:
> > > > > > org.xml.sax.SAXException: unable to find FieldDescriptor
> > > > > for 'site' in ClassDescriptor of Operation
> > > > > > at
> > > > > org.exolab.castor.xml.UnmarshalHandler.startElement(UnmarshalH
> > > > > andler.java:1021)
> > > > > > at
> > > > >
> > >
> org.apache.xerces.parsers.SAXParser.startElement(SAXParser.java:1340)
> > > > > > at
> > > > > org.apache.xerces.validators.common.XMLValidator.callStartElem
> > > > > ent(XMLValidator.java:1197)
> > > > > > at
> > > > > org.apache.xerces.framework.XMLDocumentScanner.scanElement(XML
> > > > > DocumentScanner.java:1862)
> > > > > > at
> > > > > org.apache.xerces.framework.XMLDocumentScanner$ContentDispatch
> > > > > er.dispatch(XMLDocumentScanner.java:1238)
> > > > > > at
> > > > > org.apache.xerces.framework.XMLDocumentScanner.parseSome(XMLDo
> > > > > cumentScanner.java:381)
> > > > > > at
> > > > >
> org.apache.xerces.framework.XMLParser.parse(XMLParser.java:1035)
> > > > > > at
> > > > >
> > >
> org.exolab.castor.xml.Unmarshaller.unmarshal(Unmarshaller.java:485)
> > > > > > at
> > > > >
> > >
> org.exolab.castor.xml.Unmarshaller.unmarshal(Unmarshaller.java:417)
> > > > > > at
> > > > >
> > >
> org.exolab.castor.xml.Unmarshaller.unmarshal(Unmarshaller.java:557)
> > > > > >
> > > > > > more followed
> > > > > > I tried to replace "genericOperation" with
> > > > > "my.package.for.GenericOperation" in the generated document
> > > > > instance. no show.
> > > > > > Is this issue resolved? Is it new/newly noticed? Is there a
> > > > > rogue fix? Is it resolved in cvs?
> > > > > >
> > > > > > here are the schema fragments:
> > > > > >
> > > > > > <xsd:complexType name="operation">
> > > > > > <xsd:attribute name="name" type="xsd:string"><!--
> > > > > default="operation"-->
> > > > > > </xsd:complexType>
> > > > > >
> > > > > > <xsd:complexType name="genericOperation">
> > > > > > <xsd:complexContent>
> > > > > > <xsd:extension base="sc:operation">
> > > > > > <xsd:sequence>
> > > > > > <xsd:element name="site" type="lib:radar"
> > > > > minOccurs="1" maxOccurs="1" >
> > > > > > </xsd:element>
> > > > > > </xsd:sequence>
> > > > > > </xsd:extension>
> > > > > > </xsd:complexContent>
> > > > > > </xsd:complexType>
> > > > > >
> > > > > > my gratitude will be,
> > > > > >
> > > > > > -----------------------------------------------------------
> > > > > > If you wish to unsubscribe from this mailing, send mail to
> > > > > > [EMAIL PROTECTED] with a subject of:
> > > > > > unsubscribe castor-dev
> > > > >
> > > > > -----------------------------------------------------------
> > > > > If you wish to unsubscribe from this mailing, send mail to
> > > > > [EMAIL PROTECTED] with a subject of:
> > > > > unsubscribe castor-dev
> > > > >
> > > > >
> > > >
> > > > -----------------------------------------------------------
> > > > If you wish to unsubscribe from this mailing, send mail to
> > > > [EMAIL PROTECTED] with a subject of:
> > > > unsubscribe castor-dev
> > >
> > > -----------------------------------------------------------
> > > If you wish to unsubscribe from this mailing, send mail to
> > > [EMAIL PROTECTED] with a subject of:
> > > unsubscribe castor-dev
> > >
> > >
> >
> > -----------------------------------------------------------
> > If you wish to unsubscribe from this mailing, send mail to
> > [EMAIL PROTECTED] with a subject of:
> > unsubscribe castor-dev
>
> -----------------------------------------------------------
> If you wish to unsubscribe from this mailing, send mail to
> [EMAIL PROTECTED] with a subject of:
> unsubscribe castor-dev
>
>
-----------------------------------------------------------
If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
unsubscribe castor-dev
