I agree on the first part of your statements. But giving that we will be introducing a new XMLContext object soon (similar to what JAXB offers, i.e. JAXBContext), this might be the right place for introducing such functionality.
Can you please create a new Jira issue for me to act upon it, copying the relevant fragments of this thread ? Regards Werner Godmar Back wrote: > A static method sounds reasonable and would save memory and reduce > name space pollution on the XML object. I'm not too familiar with > Castor's internals, but it seems to me that the correct thing may be > to have an immutable singleton Descriptor object. If so, the static > method should return a reference to this singleton, avoiding the need > for newInstance(). > > - Godmar > > On 4/27/07, Werner Guttmann <[EMAIL PROTECTED]> wrote: >> Godmar, >> >> I am not really sure how to go about this, to be honest. Somehow, >> adding a 'getCastorDescriptor()' method onto the domain objects does >> not sound right to me, as it seems to be intrusive. Yes, I agree that >> this could be an option (configurable by the means of the source >> generator properties file), but still my above comment is valid. >> >> I do acknowledge, though, that below code fragment could be moved into >> Castor, adding a (static) method to provide lookup functionality for a >> given class' descriptor. Actually, that code should be in place >> already, as it's used by the XMLClassDescriptorResolver internally to >> lookup an (XML)ClassDescriptor, so this should be about making this >> public ally available only. >> >> Let me know what you think about these thoughts. >> >> Werner >> >> > -----Ursprüngliche Nachricht----- >> > Von: Godmar Back [mailto:[EMAIL PROTECTED] >> > Gesendet: Donnerstag, 26. April 2007 15:00 >> > An: [email protected] >> > Betreff: [castor-user] add reference from Java bean to descriptor >> > >> > In our application, we need to examine the XML elements according to >> > their schema. >> > >> > For instance, given an object, we need to identify which of its >> > attributes are required and which are not. Currently, we're doing the >> > following, where 'catClass' is the object whose attributes we want to >> > find. >> > >> > /** >> > * Give a class in Castor's XML binding, return the matching >> > descriptor class >> > */ >> > static Class getDescriptorClass(Class catClass) { >> > // as of Castor 1.1, descriptor classes are in subpackage >> > "descriptor" >> > try { >> > String descClass = catClass.getPackage().getName() >> > + ".descriptors." >> > + catClass.getName().replaceFirst(".*\\.", "") + >> > "Descriptor"; >> > return Class.forName(descClass); >> > >> > } catch (ClassNotFoundException cne) { >> > cne.printStackTrace(); >> > } >> > return null; >> > } >> > >> > Then we create an object of the descriptor class of type >> > XMLClassDescriptor, and iterate over its XMLFieldDescriptors. >> > >> > This is obviously ugly; and incidentally had to be rewritten when we >> > upgraded from 1.0.5 to 1.1 because the Descriptor classes were moved >> > in the package hierarchy. >> > >> > My question: is there another way to examine, at runtime, a bean's >> > descriptor given only a reference to the bean? If not, would it be >> > possible to add a "getDescriptor()" method to each bean to retrieve >> > the descriptor, or some other means to do that? "getDescriptor()" is >> > probably not a good idea since it would conflict with a "descriptor" >> > property, so either call it something else or provide a static method >> > maybe to map beans to the descriptor classes. It could be a build >> > option as well. >> > >> > - Godmar >> > >> > --------------------------------------------------------------------- >> > To unsubscribe from this list please visit: >> > >> > http://xircles.codehaus.org/manage_email >> >> >> --------------------------------------------------------------------- >> To unsubscribe from this list please visit: >> >> http://xircles.codehaus.org/manage_email >> >> > > --------------------------------------------------------------------- > To unsubscribe from this list please visit: > > http://xircles.codehaus.org/manage_email > --------------------------------------------------------------------- To unsubscribe from this list please visit: http://xircles.codehaus.org/manage_email
