Guice and Commons Proxy?

[James Carman]

Would the Google Guice project be interested in using Apache Commons
Proxy (http://commons.apache.org/proxy/)? ACP basically allows you to
create dynamic proxy objects using a standardized API without worrying
about the underlying dynamic class library specifics. Right now, it
includes support for JDK proxies, Javassist, and CGLIB (no ASM yet,
but I imagine it could be done).

[Brian Pontarelli]

I'm not a big fan of most of the commons libraries. They tend to pull
in a number of extra dependencies and most aren't JDK 5 converted yet.
Plus, this would only be useful if the CGLIB dependency was opened up
rather than pre-packaged. This commons library might be different, but
my guess is that it still depends on commons-lang, commons-logging and
maybe one more. I don't think that bundling CGLIB inside the JAR is a
bad thing personally.

-bp

[James Carman]

Take a look at the dependencies page for Commons Proxy:

http://commons.apache.org/proxy/dependencies.html

Nothing is required other than the JDK. Now, this is a bit
misleading. If you want to use any of the optional libraries (CGLIB
and Javassist), then you of course have to include their dependencies.
Commons Proxy manages its dependencies using Maven2, so it picks up
whatever CGLIB and Javassist say they need.

[Brian Pontarelli]

Wow, somewhat unheard of for the commons libraries ;)

[James Carman]

Hey hey hey. Easy now. You're talking to one of the Apache Commons
PMC members! :)

Apache Commons does try to minimize the dependence on other projects
as much as possible. We even copy code from one project to another to
avoid adding a dependency, sometimes (especially if the code needed is
small). Trust me, sometimes it seems like quite a hindrance on us
because of all of the care we have to take to be backwards compatible,
binary compatible, etc. A lot of folks don't think about (I didn't)
what it takes to maintain a library when so many folks depend on it.
It's not easy.

[limpb...@gmail.com]

Honest question: how would this make our code better?

[Gili Tzabari]

I've only personally played around with JDK proxies, ASM and CGLIB
(so no ideas about the other ones). Personally I would advocate using
any API that simplifies the code and has good documentation. For
example, last time I checked CGLIB had horrible (practically
nonexistent) documentation and ASM wasn't the easiest thing in the world
to use (though the documentation was a lot better). If Apache Commons
Proxy improves on both fronts (usability, documentation) it would be
worth using in my view. I'm not sure whether it does though or how well
it is maintained.

Gili

[Stuart McCulloch]

2008/10/21 Gili Tzabari <gili.t...@gmail.com>

   I've only personally played around with JDK proxies, ASM and CGLIB
(so no ideas about the other ones). Personally I would advocate using
any API that simplifies the code and has good documentation. For
example, last time I checked CGLIB had horrible (practically
nonexistent) documentation and ASM wasn't the easiest thing in the world
to use (though the documentation was a lot better). If Apache Commons
Proxy improves on both fronts (usability, documentation) it would be
worth using in my view.

cglib is currently an internal dependency that's hidden from users
so using commons proxy would not change the public API, except
to let them choose which proxy to use - it would also add a level of
indirection internally, and may make Guice slightly harder to setup
(as the proxy libraries would then be managed externally)

