commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Spies, Brennan" <Brennan.Sp...@ejgallo.com>
Subject RE: [ANNOUNCE] Release of Commons Proxy 1.0
Date Fri, 07 Mar 2008 00:37:01 GMT
James,

I can see the argument against public interfaces (a similar argument was made
for Struts ActionForms et al. and there have been some regrets on the part of
some over not being able to add methods to JDK Collection interfaces), but it
seems to me that you are trading one disadvantage for others. By forcing
implementations to extend a concrete class, you also force them to inherit
any shared state and method implementations (unless explicitly overridden).
This may have undesired consequences if you need to change the ProxyFactory
class itself. I've been burned by this myself.

But I don't want to belabor the point since the decision has already been
made...

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 2:18 PM
To: Jakarta Commons Users List
Subject: Re: [ANNOUNCE] Release of Commons Proxy 1.0

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


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


Mime
View raw message