Return-Path: Mailing-List: contact commons-user-help@jakarta.apache.org; run by ezmlm Delivered-To: mailing list commons-user@jakarta.apache.org Received: (qmail 20851 invoked by uid 98); 18 Dec 2002 10:14:55 -0000 X-Antivirus: nagoya (v4218 created Aug 14 2002) Received: (qmail 20825 invoked from network); 18 Dec 2002 10:14:53 -0000 Received: from daedalus.apache.org (HELO apache.org) (63.251.56.142) by nagoya.betaversion.org with SMTP; 18 Dec 2002 10:14:53 -0000 Received: (qmail 71847 invoked by uid 500); 18 Dec 2002 10:13:29 -0000 Received: (qmail 71840 invoked from network); 18 Dec 2002 10:13:28 -0000 Received: from uni-sb.de (134.96.252.33) by daedalus.apache.org with SMTP; 18 Dec 2002 10:13:28 -0000 Received: from cs.uni-sb.de (cs.uni-sb.de [134.96.252.31]) by uni-sb.de (8.12.6/2002112700) with ESMTP id gBIADfJl018981 for ; Wed, 18 Dec 2002 11:13:41 +0100 (CET) Received: from mail.cs.uni-sb.de (IDENT:oWTSMcl/kLWKmOT95GO9fDpvaXHt2bm6@mail.cs.uni-sb.de [134.96.254.200]) by cs.uni-sb.de (8.12.6/2002120200) with ESMTP id gBIADek0001487 for ; Wed, 18 Dec 2002 11:13:40 +0100 (CET) Received: from activemath.org (w264.funklan.uni-saarland.de [134.96.205.8]) by mail.cs.uni-sb.de (8.12.6/2002112700) with ESMTP id gBIADc8G005144 for ; Wed, 18 Dec 2002 11:13:38 +0100 (CET) X-Authentication-Warning: email: Host w264.funklan.uni-saarland.de [134.96.205.8] claimed to be activemath.org Date: Wed, 18 Dec 2002 11:12:18 +0100 Subject: Re: [BeanUtils] MethodUtils caching Content-Type: text/plain; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v548) From: Paul Libbrecht To: "Jakarta Commons Users List" Content-Transfer-Encoding: quoted-printable In-Reply-To: <20021217161900.D27114-100000@icarus.apache.org> Message-Id: <30750664-1271-11D7-A6BA-0003934D43BA@activemath.org> X-Mailer: Apple Mail (2.548) X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Having tests within applets looks perfect to me! The most simplistic approach would be to use appletviewer to run all=20 the jUnit tests. That would bring an amount of "failed" that would=20 force developers to flag their tests to be applet-friendly or not, then=20= presumably flag the functionalities as such. A better approach would be to run a webserver and have the applets from=20= there, I presume. Also, I am not a signed applet should not be tested=20 as well (i.e. I am not sure there is not a little bit of security left=20= within these which is again different from the simple java command). Or... should we make an interace for jUnit tests "applet-friendly" or=20 such? I think the issue to manage here is close to a documentation/build=20 issue: it needs to be documented what is applet friendly and what is=20 not, and this has to be documented at least on a class-basis, cascading=20= through dependencies). Would there be a better approach than just=20 attacking unit-tests for this ? How much "unfriendly" to developers would this be ? I typically fear a=20= complete refusal: "This collection is not applet-friendly, period,=20 don't bother me with that..." Paul On Mercredi, d=E9ce 18, 2002, at 01:27 Europe/Brussels, Rodney Waldhoff=20= wrote: > Pressure from applet-oriented clients (like you) is one good way to > address this. Perhaps adding a some sort of unit testing framework = for > running regular Junit tests in a "secured" mode would be another. I'd=20= > be > willing to experiment with the latter if anyone else would like to > collaborate.