Keith-
The only reason I think the *Descriptor.class files might be easier is the fact that the user is already getting a jar file from me for use. They don't need to know what's in the jar file, they just need to know how to use it... (Am I correct in assuming that using Descriptors allows the user to unmarshal using the static calls?)
I think this all comes from my belief that the mapping should be associated with the java code rather than a user document. By associating Descriptors with the java code, it is much less likely to be modified by an end-user... I think... But I could be convinced without too much work that perhaps an end-user wants the capability to change how the XML looks...
So in the end, I guess I'm still in the concept exploration stage. I like the idea of having a "fixed" XML representation of a class that "follows" the class (i.e. I don't need to change the mapping file when I change from one interface implementing class to another), but that does introduce some rigidity and increases the class count on the project.
In any case, thanks for your input, I'll look into the creation of those descriptors and see what method I like better.
Stephen
Keith Visco wrote:
Hi Stephen,
I'm not sure what the problem would be with handing over mapping files vs. handing over *Descriptor.class files, other than one is semi obfuscated compared with the other. In any case, we don't have a tool that will automatically do the translation for you, but when the mapping file is loaded, we create in-memory ClassDescriptors. So I suppose it should be fairly straight forward for one to take that same code and instead of creating in-memory ClassDescriptors, use the org.exolab.castor.builder.DescriptorSourceFactory to create the actual *Descriptor.java files.
If you want to do it manually, that should be pretty easy as well. For each <class> element in your mapping file you need a {fully qualified classname}Descriptor.java file. For simplicity you can simply extend the org.exolab.castor.xml.util.XMLClassDescriptorImpl, just like the SourceGenerator does. For each field you need a XMLFieldDescriptor, and for each XMLFieldDescriptor and associated FieldHandler.
Castor comes with some built-in descriptors in the org.exolab.castor.types package as well as in the org.exolab.castor.xml.descriptors package which you can use for reference.
--Keith
Stephen Bash wrote:
Everyone-
I've been puzzling over this problem in my head for a while now and would like some input from the rest of the community. I have an existing class structure that I am initializing with Castor (so I instantiated everything once, set it up the way I want, then marshalled to XML and when I need that setup again, I unmarshal). I have written a few very detailed mapping files to get the XML to look the way I want (well, close enough), but I realized last night that I don't really want to have to hand the mapping files to users... I'd really prefer to only have to hand them the XML file and have Castor do the rest of the work.
So that leads me to the conclusion I need to use ClassDescriptors (if there is another possibility, I'm open to input). Following this conclusion, I am wondering if it is possible to translate the preexisting mapping files into ClassDescriptors that can be included in a code distribution... I have a vague idea of how the mapping file is used internally in Castor, but not enough to know how easy/hard this problem is. Any comments on better implementations or tools to use would be greatly appreciated.
Thanks, Stephen
----------------------------------------------------------- If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
unsubscribe castor-user
----------------------------------------------------------- If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
unsubscribe castor-user
----------------------------------------------------------- If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
unsubscribe castor-user
