Next questions... :)
Is there any way (short of using XSL translation) to unmarshal an object
based upon an Attribute?
Example:
<Command Type="Submit"/>
would create a submit object while
<Command Type="Query"/>
would create a query object.
Is there anything that the XML Mapping file can do that can't be done with
the Descriptor framework in regards to un/marshalling?
Thanks in advance,
Jody Terrill
Hewlett-Packard
> -----Original Message-----
> From: Keith Visco [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, October 17, 2001 2:54 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [castor-dev] Un/Marshalling abstract objects
>
>
>
>
> Hi Jody,
>
> You should be able to do what you want with Castor. You can use a
> combination of compiled descriptors, mapping file, and default
> introspection.
>
> For example, if all the implementations of Message class are
> in the same
> package, including the Root class, Castor can automatically find these
> classes based on the element name.
>
> If you have an element named "command" then Castor will look
> for a class
> called Command.class
>
> The package that Castor looks in will be the package of the parent
> class...ie the Root.class.
>
> If you need to change this behavior you can always implement your own
> ClassDescriptorResolver.
>
> The default implementation is
> org.exolab.castor.xml.util.ClassDescriptorResolverImpl.
>
> Hope that helps,
>
> --Keith
>
>
> "TERRILL,JODY (HP-Boise,ex1)" wrote:
> >
> > Hello,
> >
> > I am looking at using Castor as a marshalling framework and
> have some
> > questions regarding how this might work with abstract java
> objects. I have
> > a java object model that allows a root object to contain one to many
> > abstract message objects. I'll try to simplify and
> summarize this below...
> >
> > public class Root{
> > private java.util.ArrayList _messageList; // holds
> Message objects
> > }
> >
> > public abstract class Message;
> > public class Command extends Message;
> > public class Response extends Message;
> >
> > The XML instance can look like ...
> >
> > <Root>
> > <Command ID="3"/>
> > </Root>
> > or
> > <Root>
> > <Response ID="3"/>
> > </Root>
> >
> > I would like the Root class to only hold the abstract base
> class Message
> > (not Command and Response). Actually, in my problem there
> are potentially
> > >50 Message types.
> >
> > I think I can do the unmarshalling if I add an
> XMLFieldDescriptorImpl for
> > each possible Message type. What I think I would like is
> to write some code
> > that would generically create the object based upon it
> reflected name (e.g.
> > Command) and then checks to see if it is an instanceof
> Message. If it is, I
> > can add it to the _messagelist. This would allow others to
> extend the
> > framework without having to change the Root marshalling.
> >
> > For marshalling, what I think I need is a way for the
> framework to find the
> > proper descriptor to call instead of the abstract classes
> descriptor (e.g.
> > CommandDescriptor instead of MessageDescriptor). Is there
> a way for this to
> > happen or a way for the MessageDescriptor to figure the inheritance
> > heirarchy out and call the correct descriptor?
> >
> > I have primarily been working with the compile-time
> Descriptors. I briefly
> > looked at the mapping behaviour but I didn't see how it
> would help in this
> > situation and I would like the performance of the
> compile-time behaviour.
> >
> > Any insight into how this might be solved with Castor is
> appreciated.
> >
> > Thanks in advance,
> > Jody Terrill
> > Hewlett-Packard
> >
> > -----------------------------------------------------------
> > 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
