Return-Path: Delivered-To: apmail-commons-dev-archive@www.apache.org Received: (qmail 1449 invoked from network); 15 Jul 2010 02:22:03 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 15 Jul 2010 02:22:03 -0000 Received: (qmail 61971 invoked by uid 500); 15 Jul 2010 02:22:03 -0000 Delivered-To: apmail-commons-dev-archive@commons.apache.org Received: (qmail 61855 invoked by uid 500); 15 Jul 2010 02:22:02 -0000 Mailing-List: contact dev-help@commons.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Commons Developers List" Delivered-To: mailing list dev@commons.apache.org Received: (qmail 61847 invoked by uid 99); 15 Jul 2010 02:22:02 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 15 Jul 2010 02:22:02 +0000 X-ASF-Spam-Status: No, hits=0.7 required=10.0 tests=RCVD_IN_DNSWL_NONE,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (nike.apache.org: local policy) Received: from [209.85.216.43] (HELO mail-qw0-f43.google.com) (209.85.216.43) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 15 Jul 2010 02:21:55 +0000 Received: by qwd6 with SMTP id 6so70962qwd.30 for ; Wed, 14 Jul 2010 19:21:34 -0700 (PDT) Received: by 10.224.65.147 with SMTP id j19mr10542977qai.189.1279160494134; Wed, 14 Jul 2010 19:21:34 -0700 (PDT) MIME-Version: 1.0 Sender: jcarman@carmanconsulting.com Received: by 10.229.82.15 with HTTP; Wed, 14 Jul 2010 19:21:14 -0700 (PDT) From: James Carman Date: Wed, 14 Jul 2010 22:21:14 -0400 X-Google-Sender-Auth: PndhNAm7zApTRfr3s49Iw-vEllg Message-ID: Subject: [proxy] Changing the API to an interface (AGAIN)... To: Commons Developers List Content-Type: text/plain; charset=ISO-8859-1 X-Virus-Checked: Checked by ClamAV on apache.org All, One of the biggest complaints I've received from folks about the proxy library is that it's not based on interfaces. The main class is the ProxyFactory class and it's a concrete class which implements all proxying logic using JDK proxies. We did this for maintainability (adding stuff to the interface breaks binary compatibility as opposed to adding a method to a concrete superclass with an implementation). I would like to re-structure proxy so that it contains a few modules... 1. Commons Proxy Core - the API itself containing the ProxyFactory *interface* 2. Commons Proxy JDK - the JDK proxies implementation 3. Commons Proxy CGLIB - the CGLIB implementation 4. Commons Proxy Javassist - the Javassist Library With the new paradigm of just bumping major version numbers (and package names) allowing us to break compatibility, I don't think the interface issue is that much of an issue anymore. What do you guys think? Thanks, James --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org For additional commands, e-mail: dev-help@commons.apache.org