On Monday, November 18, 2002, at 08:41 PM, [EMAIL PROTECTED] 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: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to