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