commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Carman" <ja...@carmanconsulting.com>
Subject RE: [proxy] Moving Proxy to Commons Proper
Date Sat, 15 Oct 2005 13:42:04 GMT
Stephen,

Thank you for taking the time to dig into the code and poke around a bit.
I'll try to address your questions/concerns here:

1.  Logging interceptor using Javassist - it didn't really use Javassist,
but a method that was in JavassistUtils which returns the "java class name"
of a class (java class name of Object[] == "java.lang.Object[]").  So, I
moved that method to ProxyUtils.  That was a good catch.  Thanks!  It would
be silly to introduce a dependency on Javassist just to log method
invocations!

2.  The ProxyFactory interface could limit you in the future - I don't
understand what you mean here.  Do you mean because I depend on interfaces
that I don't have control over (AOP Alliance's MethodInterceptor and the
JDK's InvocationHandler)?  If so, then I suppose that I could come up with
my own interfaces and provide "bridge" or "adapter" classes to close the gap
(I think someone suggested this before, but I forgot about it).  This would
actually remove *all* required dependencies (other than JDK1.3+) from
[proxy].  All other dependencies are optional.  If you want to use CGLIB or
Javassist to create your proxies, you can just include them in your
classpath.  Maybe I could provide a getInstance() method on ProxyFactory
which tries to discover which options are available (Javassist, then CGLIB,
then default to JDK proxies; override using system propery).  What would you
think about these changes?

3.  Will most users have to write their own code implementing an 
interface defining in [proxy], or can they just used the existing 
implementations? - Well, users could use existing AOP Alliance method
interceptors (like the ones included with Spring, for example).  Other than
that, if you just want to create proxies for your classes/objects, you don't
have to implement anything from [proxy].  The core object providers
(BeanProvider or ConstantProvider) would provide all you need to "plug in."

James
-----Original Message-----
From: Stephen Colebourne [mailto:scolebourne@btopenworld.com] 
Sent: Saturday, October 15, 2005 8:08 AM
To: Jakarta Commons Developers List
Subject: Re: [proxy] Moving Proxy to Commons Proper

James Carman wrote:
> Thank you for your feedback (finally somebody said *something*).  I made
> this a vote based on the instructions found at
> http://wiki.apache.org/jakarta-commons/MovingFromSandboxToProperSVN.
Maybe
> we should update that WIKI to suggest making a proposal first and then
> starting a vote if there are no objections.  I really just wanted to know
if
> there were any technical objections to having proxy move into the commons
> proper so that I could fix the problems.  I would really like to see this
> become a full-fledged commons component.  I think it's a very useful idea
> and a pretty intuitive API.

I took a look this morning, and also thought it could be quite useful, 
and I could follow reasonably well what was going on.

Technically, I remember a couple of oddities, although there may be more:
- the Logging interceptor used Javassist, an odd dependency
- the core ProxyFactory interface could limit you in the future, as you 
can't change released interfaces

The more fundamental question however, is whether this is a true commons 
component. The sheer number of dependencies is a real question. Now 
while a lot are probably optional, some will not be.

This component looks rather like a framework to me, although a very low 
level framework. Commons does have other components that have interfaces 
and plugin points, but doesn't this one go further than we've had 
before? Will most users have to write their own code implementing an 
interface defining in [proxy], or can they just used the existing 
implementations?

Stephen


> As for your suggestion to cut a release candidate now, I like it.  I do
> think that I need some simple tutorials/examples on the site before it's
> ready for a real release, so I'll try to take care of that sometime soon.
> Then, I'll cut a release candidate, per your suggestion.  I will try to
> follow the directions found at
> http://jakarta.apache.org/commons/releases/prepare.html to prepare the
> release candidate, but I'm probably bound to make mistakes as I'm new to
> this project management stuff.  I'll probably have a few questions along
the
> way too! 
> 
>  
> 
> Also, I would still like to hear if anyone else has any suggestions for
> things that I need to take care of before they would consider it ready for
> release.  Resolving the 1.5 dependency helped of course, even if it did
make
> the API a lot uglier IMHO.  I liked the var-args feature for specifying
the
> interfaces/classes that the proxy should support and I would rather use
the
> core JDK Executor class rather than the one from the "concurrent" API.  Oh
> well.
> 
>  
> 
> James
> 
>  
> 
> -----Original Message-----
> From: robert burrell donkin [mailto:rdonkin@apache.org] 
> Sent: Saturday, October 15, 2005 6:28 AM
> To: Jakarta Commons Developers List
> Subject: Re: [VOTE] Moving Proxy to Commons Proper
> 
>  
> 
> hi james
> 
>  
> 
> IMO it would be better to make this a proposal. quite often, small
> 
> changes will are needed and discussion required. votes tend to get a
> 
> little confused and lost when that happens. usually, it's a bit cleaner
> 
> to make a proposal then move to a vote when there are no remaining
> 
> objections.
> 
>  
> 
> On Fri, 2005-10-14 at 08:17 -0400, James Carman wrote:
> 
> 
>>All,
> 
> 
>> 
> 
> 
>>Outside projects (currently my Syringe project and the "Crispy" project at
> 
> 
>>sourceforge) are beginning to want to use Commons Proxy, but are finding
> 
> it
> 
> 
>>difficult since it's in the sandbox and no releases are available.  I
> 
> 
>>believe Proxy's API is close to being ready for a release candidate.
> 
> 
>>Currently, I don't have any other bright ideas for it, but I'm open to
> 
> 
>>suggestions.  Moving it to the proper will help us prepare it for an
> 
> 
>>official release.
> 
> 
>  
> 
> being ready for an official release is one of my personal criteria for
> 
> promotion (so that's good). part of being ready is demonstrating to the
> 
> community that the committers know how to cut commons releases. 
> 
>  
> 
> might i suggest that you cut an example release candidate and upload it
> 
> to your apache home directory. not only will this speed the time taken
> 
> to cut the first release (we can spot any problems now rather than
> 
> later) but it will also give us a better idea of where proxy actually is
> 
> right now.
> 
>  
> 
> - robert
> 
> 

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



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


Mime
View raw message