Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Received-SPF: pass (asf.osuosl.org: local policy)
From: "James Carman" <james@carmanconsulting.com>
To: "'Jakarta Commons Developers List'" <commons-dev@jakarta.apache.org>
Subject: RE: [proxy] Moving Proxy to Commons Proper
Date: Sun, 16 Oct 2005 10:03:22 -0400
Message-ID: <000201c5d25a$600afe70$6401a8c0@CARMANI9300>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
In-Reply-To: <43524291.4050409@j-hohwiller.de>
Thread-Index: AcXSSjWulrjseYjFTFiLVhoC4ClP8AAD9f+g

I have implemented what I was talking about (using our own interfaces =
and
providing bridge/adapter implementations).  Do you guys want me to check =
it
in so that you can see what I mean?  Basically, I introduced a few new
interfaces (Invoker, InvocationInterceptor, and Invocation) and made
ProxyFactory dependent upon those rather than the AOP Alliance stuff and =
the
InvocationHandler (in the JDK).

-----Original Message-----
From: Joerg Hohwiller [mailto:joerg@j-hohwiller.de]=20
Sent: Sunday, October 16, 2005 8:08 AM
To: Jakarta Commons Developers List
Subject: Re: [proxy] Moving Proxy to Commons Proper

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

James Carman wrote:
> Stephen,
Hi there,

just to give some feedback from me...

In my oppinion commons-proxy is very usefull already as is. So I
want to agree with the initial idea of this thread and would also like =
to
see it in proper.
>=20
> 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:
>=20
> 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[] =3D=3D "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!
>=20
> 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?
I am currently active on commons-logging. We want to extend the API of =
the
logger. The problem is that extending the existing interface (Log) is =
not a
good
idea, because it is already implemented by third-party code that we can =
not
control. So if we add new methods to the interface, we will break
dependencies.
So we expierence some difficulties in realizing the proposal, even =
though it
is
still possible without breaking dependencies.
The same issue is also causing pain in log4j 1.2 -> 1.3 where the =
intention
was
to prepare for removing legacy stuff in further releases.
So I think Stephen wanted to say that you should think deep about
ProxyFactory
and consider if there could be use-cases in the future that may need to
change
the interface in any way? There we discussions about the fact that what
commons-proxy does is already done by others. It may help to have a look
there and consolidate the ideas to have a stable API for the future.
I personally think your usage and dependency on AOP-Al. is good and not =
a
problem, but removing dependencies is never a bad thing. Anyways AOP-Al.
aims to
be THE API for that issue and for me it does not make sense to =
encapsulate
this
API. Isn't the idea that you have an AOP-Al. compatible implementation =
and
can
pass those instances directly to commons-proxy?
But I am maybe not deep enough into commons-proxy to see exactly what =
you
pointed out.
>=20
> 3.  Will most users have to write their own code implementing an=20
> interface defining in [proxy], or can they just used the existing=20
> 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."
mhm. Actually I can not see the problem about commons-proxy beeing a =
wrong
animal here... logging has dependencies on various native-logger
implementations. They are all optional but I think this is almost the =
same
about
commons-proxy.
You might consider to spilt some of the code into sub-projects. Then you =
can
have the commons-proxy core with almost no dependencies and addintional
sub-projects for cglib stuff, javassist stuff, and the cacho stuff.
This will be very conform with the maven philosophy of projects and
dependencies.
The disadvantage is that by default you will not produce a single jar as
artifact by default. Anyways you can still provide this if you want.
>=20
> James
Regards
  J=F6rg

> -----Original Message-----
> From: Stephen Colebourne [mailto:scolebourne@btopenworld.com]=20
> Sent: Saturday, October 15, 2005 8:08 AM
> To: Jakarta Commons Developers List
> Subject: Re: [proxy] Moving Proxy to Commons Proper
>=20
> James Carman wrote:
>=20
>>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.
>=20
> Maybe
>=20
>>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
>=20
> if
>=20
>>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.
>=20
>=20
> I took a look this morning, and also thought it could be quite useful, =

> and I could follow reasonably well what was going on.
>=20
> 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=20
> can't change released interfaces
>=20
> The more fundamental question however, is whether this is a true =
commons=20
> component. The sheer number of dependencies is a real question. Now=20
> while a lot are probably optional, some will not be.
>=20
> This component looks rather like a framework to me, although a very =
low=20
> level framework. Commons does have other components that have =
interfaces=20
> and plugin points, but doesn't this one go further than we've had=20
> before? Will most users have to write their own code implementing an=20
> interface defining in [proxy], or can they just used the existing=20
> implementations?
>=20
> Stephen
>=20
>=20
>=20
>>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
>=20
> the
>=20
>>way too!=20
>>
>>=20
>>
>>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
>=20
> make
>=20
>>the API a lot uglier IMHO.  I liked the var-args feature for =
specifying
>=20
> the
>=20
>>interfaces/classes that the proxy should support and I would rather =
use
>=20
> the
>=20
>>core JDK Executor class rather than the one from the "concurrent" API. =
 Oh
>>well.
>>
>>=20
>>
>>James
>>
>>=20
>>
>>-----Original Message-----
>>From: robert burrell donkin [mailto:rdonkin@apache.org]=20
>>Sent: Saturday, October 15, 2005 6:28 AM
>>To: Jakarta Commons Developers List
>>Subject: Re: [VOTE] Moving Proxy to Commons Proper
>>
>>=20
>>
>>hi james
>>
>>=20
>>
>>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.
>>
>>=20
>>
>>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.
>>
>>
>>=20
>>
>>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.=20
>>
>>=20
>>
>>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.
>>
>>=20
>>
>>- robert
>>
>>
>=20
>=20
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>=20
>=20
>=20
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>=20
>=20

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDUkKRmPuec2Dcv/8RArfbAJ0TfUd0D8Bp5HtRuLD0lCmQz8kK9gCfXbEh
vncqXCrQ5E34qhEhq5qlkeA=3D
=3DbldL
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
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