hi andrew,
Clute, Andrew schrieb:
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.
if this feature is planned for 1.0.x we should introduce as less incompatibilities as possible.
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.
imo we should let the users decide what kind of proxies the like. that's why i think the proxy-generator has to be pluggable.
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").
is it really necessary to define the proxy-generator on class-descriptor level ? what's the benefit of having a bytecode proxy on one class and a jdk-proxy on the other class. imo we could define a global proxy-generator to generate the proxies for classes with proxy='dynamic' and for classes with proxy = 'myclass' it's up to the user.
jakob
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
