commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From robert burrell donkin <>
Subject Re: AW: [Betwixt] XMLBeanInfo customization
Date Mon, 18 Nov 2002 21:52:44 GMT
On Monday, November 18, 2002, at 08:41 PM, wrote:

> <%--- snip ---%>

>>> For handling XMLBeanInfos i guess a pluggable mechanism
>> could be the right
>>> way, since there are different opinions about how and where to store
>>> XMLBeanInfos.
>> IMHO these are solutions to different problems.
> How do you propose to handle different strategies for getting 
> XMLBeanInfos,
> like introspection, .betwixt files, FooBarXMLBeanInfo classes, etc.?

i'd need to hear what other people thing about some of the priorities but 
i think that the basic flow of the algorithm should be straight forward.

XMLBeanInfoRegistry would simply act as a cache. if the required 
XMLBeanInfo isn't in the cache, then XMLIntrospector would create one. it 
would first look for a custom mapping (either a .betwixt file or a custom 
class). if it couldn't find a custom mapping, then it would use 
introspection to create a generic mapping. (this introspection might be 
pluggable later).

> Should all his reside inside the XMLIntrospector? I would like to see a 
> way to
> append new strategies without having to rewrite the code of 
> XMLIntrospector
> or put the info into the XMLBeanInfoRegistry without taking care of the
> XMLIntrospector.

i think that you should able to do this by adding XMLBeanInfo's into the 
XMLBeanInfoRegistry programmatically before starting the betwixt reading 
or writing. if an XMLBeanInfo's is in the registry, then there would be no 
need for XMLIntrospector to create one.

> Since a cache might be flushed the initially added infos
> would be lost without chance to put them back in the registry.

the intention was to allow the cache to be flushed programmatically by 
users. (the current XMLIntrospection has this feature.)

but maybe it wouldn't be necessary. if it's pluggable, then users would be 
able to flush the cache by replacing the current instance with another. of 
course, if users really needed a flushable implementation, then they'd be 
free to create on of their own.

- robert

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message