You are viewing a plain text version of this content. The canonical link for it is here.
Posted to ojb-dev@db.apache.org by "Clute, Andrew" <An...@osn.state.oh.us> on 2005/03/28 17:38:05 UTC
ProxyHelper -- should it remain static?
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:
myOjb.getProxyFactory().getReferenceProxyFactory().getRealObject(obj);
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?
Thanks,
-Andrew
Re: ProxyHelper -- should it remain static?
Posted by Jakob Braeuchi <jb...@gmx.ch>.
hi andrew,
i'd like to see the ProxyHelper accessible through 'myOJB' wherever
possible. this is about the same as your proposed ProxyFactory access.
imo we should try to get rid of _all_ those static methods. what are
these disconnected methods ?
btw i'm currently trying to refactor the query and it's interfaces. the
QueryFactory methods are also accessed statically :(
jakob
Clute, Andrew schrieb:
> 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:
>
> myOjb.getProxyFactory().getReferenceProxyFactory().getRealObject(obj);
>
> 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?
>
> Thanks,
> -Andrew
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org
Re: ProxyHelper -- should it remain static?
Posted by Thomas Dudziak <to...@gmail.com>.
> agree, but I think the problem will be the new pluggable Query,
> QueryByCriteria,... interfaces. If this is true, I would prefer a method
> in main class OJB#getQueryFactory() to let OJB instantitate/configurate
> an QueryFactory instance to allow user extensions of QueryXXX classes.
> The static QueryFactory should be deprecated and still remain to be
> backward compatible (this class can't be used with extented Query classes).
Even that would work when using the delegation via the PBF, but IMO we
should deprecate the static QF nonetheless.
Tom
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org
Re: ProxyHelper -- should it remain static?
Posted by Armin Waibel <ar...@apache.org>.
Thomas Dudziak wrote:
>>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 :(
>
>
> Mhmm, don't know, do the query objects need a OJB, PC or PB object for
> creation ? If not, then the static methods could remain in place,
> could they not ?
agree, but I think the problem will be the new pluggable Query,
QueryByCriteria,... interfaces. If this is true, I would prefer a method
in main class OJB#getQueryFactory() to let OJB instantitate/configurate
an QueryFactory instance to allow user extensions of QueryXXX classes.
The static QueryFactory should be deprecated and still remain to be
backward compatible (this class can't be used with extented Query classes).
regards,
Armin
> If yes, then you're right, though we should leave the static methods
> in place nonetheless, but they only delegate to the OJB object that
> can be retrieved at the PBF (which is not static but comes from a
> ThreadLocal), and they should be properly deprecated.
>
> WDYT ?
> 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
Re: ProxyHelper -- should it remain static?
Posted by Thomas Dudziak <to...@gmail.com>.
> 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 :(
Mhmm, don't know, do the query objects need a OJB, PC or PB object for
creation ? If not, then the static methods could remain in place,
could they not ?
If yes, then you're right, though we should leave the static methods
in place nonetheless, but they only delegate to the OJB object that
can be retrieved at the PBF (which is not static but comes from a
ThreadLocal), and they should be properly deprecated.
WDYT ?
Tom
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org
Re: ProxyHelper -- should it remain static?
Posted by Jakob Braeuchi <jb...@gmx.ch>.
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
Re: ProxyHelper -- should it remain static?
Posted by Thomas Dudziak <to...@gmail.com>.
> 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