db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Clute, Andrew" <Andrew.Cl...@osn.state.oh.us>
Subject ProxyHelper -- should it remain static?
Date Mon, 28 Mar 2005 15:38:05 GMT
I have finished all of the changes necessary to implement the pluggable
proxy pattern. Both JDK and CGLIB are supported. It seems to work great.
However, there is one design question that I want to get a consensus on
before I finish up the final work, including writing unit tests. The
generation of the Proxies is very straight-forward; there is has been no
issues incorporating it within the new configuration framework. 
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:
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.
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?

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message