Return-Path: Delivered-To: apmail-jakarta-commons-dev-archive@apache.org Received: (qmail 50027 invoked from network); 25 Jul 2002 21:08:17 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 25 Jul 2002 21:08:17 -0000 Received: (qmail 2496 invoked by uid 97); 25 Jul 2002 21:08:39 -0000 Delivered-To: qmlist-jakarta-archive-commons-dev@jakarta.apache.org Received: (qmail 2470 invoked by uid 97); 25 Jul 2002 21:08:38 -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 2454 invoked by uid 98); 25 Jul 2002 21:08:37 -0000 X-Antivirus: nagoya (v4198 created Apr 24 2002) X-Authentication-Warning: costinm.sfo.covalent.net: costin owned process doing -bs Date: Thu, 25 Jul 2002 14:05:42 -0700 (PDT) From: costinm@covalent.net X-X-Sender: costin@costinm.sfo.covalent.net To: Jakarta Commons Developers List , Subject: RE: [Logging] more issues with stack reading In-Reply-To: <000e01c2340e$45445d90$ac00a8c0@Gabriel> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 Thu, 25 Jul 2002, Berin Loritsch wrote: > > Of course Tomcat exposes API - it is intended for people > > extending tomcat. Realms, loggers, valves, etc. And also the > > embeding API used by all who include tomcat in their products. > > I learned something new today. :) I would have assumed that anyone using tomcat noticed the server.xml and all the 'Interceptor' 'Realm', 'Listener', Logger, etc. Each corresponds to an interface - which has been frozen and stable since 3.3 and 4.0 were released ( in reasonable limits, of course :-). The plan for 5.0 is to continue the support for the existing interfaces that we expose. > Java Management eXtensions designed purpose is to expose management > functionality for servers. The fact that it can be used for > configuration is either a side benefit, or a bastardization of the > spec--depending on your view (I know people on both sides of the > coin, and I have no opinion yet). I don't think 'for servers' is included in the spec. Its purpose AFAIK is to standardise the management of java applications ( just like SNMP can be used for arbitrary applications - from routers to databases ). 'Configuration' ( and runtime configuration ) is the core piece of 'management'. > If a function is available via the wrapper, it should be available > to all wrappers. That means the user will view it as being Commons > Logging. If the Logger exposes a JMX view - the user will view all the capabilities of the specific logger implementation. Think of a Realm - while all authenticators share the same interface, a database realm will have a quite different set of attributes to configure than a text realm. Costin -- To unsubscribe, e-mail: For additional commands, e-mail: