<%--- 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]>
