Return-Path: Delivered-To: apmail-jakarta-commons-dev-archive@apache.org Received: (qmail 88551 invoked from network); 18 Nov 2002 19:55:57 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 18 Nov 2002 19:55:57 -0000 Received: (qmail 13985 invoked by uid 97); 18 Nov 2002 19:56:58 -0000 Delivered-To: qmlist-jakarta-archive-commons-dev@jakarta.apache.org Received: (qmail 13966 invoked by uid 97); 18 Nov 2002 19:56:57 -0000 Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Jakarta Commons Developers List" Reply-To: "Jakarta Commons Developers List" Delivered-To: mailing list commons-dev@jakarta.apache.org Received: (qmail 13939 invoked by uid 98); 18 Nov 2002 19:56:56 -0000 X-Antivirus: nagoya (v4218 created Aug 14 2002) Date: Mon, 18 Nov 2002 19:55:23 +0000 Subject: Re: [Betwixt] XMLBeanInfo customization Content-Type: text/plain; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v482) From: robert burrell donkin To: "Jakarta Commons Developers List" Content-Transfer-Encoding: quoted-printable In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.482) X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N On Monday, November 18, 2002, at 10:59 AM, h.dietrich@webfair.com 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=20 > 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=20 XMLIntrospector, this functionality would be broken out into a separate=20= pluggable class. this class would map classes to XMLBeanInfo and provide=20= services such as cache flushing. XMLIntrospector would see if the=20 XMLBeanInfo exists in the cache and if it doesn't, it would create it = and=20 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=20 rewrite it to make it work the way you want to. - robert > - Harald > >> -----Urspr=FCngliche Nachricht----- >> Von: Stephen Colebourne [mailto:scolebourne@btopenworld.com] >> 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: = org> > For additional commands, e-mail: = org> > -- To unsubscribe, e-mail: For additional commands, e-mail: