Not leaving yet.. :) I will give a shout when I have the site for the trip ready. (will take a while though). Since it would be nice to have some work in every country I visit and to meet up with everyone ;)
Mvgr, Martin On Sun, 2002-12-01 at 21:01, robert burrell donkin wrote: > On Friday, November 29, 2002, at 10:56 AM, Martin van den Bemt wrote: > > > The TestSchema you changed should be a cool example, I'll try to use the > > beaninfosearchpath and register an xmlbeaninfo for component to see if > > it works correctly (probably next week, Sorry about my "lack' of > > interest lately, but I am in the process of trying to buy a (sailing) > > boat and selling my house, so I can do what I want : sail around the > > world :) (besides the big deadlines at work..) > > that sounds very cool :) > > good luck and a fair breeze! > > - robert > > > > Mvgr, > > Martin > > > > On Wed, 2002-11-27 at 23:25, robert burrell donkin wrote: > >> hi > >> > >> i've committed a first cut at XMLBeanInfoRegistry (if anyone wants to > >> take > >> a look). > >> > >> (sorry it's been so long.) > >> > >> - robert > >> > >> On Tuesday, November 19, 2002, at 10:55 AM, [EMAIL PROTECTED] wrote: > >> > >>> > >>> > >>>> -----Ursprüngliche Nachricht----- > >>>> Von: robert burrell donkin > >>>> [mailto:[EMAIL PROTECTED]] > >>>> Gesendet: Montag, 18. November 2002 22:53 > >>>> An: Jakarta Commons Developers List > >>>> Betreff: Re: AW: [Betwixt] XMLBeanInfo customization > >>>> > >>>> > >>>> 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. > >>> > >>> I agree. Right now Betwixt is very easy to use and that is a great > >>> benefit > >>> of this component. > >>> > >>>> > >>>> 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. > >>> > >>> Maybe you are right again, but I am still a little sceptic... > >>> It seems to me, that for customization the program flow could get very > >>> ugly, > >>> since I have to implement the registry functionality of XMLIntrospector > >>> again. But maybe it could be a solution to create a child class of > >>> XMLIntrospector, which provides the required functionality, and put this > >>> into the reader/writer instead of using the standard XMLIntrospector. > >>> I am still thinking of this, because XMLIntrospector already provides > >>> two > >>> quite different funtions - bean introspection and reading bean info from > >>> a > >>> .betwixt file... > >>> > >>>> > >>>>> 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. > >>> > >>> Here I agree again :) > >>> > >>>> > >>>> - robert > >>>> > >>>> > >>>> -- > >>>> To unsubscribe, e-mail: > >>>> <mailto:[EMAIL PROTECTED]> > >>>> For additional commands, e-mail: > >>>> <mailto:[EMAIL PROTECTED]> > >>>> > >>> > >>> -- > >>> To unsubscribe, e-mail: <mailto:commons-dev- > >>> [EMAIL PROTECTED] > >>> org> > >>> For additional commands, e-mail: <mailto:commons-dev- > >>> [EMAIL PROTECTED] > >>> org> > >>> > >> > >> > >> -- > >> To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]. > >> org> > >> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]. > >> org> > >> > >> > > > > > > > > -- > > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]. > > org> > > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]. > > org> > > > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
