Mailing-List: contact ojb-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "OJB Developers List" <ojb-dev@db.apache.org>
Received-SPF: pass (hermes.apache.org: local policy)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: UPDATE: (was: Feature Proposal: Bytecode generated Proxies)
Date: Mon, 21 Mar 2005 10:45:27 -0500
Message-ID: <316E5B943771D311BAC500805FD7A07804089D64@MAIL.osn.state.oh.us>
Thread-Topic: UPDATE: (was: Feature Proposal: Bytecode generated Proxies)
Thread-Index: AcUr5I+buFhFc9ZaTs26wttzaqpqXQAC49tQAI72DHA=
From: "Clute, Andrew" <Andrew.Clute@osn.state.oh.us>
To: "OJB Developers List" <ojb-dev@db.apache.org>

I have finished the changes to make all dynamic proxies generated by
CGLIB. In the limited testing that I have done, proxy generation using
CGLIB seems to be in the order of 30-50% faster than JDK proxies
(assuming you cache the initial CGLIB Factory). The code is very
straight forward, and works great!

However, at this point I would not recommend introducing it to the 1.0.X
line. :(

While it *should* be completely transparent to the user which proxy
system is being used, there is one vital spot where it does become
apparent: the new generated proxies *are not* of type
java.lang.reflect.Proxy. This could be troublesome for people who have
infrastructure depending on the notion that those objects are of type
Proxy. This change could unknowingly break that code.

So, while this has been very helpful as an R&D project, I think the only
right away do to this is as we have said before, introduce it into the
HEAD as a pluggable interface, with a common base Proxy implementation
that all Proxy plug-ins would generate (like OJBProxy). That way, the
current JDK based implementation could be maintained, and probably be
the default.

-Andrew


=20

> -----Original Message-----
> From: Clute, Andrew [mailto:Andrew.Clute@osn.state.oh.us]=20
> Sent: Friday, March 18, 2005 2:31 PM
> To: OJB Developers List
> Subject: RE: Feature Proposal: Bytecode generated Proxies
>=20
> =20
>=20
>=20
> > > There are several points to consider with this, and I am
> > going to try
> > > to hit them all (in no particular order)
> > > =20
> > > 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.
> >=20
> > if this feature is planned for 1.0.x we should introduce as less=20
> > incompatibilities as possible.
>=20
>=20
> I agree completely. I think the plan of a drop-in replacement=20
> that is invisable to the user for 1.0.X line and a=20
> configurable strategy for 1.X is wise. I could see waiting=20
> for 1.1 to introduce any of this, but the timeline for that=20
> is so unknown, and I think this could be useful in the=20
> immediate future.
>=20
>=20
>=20
> > is it really necessary to define the proxy-generator on=20
> > class-descriptor level ? what's the benefit of having a=20
> bytecode proxy=20
> > on one class and a jdk-proxy on the other class. imo we=20
> could define a=20
> > global proxy-generator to generate the proxies for classes with=20
> > proxy=3D'dynamic'
> > and for classes with proxy =3D 'myclass' it's up to the user.
> >=20
>=20
>=20
> I agree completely, and eventually worked myself to that way.=20
> My current
> implementation of this only uses CGLIB to generate proxies.=20
> JDK proxies
> are no longer used. There are no new configuration settings. Setting
> either 'dynamic' at the ClassDescriptor, or 'proxy=3Dtrue' at the
> ReferenceDescriptor generates a CGLIB-backed Proxy based on the
> itemClass, regardless of what interfaces it implements (since the new
> proxy is guaranteed to implement them all since it is a=20
> subclass of the
> itemClass).
>=20
> Thanks for all the feedback! I really do appreciate it. My hope is to
> have something done for the 1.0.X line by early next week that can be
> reviewed, and then I will start work on design for the 1.X lines
> pluggable model.
>=20
> -Andrew
>=20
>=20
>=20
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-dev-help@db.apache.org
>=20
>=20
>=20

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