db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Clute, Andrew" <Andrew.Cl...@osn.state.oh.us>
Subject RE: Feature Proposal: Bytecode generated Proxies
Date Thu, 17 Mar 2005 19:19:10 GMT
Thanks for the feedback.

The last time I looked (at 3.0 RC1 stage), Gavin and the boys could only
offer field level interception for proxies if you instrumented your
classes. Their CGLIB generated proxies were still just method-level.

One of things that I forgot to mention in my previous post was that if
we were to move to CGLIB generated proxies for all, it would remove the
necessity to do conditional builds for JDK1.2 (to interject Proxy stuff
for pre-JDK Proxies) -- everything could be built with a common
infrastructure.

I guess that was a point I didn't make clear as well -- CGLIB proxies
are already being used for JDK1.2 -- why not just extend that for
everyone, and get the added benefit of allowing proxies that do not have
to be interface-backed?

I agree that there is a whole lot of interesting stuff that can be done
with bytecode munging, especially in state tracking (similar to what
Jboss does with JBossCache). 

My initial thought was that something like extending CGLIB for all
proxies was of the scope that could be included in 1.0.3 (I am assuming
there will another maintenance release), and additional facilities to
manage bytecode manipulation could be included in the MAIN line.

Thanks

-Andrew



-----Original Message-----
From: Brian McCallister [mailto:brianm@apache.org] 
Sent: Thursday, March 17, 2005 11:56 AM
To: OJB Developers List
Subject: Re: Feature Proposal: Bytecode generated Proxies

I'd actually like to go much further than bytecode proxies replacing jdk
proxies, I'd like to move state tracking etc fully to the instance via
bytcode munging and not have to track it externally. This has the nice
side effect of letting transactional object get garbage collected if
memory gets low (so you can stream through them for example).

IIRC Chris added field interception capabilities to cglib a while back
(at the request, of, erm, *cough* hibernate *cough*). I'd be more in
favor of using (AspectWerks) AWProxy except for its licensing (grr) as
it is much easier to work with, and provides for much more naturally
expressed code. I doubt Jonas and company are interested in re-licensing
it, though. Another option on that is to look at ASM directly -- I
recall hearing that they were going to bundle up support for most of the
common use cases, proxying/interception being the #1 use case.

Aside from those details, I wholly agree with you that we should do
this. I also think we should proxy collections and references by default
instead of nulling them by default

-Brian

On Mar 17, 2005, at 11:41 AM, Clute, Andrew wrote:

> In my everyday application, I am starting to see some issues where 
> restoring graphs that contain references to other graphs is slowing us

> down. We make extensive use of Collection Proxies, but make minimal 
> use of Reference Proxies (1 class is proxy-enabled out of about 200 
> domain
> objects) -- due mostly to the overhead of maintaining Interfaces for 
> the objects.
>
> I believe I am not alone in this case. As more and more people start 
> to move their existing code-bases over to an O/R mapping system, they 
> are going to face a similar scenario. As such, I would like to propose

> the addition of byte-code generated Proxies. This would allow for the 
> returning of true 'flat' objects, and delaying the walking of graphs 
> until needed. There has been talk before of this, but most of that has

> died in the trenches. I would like to pick this back up and get this 
> feature implemented into OJB.
>
> So, what exactly are we talking about?
> Adding the ability for users to specify reference proxies for classes 
> that are not backed by an interface. The proxies themselves will be 
> generated via a bytecode library (most notably CGLIB).
>
> There are several points to consider with this, and I am going to try 
> to hit them all (in no particular order)
>
> 1) What are the downsides to doing this? If the goal is give a drop-in

> replacement to the JDK-generated proxies based on interfaces, then 
> none.
> They would work the exact same way. They can use the same 
> InvocationHandler stack (IndirectionHandler) and they still do 
> method-interception. Very little, if any, user code would need to be 
> changed to take advantage.
>
> Libraries like CGLIB only do method-level interception, so the 
> generated classes do not contain any of the same fields -- so doing 
> field introspection would break on the proxies. While this seems like 
> a pretty big "gotcha", the Proxies currently being used by OJB (JDK 
> produced) have the same constraint. So, no new issues are being 
> introduced, just old ones not being addressed
>
> 2) One could go a route where the generation of Proxies could be an 
> externalized, plugged-in process, and thus allow different bytecode 
> libraries the ability to generate the proxy. This is probably a good 
> idea in the long run, but not necessary for a first release of this. 
> By sticking to one library, an effective replacement solution can be 
> introduced almost immediately.
>
> 3) I teeter back and forth on this: You could even go so far as to 
> have all Proxies generated by CGLIB, interface-backed and 
> auto-generated ones. You could remove the JDK versions and have one 
> consistent proxy generation. I don't know exactly what I think about 
> this yet, as there might be some benefits to having JDK-produced ones 
> for interface-backed, but I don't know yet.
>
> 4) How it affects configuration (I am open to all kinds of
> suggestions):
> My initial thought is to keep the current pattern in place of allowing

> ClassDescriptors to set a proxy-class that is secondary to 
> ReferenceDescriptors that specify "proxy=true".
>
> My initial thought is to follow the pattern for the atuo-XXX fields 
> and add additional values for the proxy setting in
ReferenceDescriptors.
> Whereas the current values are "true", "false", the new values would 
> be "auto-gen", "interface", "none", "true" (interface) and false
("none").
>
> On the ClassDescriptors, the only option is to specify the 
> proxy-class, and in that case a user could continue to specify an 
> interface, or they could either specify the same class as the proxy 
> (the way Hibernate does it), or the setting could look for a key word,

> like "auto-gen".
>
>
> I currently have a working prototype of this (without the 
> configuration right now), and have not seen any significant issues.
>
> I would love to get any and all feedback about the possibility of 
> adding this to OJB (which version would be best?)
>
> Thank you for your time,
>
> -Andrew
>
>


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




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


Mime
View raw message