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: RE: ProxyHelper -- should it remain static?
Date: Mon, 28 Mar 2005 14:29:15 -0500
Message-ID: <316E5B943771D311BAC500805FD7A078040D9515@MAIL.osn.state.oh.us>
Thread-Topic: ProxyHelper -- should it remain static?
Thread-Index: AcUzx1SW1pZ/yG4JRxq4Azoziiq44wAAkCxg
From: "Clute, Andrew" <Andrew.Clute@osn.state.oh.us>
To: "OJB Developers List" <ojb-dev@db.apache.org>

=20
> > =20
> >=20
> myOjb.getProxyFactory().getReferenceProxyFactory().getRealObject(obj);
>=20
> Why do you need the two indirections (proxy factory and=20
> reference proxy factory) ?

I don't really like it either, especially when in some cases it starts
to look like this:

pb.getConfiguration().getOjb().getProxyFactory().getReferenceProxyFactor
y().getIndirectionHandler(proxy);


To be honest, I made them separate because 1) It was simpler (touched
less points) and 2) To keep Reference proxies and collection proxies
separate -- since configuration for them is separate as well.

Right now I have a base interface named ReferenceProxyFactory that the
implementations extend. I didn't like adding pass through methods on
ProxyFactory to the ReferenceProxyFactory, seemed easier to just get the
reference to the ReferenceProxyFactory. Maybe I can combine ProxyFactory
with the ReferenceProxyFactory into one single ProxyFactory that will
handle all proxy functions (both reference and collection).


>=20
> > This works well in most cases, except the ones where the use of=20
> > ProxyHelper is completely disconnected from the rest of the=20
> system --=20
> > there are no references to a PersistenceBroker, or OJB, or any=20
> > configuration information to be able to walk to the=20
> > ReferenceProxyFactory. If the goal is to get rid of all static=20
> > instances, this is the right way of doing it, and a pattern=20
> will need=20
> > to be formulated to allow these 'rogue' cases access to=20
> that information.
>=20
> Do you have an example of such a rogue case ? Are there=20
> places in the current OJB (1.1) ?


I am in the process of going through right now and listing all these
'rogue' places. But for an immediate example, StatementsForClassImpl has
no apperant connection to configuation information and it uses
ProxyHelper.isNormalOjbProxy().=20


> > Thoughts on this?
>=20
> The problem with static is that you cannot get rid of the=20
> loaded classes once they've been loaded. This can be quite=20
> troublesome, e.g.
> unit-testing the XDoclet module is really a pain because=20
> XDoclet itself uses static stuff extensively so I have to use=20
> a clean class loader for each and every one of the 850+ unit=20
> tests which leads to a total running time of ~30 min for a=20
> run of all tests. Also using OJB within an IoC context (e.g.=20
> Spring) is much more difficult for the same reasons.
>=20
> The general goal in OJB 1.1 is to get rid of static=20
> completely (except for the LockMap AFAIK). If need be, then=20
> the OJB or PC object can always be stored away in ThreadLocal=20
> or the session or application context (for web apps).
>=20
> Also, generally I think applications rarely need to determine=20
> whether an object is a proxy or the real thing (I at least=20
> never had to know yet), so if within OJB all static usages=20
> can be replaced by accesses to the OJB object, then IMO we=20
> should use this way. I don't think that maintaining the API=20
> of ProxyHelper is really necessary, especially because it=20
> never was an endorsed API. And the app should be able to have=20
> an OJB object available anyway.
>=20


Agreed. You have convinced me. I hadn't thought about the classloader
issues, which makes complete sense.

It might be best for me then to refactor all the static references to
ProxyHelper as well to use the OJB, and then deal with the rogue cases
on indiviual basis, once I have a firm grasp on which ones will not
work.

Does this mean that BrokerHelper will be refactored as well? It is one
of the major culprits that uses ProxyHelper statically without any
application references.

Thanks for all the pointers as I get up to speed. My hope is become more
useful to OJB.

-Andrew


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