Dean,
I'm just saying that with a large schema
the Hashtable could end up with a lot
of unnecessary (not top level) entries.
--Erik
> -----Original Message-----
> From: Dean Hiller [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, December 05, 2002 11:28 AM
> To: [EMAIL PROTECTED]
> Subject: Re: [castor-dev] unmarshalling unkown xml with
> generated code
>
>
> Am I wrong in saying there is no performance hit if the
> generated
> ClassDescriptorResolverImpl
> 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:
> > > 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
