<%--- snip ---%>

> > Is there a reason for keeping the XMLBeanInfos inside the 
> Introspector. I
> > would prefer something like an XMLBeanInfoRegistry class, 
> which keeps the
> > instances. This would make it easier to provide 
> XMLBeanInfo, which might 
> > me
> > generated on the fly without using an Introspector.
> 
> let's see if i've got this right.
> 
> the idea would be that rather than caching the XMLBeanInfo's inside 
> XMLIntrospector, this functionality would be broken out into 
> a separate 
> pluggable class. this class would map classes to XMLBeanInfo 
> and provide 
> services such as cache flushing. XMLIntrospector would see if the 
> XMLBeanInfo exists in the cache and if it doesn't, it would 
> create it and 
> then ask the XMLBeanInfoRegistry to cache it.
> 
> i quite like this idea :)

Great!!!

> 
> > 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.? 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. Since a cache might be flushed the initially added infos
would be lost without chance to put them back in the registry.

- Harald

--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to