[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.
It's a reasonable idea. I've toyed with it in the past actually, but thought it was unnecessary if implement two fairly simple items that have been on my mind for quite some time. We can implement a "resolve package" method which will load all ClassDescriptors found in the package. The overhead may be slightly more that a custom ClassDescriptorResolver as the default resolver looks for the *Descriptor classes within a package, but this can be a one time penalty by simply saving and reusing the resolver. The other item is it so clean-up the namespace->package resolving so that Castor can automatically detect which package to look in when it receives an element of a particaluar namespace. --Keith > 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
