Return-Path: Delivered-To: apmail-jakarta-commons-dev-archive@apache.org Received: (qmail 87422 invoked from network); 7 Dec 2002 21:00:14 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 7 Dec 2002 21:00:14 -0000 Received: (qmail 22196 invoked by uid 97); 7 Dec 2002 21:01:02 -0000 Delivered-To: qmlist-jakarta-archive-commons-dev@jakarta.apache.org Received: (qmail 22102 invoked by uid 97); 7 Dec 2002 21:01:02 -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 21996 invoked by uid 98); 7 Dec 2002 21:01:01 -0000 X-Antivirus: nagoya (v4218 created Aug 14 2002) Date: Sat, 7 Dec 2002 21:00:11 +0000 Subject: Re: [beanutils] statics Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v482) From: robert burrell donkin To: "Jakarta Commons Developers List" Content-Transfer-Encoding: 7bit In-Reply-To: <20021207090925.Y5855-100000@icarus.apache.org> 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 Saturday, December 7, 2002, at 05:11 PM, Craig R. McClanahan wrote: > > > On Sat, 7 Dec 2002, robert burrell donkin wrote: > >> Date: Sat, 7 Dec 2002 09:10:47 +0000 >> From: robert burrell donkin >> Reply-To: Jakarta Commons Developers List > dev@jakarta.apache.org> >> To: Jakarta Commons Developers List >> Subject: [beanutils] statics [WAS Re: [digester] collections and default >> for useThreadClassLoader] >> >> On Saturday, December 7, 2002, at 06:50 AM, Costin Manolache wrote: >> >> >> >>> There is also the issue of statics ( which become very visible when >>> you move stuff to the top loader), and the issue of security - which is >>> particularily important for beanutil and probably in collections >>> ( i.e. - if things are cached - can an application access other >>> application's data ? Is there any thread that may change the >>> security context ? ) >> >> (now is probably a good time to raise something that's been in the air >> for >> a little while.) >> >> at the moment, beanutils is composed of static methods. the caching is >> also static. >> >> one effect of this is that there is only one global set of converters. >> another is that the cached data has to be shared globally. >> >> it might make more sense to have concrete objects. caches and other data >> would be stored with each instance. the current static methods would then >> call a static instance. >> >> users would then be free to continue to use the convenient static methods >> or they could create an instance and use that instead. >> > > +1 on exploring this, with appropriate factory methods and such. It might > also be interesting to support a mode that maintains a "static"-ish cache > per context class loader via the existing call signatures, because that's > a very useful scenario in things like a servlet container. that sounds good. the classes in beanutils depend on each other. ao we'll need to make sure that the instances are linked consistently together. probably the delegated instances should be exposed as read-only properties. a single per context class loader cache for the whole of beanutils (rather than per class) seems like a good idea. that way, we can easily make sure that a consistent set of all beanutils objects will be created every time. - robert -- To unsubscribe, e-mail: For additional commands, e-mail: