> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