so imho this wouldn't be a huge gain, compared to other features
on the issues list (and I wouldn't want it to delay the next release)

I'm not sure whether it does though or how well it is maintained.

well, I'm sure James can answer that ;) I did notice that it still has
a dependency on cglib 2.1_3, which has a race condition - but I
assume cglib 2.2 can be dropped in without any recompilation
 

Gili

je...@swank.ca wrote:
> On Oct 16, 10:42 pm, "James Carman" <jwcar...@gmail.com> wrote:
>
>> Would the Google Guice project be interested in using Apache Commons
>> Proxy (http://commons.apache.org/proxy/)? ACP basically allows you to
>> create dynamic proxy objects using a standardized API without worrying
>> about the underlying dynamic class library specifics.  Right now, it
>> includes support for JDK proxies, Javassist, and CGLIB (no ASM yet,
>> but I imagine it could be done).
>>
>
> Honest question: how would this make our code better?
> >
>
>

--
Cheers, Stuart

[James Carman]

Commons Proxy would definitely help abstract away practically all of
the proxying logic from Guice (you'd still have to decide what to pass
into the API, obviously). It has support for aopalliance interceptors
out of the box, so you wouldn't have to jump through any hoops to get
that working. If a Guice project only uses interfaces for their
"services", then they could just use Commons Proxy with no
dependencies and just use JDK proxies (it'd be slower, but if speed
isn't an issue...).

I wrote Commons Proxy with dependency injection in mind. While
working on the HiveMind project, I really hated doing all of that
Javassist programming necessary for writing your own interceptors and
stuff. I decided to write the logic one time and allow "hooks" for
the proxying logic instead. Once I abstracted stuff out, I decided to
start implementing it using different dynamic proxy libraries. As for
the maintenance, it really hasn't needed much maintenance because
there aren't that many folks using it, yet. I would imagine that it's
partly because nobody really knows about it (that's what I keep
telling myself so that I don't think all my hard work was for nothing
:).

[James Carman]

On Tue, Oct 21, 2008 at 12:51 AM, Stuart McCulloch <mcc...@gmail.com> wrote:
> 2008/10/21 Gili Tzabari <gili.t...@gmail.com>

>
> cglib is currently an internal dependency that's hidden from users
> so using commons proxy would not change the public API, except
> to let them choose which proxy to use - it would also add a level of
> indirection internally, and may make Guice slightly harder to setup
> (as the proxy libraries would then be managed externally)

I don't know if it would make it harder to set up. You could pick a
default ProxyFactory implementation (CGLIB perhaps) and if users want
to override that (with Javassist perhaps) then they could. It
wouldn't be need to be something your users think about if they don't
want to.

>
> so imho this wouldn't be a huge gain, compared to other features
> on the issues list (and I wouldn't want it to delay the next release)
>

You're probably right. The big gain here would be slimming down
Guice's codebase to not need all of that proxying logic. Since it'd
be an internal thing primarily, I would agree that it shouldn't delay
any release. I was just offering it up in case you folks didn't know
about it and it could help your project.

>> I'm not sure whether it does though or how well it is maintained.
>
> well, I'm sure James can answer that ;) I did notice that it still has
> a dependency on cglib 2.1_3, which has a race condition - but I
> assume cglib 2.2 can be dropped in without any recompilation
>

I already replied to the maintenance question. As far as that CGLIB
dependency, I was unaware of the race condition and I would imagine
that it could be swapped out with no issues. If you're using Maven
and there is a newer version of CGLIB already declared in your pom, it
will just use that. I need to release a new version of Commons Proxy
anyway, I'll make sure the dependency is updated. If you want, you
can file a JIRA issue (so that it doesn't look like I file all my own
JIRAs :). I may "borrow" some of Guice's ASM code to provide an
ASM-based implementation of ProxyFactory. Would anyone care to help
implement it?

[James Carman]

On Tue, Oct 21, 2008 at 6:19 AM, James Carman <jwca...@gmail.com> wrote:
>> well, I'm sure James can answer that ;) I did notice that it still has
>> a dependency on cglib 2.1_3, which has a race condition - but I
>> assume cglib 2.2 can be dropped in without any recompilation

Anyone know where I can get cglib 2.2.x via maven2? It's not in the
main repository. It was released earlier this year, so it shouldn't
be a synchronization issue.

[tzwoenn]

As far as I know, it is still not available in one of the relevant
repositories, so decided some months ago to upload it to my own:
http://maven.kamalook.de/

BR, Sven

On Oct 21, 12:32 pm, "James Carman" <jwcar...@gmail.com> wrote:

[James Carman]

Ok, thanks. I didn't know if perhaps they changed their groupId or
something and I was unaware. Their site doesn't have any
maven-specific instructions. I think I might wait for it to make it
to the main repository before I upgrade my dependency declaration. It
can always be overridden.

[Dhanji R. Prasanna]

This is really a non-issue with Guice. There is no requirement for an alternate proxy API. Perhaps Hibernate could benefit from something like this, they already have their own abstraction API for javassist and cglib.

As has been stated before, cglib is *not* an external dependency of Guice.

Dhanji.

[James Carman]

I didn't say it was a requirement. However, if it can slim down the
codebase, it could be beneficial.

[Bob Lee]

The cglib impl is pretty tight already and it works well, so this probably isn't worth it. Also, there's no telling whether the proxy API can support our usage. My guess is cglib and ASM (which is used by cglib anyway) are the only impls that can, at least w/o a significant rewrite.

Bob

[James Carman]

What specific usage scenarios do you have that you think Proxy might
not support? If there's something that we have overlooked, we should
improve our library (even if guice doesn't want to use it). Have you
looked at the Commons Proxy API?

[Bob Lee]

On Tue, Oct 21, 2008 at 7:42 AM, James Carman <jwca...@gmail.com> wrote:

What specific usage scenarios do you have that you think Proxy might
not support?  If there's something that we have overlooked, we should
improve our library (even if guice doesn't want to use it).  Have you
looked at the Commons Proxy API?

I haven't, but the Guice code is fairly simple if you want to check.

Bob

[James Carman]

I'm doing that now. Again, I'm not trying to cram Proxy down Guice's
throat or anything. I just thought it might be helpful. I know how
much I hated writing proxying logic code manually and hopefully
Commons Proxy's abstraction is intuitive enough to make it easy on
folks. If you guys do decide to use it and run into any problems,
just let us know via the d...@commons.apache.org mailing list (or you
can contact me directly if you have something that needs answering
quickly :).

[Bob Lee]

Thanks for the suggestion and the support.

Bob