db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian McCallister <bri...@apache.org>
Subject Re: Feature Proposal: Bytecode generated Proxies
Date Thu, 17 Mar 2005 16:56:07 GMT
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


Mime
View raw message