Mailing-List: contact user-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Users List" <user@commons.apache.org>
Received-SPF: neutral (athena.apache.org: local policy)
Message-ID: <f2e8eedf0803061418r495b95aex715b3c04df62ad9c@mail.gmail.com>
Date: Thu, 6 Mar 2008 17:18:12 -0500
From: "James Carman" <james@carmanconsulting.com>
Sender: jcarman@carmanconsulting.com
To: "Jakarta Commons Users List" <user@commons.apache.org>
Subject: Re: [ANNOUNCE] Release of Commons Proxy 1.0
In-Reply-To: <f2e8eedf0803061405g7497b5bctde5af3432198b5cd@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <22C5A81B3491F241BF9447DC9C79E24D059B16AA@modmsx011.network.local>
	 <f2e8eedf0803061405g7497b5bctde5af3432198b5cd@mail.gmail.com>

Brennan,

I found the thread where we discussed class vs. interface.  You can see it here:

http://markmail.org/message/t4tzpepzt7aqvocn

James


On 3/6/08, James Carman <james@carmanconsulting.com> wrote:
> Brennan,
>
>  1.  The problem with adding in IProxyFactory isn't the implications on
>  Commons Proxy's code.  It's on client code.  Suppose we introduced
>  IProxyFactory as you suggest and then some project which uses Proxy
>  implements their own brand of proxy factory (asm-based perhaps) by
>  implementing that interface.  Then, if a new method is added to
>  IProxyFactory, their project won't work anymore.  I agree that it
>  should be an interface, but the more experienced folks suggested that
>  I make it a class based on their experiences with these situations
>  (they've been burned before).  From a purist's point of view, yes it
>  should be an interface.
>
>
>  James
>
>  On 3/6/08, Spies, Brennan <Brennan.Spies@ejgallo.com> wrote:
>  >
>  >  James,
>  >
>  >  Actually, I was just being facetious about the first part. Thanks for the
>  >  info, though. Regarding #1, what about creating an interface (e.g.,
>  >  IProxyFactory) and making all the existing classes implement it? This would
>  >  be compatible with any existing code based on the lib. Just a thought.
>  >  Regarding #2, great idea. Most uses of dynamic proxies are a single interface
>  >  with the current ClassLoader.
>  >
>  >  Regards,
>  >
>  >
>  >  Brennan Spies
>  >  Sr. Programmer Analyst
>  >
>  > Shared Application Services
>  >
>  >
>  >  -----Original Message-----
>  >  From: jcarman@carmanconsulting.com [mailto:jcarman@carmanconsulting.com] On
>  >  Behalf Of James Carman
>  >
>  > Sent: Thursday, March 06, 2008 12:33 PM
>  >  To: Jakarta Commons Users List
>  >  Subject: Re: [ANNOUNCE] Release of Commons Proxy 1.0
>  >
>  >  Mr. Spies,
>  >
>  >  Commons Proxy has been around for quite some time.  I proposed the
>  >  project in August 2005.  It graduated to the Commons "proper" just
>  >  last September/October.
>  >
>  >  1.  Originally, ProxyFactory was an interface, but in order to help
>  >  maintain backward compatibility between releases, it was deemed more
>  >  appropriate (if less pure from an OO perspective) to make it a class.
>  >
>  >  2.  Yes, we'll probably cut a 2.0 release in the near future (1.1
>  >  should be out soon that supports serializing the proxies) that has
>  >  been JD5-ized.  Unfortunately, it might not be completely genericized.
>  >   The methods take multiple classes that the proxy should support (one
>  >  of the gripes on HiveMind was that we couldn't support multiple
>  >  "service interfaces").  I might introduce genericized helper methods
>  >  like this:
>  >
>  >  public <T> createDelegatorProxy(ObjectProvider<T> provider, Class<T>
>  >  proxyInterface)
>  >
>  >  That would take care of a good percentage of the use cases.  Most
>  >  folks only use one interface/class for the proxy.
>  >
>  >  I hope Commons Proxy can be of use to you.  If you have any issues or
>  >  questions, feel free to ping the users list.  The traffic might get
>  >  others interested too! :)
>  >
>  >  James
>  >
>  >
>  >  On 3/6/08, Spies, Brennan <Brennan.Spies@ejgallo.com> wrote:
>  >  > Very cool and useful. Kind of funny, because I wrote something about a year
>  >  >  ago almost identical in functionality to the "Delegator" piece (where were
>  >  >  you guys then? <wink>), Javassist and CGLIB implementations included.
>  >  >
>  >  >  Just two questions:
>  >  >
>  >  >  1) Why isn't ProxyFactory an interface? This makes more sense when using
>  >  the
>  >  >  lib, esp. in DI frameworks.
>  >  >
>  >  >  2) I know that Apache Java libs tend to favor compatibility with Java 1.4
>  >  and
>  >  >  earlier, but a lot of these classes/methods look like good candidates for
>  >  >  generics. Has there been any thought given to having a Java 5 version of
>  >  the
>  >  >  lib with these?
>  >  >
>  >  >  Thanks,
>  >  >
>  >  >  Brennan Spies
>  >  >  Sr. Programmer Analyst
>  >  >
>  >  >
>  >  >  -----Original Message-----
>  >  >  From: jcarman@carmanconsulting.com [mailto:jcarman@carmanconsulting.com]
>  >  On
>  >  >  Behalf Of James Carman
>  >  >  Sent: Thursday, March 06, 2008 11:49 AM
>  >  >  To: announcements@commons.apache.org; dev@commons.apache.org;
>  >  >  user@commons.apache.org
>  >  >  Subject: [ANNOUNCE] Release of Commons Proxy 1.0
>  >  >
>  >  >
>  >  > We are pleased to announce the Commons Proxy 1.0 release.  Commons
>  >  >  Proxy makes creating dynamic proxies in Java easy!
>  >  >
>  >  >  Please visit the Commons Proxy site <http://commons.apache.org/proxy>
>  >  >  for more information.
>  >  >
>  >  >  Thank you,
>  >  >
>  >  >  Commons Proxy Development Team
>  >  >
>  >  >
>  >  > ---------------------------------------------------------------------
>  >  >  To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
>  >  >  For additional commands, e-mail: user-help@commons.apache.org
>  >  >
>  >  >
>  >  >  ---------------------------------------------------------------------
>  >  >  To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
>  >  >  For additional commands, e-mail: user-help@commons.apache.org
>  >  >
>  >  >
>  >
>  >  ---------------------------------------------------------------------
>  >  To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
>  >  For additional commands, e-mail: user-help@commons.apache.org
>  >
>  >
>  >
>  >  ---------------------------------------------------------------------
>  >  To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
>  >  For additional commands, e-mail: user-help@commons.apache.org
>  >
>  >
>

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org