Erik,
I am confused about what you were saying below. We were talking about performance and a hashtable is always order one unless the hasttable is not growing as items are added, so the performance is still going to be the same no matter how big the hash is. Maybe you have changed the subject to memory. Can you clue me in here? Sorry that I got lost on this one.
Dean
[EMAIL PROTECTED] wrote:
Dean,----------------------------------------------------------- If you wish to unsubscribe from this mailing, send mail to
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
[EMAIL PROTECTED] with a subject of:
unsubscribe castor-dev
