From commons-dev-return-20478-qmlist-jakarta-archive-commons-dev=jakarta.apache.org@jakarta.apache.org Sun Dec 01 20:00:54 2002 Return-Path: Delivered-To: apmail-jakarta-commons-dev-archive@apache.org Received: (qmail 73260 invoked from network); 1 Dec 2002 20:00:53 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 1 Dec 2002 20:00:53 -0000 Received: (qmail 14096 invoked by uid 97); 1 Dec 2002 20:01:59 -0000 Delivered-To: qmlist-jakarta-archive-commons-dev@jakarta.apache.org Received: (qmail 14061 invoked by uid 97); 1 Dec 2002 20:01:58 -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 14049 invoked by uid 98); 1 Dec 2002 20:01:58 -0000 X-Antivirus: nagoya (v4218 created Aug 14 2002) Date: Sun, 1 Dec 2002 20:01:04 +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: <1038567368.30603.10.camel@swami> Message-Id: <9F76DA62-0567-11D7-911A-003065DC754C@blueyonder.co.uk> 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 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=20= >> 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=FCngliche 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=20= >>> 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=20 >>> 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: >>>> >>>> For additional commands, e-mail: >>>> >>>> >>> >>> -- >>> To unsubscribe, e-mail: >> unsubscribe@jakarta.apache. >>> org> >>> For additional commands, e-mail: >> help@jakarta.apache. >>> org> >>> >> >> >> -- >> To unsubscribe, e-mail: = > org> >> For additional commands, e-mail: = > org> >> >> > > > > -- > To unsubscribe, e-mail: = org> > For additional commands, e-mail: = org> > -- To unsubscribe, e-mail: For additional commands, e-mail: