Return-Path: Delivered-To: apmail-jakarta-commons-dev-archive@apache.org Received: (qmail 15064 invoked from network); 8 Dec 2002 07:16:30 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 8 Dec 2002 07:16:30 -0000 Received: (qmail 8572 invoked by uid 97); 8 Dec 2002 07:17:42 -0000 Delivered-To: qmlist-jakarta-archive-commons-dev@jakarta.apache.org Received: (qmail 8526 invoked by uid 97); 8 Dec 2002 07:17:41 -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 8514 invoked by uid 98); 8 Dec 2002 07:17:40 -0000 X-Antivirus: nagoya (v4218 created Aug 14 2002) To: commons-dev@jakarta.apache.org X-Injected-Via-Gmane: http://gmane.org/ Path: not-for-mail From: Costin Manolache Subject: [modeler] removing deps ? Date: Sat, 07 Dec 2002 23:09:47 -0800 Lines: 26 Message-ID: NNTP-Posting-Host: 63-203-204-149.dsl.snfc21.pacbell.net Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit X-Trace: main.gmane.org 1039331785 27556 63.203.204.149 (8 Dec 2002 07:16:25 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sun, 8 Dec 2002 07:16:25 +0000 (UTC) User-Agent: KNode/0.7.1 Sender: news X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N It would be reasonably easy to remove the deps of modeler on digester ( use DOM or SAX directly instead ) and beanutils ( we use only a a very small piece ). Our use of introspection will not be exposed to the user and we have some very specific requirements ( as mandated by the spec ), so there's little benefit of using the general purpose beanutils - quite the contrary. Modeler is a very critical piece - it needs to be in the parent loader ( if we want to control tomcat or other apps via JMX and modeler ), and it'll be critical for security. The fewer public APIs it exposes ( besides JMX ) and the fewer classes it drags into the same protection domain - the better it is. We'll not "duplicate" anything - the code to do what we need already exists ( in several forms ), we'll just use it ( adapted to the specific needs ). I don't think it'll be a problem with the duplicated maintainance either - the code we need has been quite stable for a long time and I think people working and using the modeler have enough experience to do maintain this code. Craig ? Remy ? Other people who are interested in modeler ? Costin -- To unsubscribe, e-mail: For additional commands, e-mail: