commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From robert burrell donkin <robertburrelldon...@blueyonder.co.uk>
Subject Re: [Betwixt] XMLBeanInfo customization
Date Sun, 01 Dec 2002 20:01:04 GMT
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, h.dietrich@webfair.com wrote:
>>
>>>
>>>
>>>> -----Urspr√ľngliche Nachricht-----
>>>> Von: robert burrell donkin
>>>> [mailto:robertburrelldonkin@blueyonder.co.uk]
>>>> 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,
>>>> h.dietrich@webfair.com 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:commons-dev-unsubscribe@jakarta.apache.org>
>>>> For additional commands, e-mail:
>>>> <mailto:commons-dev-help@jakarta.apache.org>
>>>>
>>>
>>> --
>>> To unsubscribe, e-mail:   <mailto:commons-dev-
>>> unsubscribe@jakarta.apache.
>>> org>
>>> For additional commands, e-mail: <mailto:commons-dev-
>>> help@jakarta.apache.
>>> org>
>>>
>>
>>
>> --
>> To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.
>> org>
>> For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.
>> org>
>>
>>
>
>
>
> --
> To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.
> org>
> For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.
> org>
>


--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message