Return-Path: Delivered-To: apmail-jakarta-tomcat-dev-archive@apache.org Received: (qmail 92033 invoked from network); 6 Jun 2002 16:55:37 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 6 Jun 2002 16:55:37 -0000 Received: (qmail 28725 invoked by uid 97); 6 Jun 2002 16:55:33 -0000 Delivered-To: qmlist-jakarta-archive-tomcat-dev@jakarta.apache.org Received: (qmail 28707 invoked by uid 97); 6 Jun 2002 16:55:33 -0000 Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Tomcat Developers List" Reply-To: "Tomcat Developers List" Delivered-To: mailing list tomcat-dev@jakarta.apache.org Received: (qmail 28695 invoked by uid 98); 6 Jun 2002 16:55:32 -0000 X-Antivirus: nagoya (v4198 created Apr 24 2002) X-Authentication-Warning: costinm.sfo.covalent.net: costin owned process doing -bs Date: Thu, 6 Jun 2002 09:55:25 -0700 (PDT) From: costinm@covalent.net X-X-Sender: costin@costinm.sfo.covalent.net To: Tomcat Developers List Subject: Re: mx for jk In-Reply-To: <20020606091609.3348.h007.c007.wm@mail.distributopia.com.criticalpath.net> 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, 6 Jun 2002, Christopher K. St. John wrote: > This sounds a bit like o.a.commons.modeler. (modeler > provides code to fill in MBean meta-data based on an external > xml file, see o.a.catalina.mbeans.mbeans-descriptors.xml) > > Is the magic jk code related, a replacement, or just something > completely different? I am well aware of modeler, I mentioned few times I think it is a good solution but not the best ( at least for our use case ) :-) Modeler creates model MBeans, based on a XML config file. This solution uses Dynamic MBeans, using introspection data - at least at the first level. It'll probably use some XML ( or properties file ) similar with modeler, but automatically generated from javadoc tags ( @jmx:attribute, etc ) and source. The big difference is that with model MBeans, the JMX implementation is providing the bridge between JMX callers and the actual managed bean. With dynamic MBeans, our Dynamic proxy gets called and we can save/manipulate the data. If users sets "port" to "8081", we can save this info in our representation of config ( I'll try to use something similar with preferences for <1.4 and preferences in 1.4 ). The result is that we can manage the config file based on what is actually set by user, not on data extracted from the runtime. ( we can also insert the very usefull ${substitution} and many other tricks ). A second difference is that we need to also manage the C components, i.e. provide the same JMX interface for mod_jk. Again, a dynamic mbean is essential for this - it'll probably do some AJP calls in setAttribute(), etc. Costin -- To unsubscribe, e-mail: For additional commands, e-mail: