commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From robert burrell donkin <>
Subject Re: [Betwixt] XMLBeanInfo customization
Date Mon, 18 Nov 2002 19:55:23 GMT
On Monday, November 18, 2002, at 10:59 AM, wrote:

> 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 :)

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

> BTW: I got my code running and it works well, but I still use the
> Introspector to get an XMLBeanInfo and modify it the way I want to use it.

glad it's working. that's a great thing about open source - you can always 
rewrite it to make it work the way you want to.

- robert

> - Harald
>> -----Urspr√ľngliche Nachricht-----
>> Von: Stephen Colebourne []
>> Gesendet: Sonntag, 17. November 2002 22:37
>> An: Jakarta Commons Developers List
>> Betreff: Re: [Betwixt] XMLBeanInfo customization
>> From: "robert burrell donkin" <>
>>> On Saturday, November 16, 2002, at 02:08 PM, Martin van den
>> Bemt wrote:
>>>>> since XMLBeanInfo's were supposed to correspond to
>> java.beans.BeanInfo.
>>>>> BeanInfo supports programmatic implementations. so if
>> you had something
>>>>> like xxx.yyy.zzz.FooBean then betwixt might look for a
>>>>> xxx.yyy.zzz.FooBeanXMLBeanInfo class which would be a
>> programmatic
>>>>> XMLBeanInfo.
>>>>> i don't know if adding this feature would help you or not.
>>>> This is already "kind of" supported, from a
>> java.beans.Introspector
>>>> perspective. Don't think it is an ellegant solution
>> though that sun
>>>> chose (with registring searchpaths)
>>> agreed :)
>>> i was thinking along the lines of allowing a custom programmatic
>>> XMLBeanInfo implementation but insisting that the package
>> and name match
>>> exactly. so, for example, if you have a bean with full name
>>> xxx.yyy.FooBean, betwixt would try to discover a class called
>>> xxx.yyy.FooBarXMLBeanInfo.
>>> anyone have any improvements on this plan?
>> I've lost track of the original request, but...
>> [clazz] is intended to provide a pluggable replacement to
>> Introspector,
>> capable of pulling in data from XML files or specially coded classes.
>> Ideally I would like to see [betwixt] use [clazz] once
>> complete, thus maybe
>> the effort should go into [clazz] as a broader solution?
>> Stephen
>> --
>> To unsubscribe, e-mail:
>> <>
>> For additional commands, e-mail:
>> <>
> --
> 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:   <>
For additional commands, e-mail: <>

View raw message