db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jakob Braeuchi <jbraeu...@gmx.ch>
Subject Re: ProxyHelper -- should it remain static?
Date Mon, 28 Mar 2005 20:21:07 GMT
hi tom,

what do think is the best way to get rid of the static QueryFactory 
methods ? these methods are used in all of our testcases and also by the 
users of ojb.

myOjb.getQueryFactory().newQuery(...) would be the right thing, but i 
think we can't break all the user's code :(

jakob

Thomas Dudziak schrieb:
>>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
> 
> 

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