Dean,
I may have a solution: I also use generated Code from a Schema, where the
schema may grow but I just want to ignore the elements in my code (until I
choose to bind them). I added code to Castor to support this.
If I have mis-scanned your email apologies for the spam -:)
If you set the property "org.exolab.castor.xml.strictelements" to true in
the castor.properties file then new elements are ignored during the
unmarshalling.
See UnmarshallHandler# setIgnoreExtraElements
/**
* Sets whether or not elements that do not match
* a specific field should simply be ignored or
* reported as an error. By default, extra attributes
* are ignored.
*
* @param ignoreExtraElems a boolean that when true will
* allow non-matched attributes to simply be ignored.
**/
public void setIgnoreExtraElements(boolean ignoreExtraElems) {
_strictElements = (!ignoreExtraElems);
} //-- setIgnoreExtraElements
-----Original Message-----
From: Dean Hiller [mailto:[EMAIL PROTECTED]]
Sent: 05 December 2002 17:44
To: [EMAIL PROTECTED]
Subject: Re: [castor-dev] unmarshalling unkown xml with generated code
Oh, I forgot, you said
If new one unexpectedly appears, then
you probably won't have any code that uses the new unmarshalled
class.
I partially agree with you but we have a server that we just pound the
unmarshaller with a stream of objects coming in. We don't want the
unmarshaller throwing an exception because it doesn't recognize the new
object. We want to get the Object back and do something like
if(obj instanceof ButtonPress)
else if(obj instanceof DeviceID)
else if(obj instanceof SomethingElse)
else
//ignore the object until implemented.
Right now castor throws an exception instead. I just thought I would
explain our use as that is sometimes important and you might think of
something else I am forgetting.
Dean
[EMAIL PROTECTED] wrote:
>Dean wrote:
> > This seems like a maintenance nightmare though. Every
> > time someone
> > regenerates new classes, he has to remember to go add
> > the class and
> > descriptor to the Resolver.
>I agree.
>
>Dean wrote this, too:
> > I have no way of
> > knowing if new ones appear, so I will have to diff the
> > new with the old.
>If new one unexpectedly appears, then
>you probably won't have any code that uses the new unmarshalled class.
>
>Dean also wrote:
> > Maybe a subclass of ClassDescriptorResolverImpl should
> > be generated for
> > generated source code.
>I like this idea; it will work well for app's that use a single schema
file.
>I'd like to hear Keith and Arnaud's $.02 on this.
>There would be one small performance caveat -- Castor only needs you to
invoke _cdr.resolve()
>for the top level classes. You'll get a touch of a performance hit
>because the generator won't know which ones are the top level classes --
>it will have to generate a _cdr.resolve() line for all classes or
>rely on some implicit (read 'often forgotten') rule,
>like "All global elements are top level classes".
>
>If you have multiple schema files (like I do), this idea will require more
work.
>The generator will have to manage
>the chaining of multiple subclasses of ClassDescriptorResolverImpl, one
>for each schema file. You'll need some meta-data to keep the list of all
these subclasses.
>
> > -----Original Message-----
> > From: Dean Hiller [mailto:[EMAIL PROTECTED]]
> > Sent: Thursday, December 05, 2002 9:47 AM
> > To: [EMAIL PROTECTED]
> > Subject: Re: [castor-dev] unmarshalling unkown xml with
> > generated code
> >
> >
> > I instead did the following but I am wondering if there
> > is a cleaner
> > solution. The ones I saw you write look like they
> > require alot of
> > maintenance too.
> >
> > _cdr = new ClassDescriptorResolverImpl();
> > _cdr.associate(ButtonPress.class, new ButtonPressDescripto());
> > _cdr.associate(Device.class, new DeviceDescriptor());
> > .......25 more of these
> > _cdr.associate(Something.class, new SomethingDescriptor());
> >
> > This seems like a maintenance nightmare though. Every
> > time someone
> > regenerates new classes, he has to remember to go add
> > the class and
> > descriptor to the Resolver. Is there a cleaner way?
> >
> > Maybe a subclass of ClassDescriptorResolverImpl should
> > be generated for
> > generated source code. If users have non-generated
> > classes also, there
> > could be a heirarchy of these resolvers just like
> > ClassLoaders and
> > ResourceBundles.
> >
> > Our plan is to keep to the CSTA schema standard, which
> > means we will
> > regenerate these classes and new ones might appear. I
> > have no way of
> > knowing if new ones appear, so I will have to diff the
> > new with the old.
> > Maybe I will write something to generate a
> > ClasDescriptorResolver that
> > auto adds all the generated classes and can have the
> > normal Resolver as
> > it's parent.
> > I will have to think about this some more. If you have
> > any ideas, let
> > me know please,
> > thanks for the suggestions below
> > Dean
> >
> > [EMAIL PROTECTED] wrote:
> >
> > >You have a few options at this point.
> > >First, be sure you've compiled the generated
> > *Descriptor.java files
> > >and they're in the cp.
> > >
> > >1)
> > > _cdr = new ClassDescriptorResolverImpl();
> > >
> > > _cdr.resolve(/* one option for top level class */);
> > > _cdr.resolve(/* a different option for top
> > level class */);
> > > _cdr.resolve(/* yet a third option for top
> > level class */);
> > >
> > > _myUnmarshaller = new Unmarshaller((Class)null);
> > > _myUnmarshaller.setResolver(_cdr);
> > > //Now you can safely unmarshall.
> > >
> > >2) In the instance document, add an xsi:type attribute
> > > on the node that you'll pass to the unmarshaller.
> > > You don't need to specify it for the child nodes, b/c
> > > this info is code generated into the
> > *Descriptor.java files.
> > > Here is an example:
> > >
> > ><?xml version="1.0" encoding="UTF-8"?>
> > ><Wrapper>
> > > <Aclass xsi:type="java:pollux.AxClass"
> > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";>
> > > <sString>string23</sString>
> > > <xInt>23</xInt>
> > > </Aclass>
> > ></Wrapper>
> > >
> > >
> > >
> > >3) Instead of using xsi:type, you can specify a namespace.
> > > This option is nice because you can easily change
> > > your package structure without breaking the client.
> > >
> > > See this post for an example:
> > http://www.mail-archive.com/[email protected]/msg09658.html
> > >
> > >Hope this help,
> > >
> > >--Erik
> > >
> > > > -----Original Message-----
> > > > From: Dean Hiller [mailto:[EMAIL PROTECTED]]
> > > > Sent: Thursday, December 05, 2002 7:42 AM
> > > > To: [EMAIL PROTECTED]
> > > > Subject: Re: [castor-dev] unmarshalling unkown
> > xml with
> > > > generated code
> > > >
> > > >
> > > > That didnt' seem to work, throws an exception saying
> > > > "The class for the
> > > > root element 'ButtonPress' could not be found from the
> > > > UnmarshalHandler.
> > > > I am looking at the UnmarshalHandler and the
> > classDesc
> > > > returned from
> > > > _cdResolver.resolveByXMLName(name, namespace,
> > null); is
> > > > null. Because
> > > > of this, the exception is thrown. _cdResolver is a
> > > > ClassDescriptorResolverImpl, so I am now looking at
> > > > that. It loads from
> > > > the mapping first(which I don't have as I read this is
> > > > for non-generated
> > > > source code). It then goes through the cached
> > > > elements. The cache size
> > > > is 0. There are no elements in the cache. Am I
> > > > missing something?
> > > > thanks very much for your help,
> > > > Dean
> > > >
> > > > [EMAIL PROTECTED] wrote:
> > > >
> > > > >Use this:
> > > > >
> > > > > _myUnmarshaller = new
> > Unmarshaller((Class)null);
> > > > >
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Dean Hiller [mailto:[EMAIL PROTECTED]]
> > > > > > Sent: Wednesday, December 04, 2002 3:56 PM
> > > > > > To: [EMAIL PROTECTED]
> > > > > > Subject: [castor-dev] unmarshalling
> > unkown xml with
> > > > > > generated code
> > > > > >
> > > > > >
> > > > > > I am sorry, the mail archives seem to
> > be down, so I
> > > > > > could not search
> > > > > > them yet.
> > > > > >
> > > > > > I see Mapping is supposed to be used
> > for non-generated
> > > > > > code from what I
> > > > > > read so far. How do I unmarshal
> > objects where I don't
> > > > > > know what the xml
> > > > > > is ahead of time. I can't seem to
> > just do this
> > > > > >
> > > > > > UnMarshaller u = new UnMarshaller();
> > > > > > Object o = u.unmarshal(myStream);
> > > > > > if(o instanceof Device).......
> > > > > > else if(o instanceof System).....
> > > > > >
> > > > > > I am sure castor can handle this. I
> > am just not sure
> > > > > > how to do it.
> > > > > > thanks for any help in this,
> > > > > > Dean
> > > > > >
> > > > > >
> > > >
> > -----------------------------------------------------------
> > > > > > 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
-----------------------------------------------------------
If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
unsubscribe castor-dev
