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

Reply via email to