looks like this
public class ResolverGeneratedImplementation extends ClassDescriptorResolverImpl
{
public ResolverGeneratedImplementation()
{
this.associate(/*Generated class like ButtonPress.class*/, /*descriptor like new ButtonPressDescriptor()*/);
this.associate();
this.associate(); //again and again, once for every generated class.
}
}
All the user needs to do is unmarshaller.setResolver(generatedResolver);
Looking at the ClassDescriptorResolver, it uses a hashtable and there would be no performance hit really. Am I missing something?
thanks,
Dean
[EMAIL PROTECTED] wrote:
Dean wrote:----------------------------------------------------------- If you wish to unsubscribe from this mailing, send mail to
> 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
[EMAIL PROTECTED] with a subject of:
unsubscribe castor-dev
