db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Dudziak <tom...@gmail.com>
Subject Re: ProxyHelper -- should it remain static?
Date Mon, 28 Mar 2005 18:46:22 GMT
> However, ProxyHelper poises a different situation. All of the methods on
> it are static, and are used in a variety of places where there exists no
> reference to configuration information. In the past this was not an
> issue because there was one, and only one, way to satisfy these methods.
> But with a pluggable structure, these methods now need to be delegated
> to the corresponding ReferenceProxyFactory -- the method to implement
> isOjbProxy() different for JDK versus CGLIB, the work to get the
> IndirectionHandler is different, etc.
> 
> One way to go about it would be to completely scrap ProxyHelper and have
> the references to it refactored to get a reference to the
> ReferfenceProxyFactory and determine it that way:
> 
>  myOjb.getProxyFactory().getReferenceProxyFactory().getRealObject(obj);

Why do you need the two indirections (proxy factory and reference
proxy factory) ?

> This works well in most cases, except the ones where the use of
> ProxyHelper is completely disconnected from the rest of the system --
> there are no references to a PersistenceBroker, or OJB, or any
> configuration information to be able to walk to the
> ReferenceProxyFactory. If the goal is to get rid of all static
> instances, this is the right way of doing it, and a pattern will need to
> be formulated to allow these 'rogue' cases access to that information.

Do you have an example of such a rogue case ? Are there places in the
current OJB (1.1) ?

> The way that I have implemented it, and think might be the cleaner way,
> is to add a static OJB instance variable on ProxyHelper that is injected
> when the OJB is configured. Then all the ProxyHelper methods that need
> to be are refactored to get the ReferenceProxyFactory to make the call
> (see code above). This way the ProxyHelper API is maintained, and there
> is still a static way to access these methods. I admit It is not ideal
> in a world where everything is managed by an IoC container. At the same
> time I don't think that is appropriate to inject references in places
> that truly need the functions that ProxyHelper provide, but would only
> have them to be able to satisfy this pattern.
> 
> Thoughts on this?

The problem with static is that you cannot get rid of the loaded
classes once they've been loaded. This can be quite troublesome, e.g.
unit-testing the XDoclet module is really a pain because XDoclet
itself uses static stuff extensively so I have to use a clean class
loader for each and every one of the 850+ unit tests which leads to a
total running time of ~30 min for a run of all tests. Also using OJB
within an IoC context (e.g. Spring) is much more difficult for the
same reasons.

The general goal in OJB 1.1 is to get rid of static completely (except
for the LockMap AFAIK). If need be, then the OJB or PC object can
always be stored away in ThreadLocal or the session or application
context (for web apps).

Also, generally I think applications rarely need to determine whether
an object is a proxy or the real thing (I at least never had to know
yet), so if within OJB all static usages can be replaced by accesses
to the OJB object, then IMO we should use this way. I don't think that
maintaining the API of ProxyHelper is really necessary, especially
because it never was an endorsed API. And the app should be able to
have an OJB object available anyway.

Tom

---------------------------------------------------------------------
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