On Sep 8, 2009, at 1:18 PM, Adam Heath wrote:
David E Jones wrote:
On Sep 8, 2009, at 11:58 AM, Adam Heath wrote:
Adrian Crum wrote:
Adam Heath wrote:
Adrian Crum wrote:
Adam Heath wrote:
adri...@apache.org wrote:
Author: adrianc
Date: Sun Aug 9 18:04:26 2009
New Revision: 802567
URL: http://svn.apache.org/viewvc?rev=802567&view=rev
Log:
Refactored GenericDelegator:
1. Converted GenericDelegator to an interface. We already have
DelegatorInterface, but it isn't being used anywhere. Removed
DelegatorInterface.java.
2. Extracted the static, cached data from the GenericDelegator
implementation and put it in its own class - DelegatorData. The
GenericDelegator implementation holds a reference to the
DelegatorData instance. This makes it possible to have per-
thread
instances of GenericDelegator.
3. Replaced the ThreadLocal variables with regular variables.
ThreadLocal variables are no longer needed. Client code
doesn't need
to be concerned with pushing and popping the GenericDelegator
state.
This commit paves the way for the forthcoming ExecutionContext.
User modifications will have to replace
GenericDelegator.getGenericDelegator(...) with
DelegatorFactory.getGenericDelegator(...). Also, replace the
push
code with the new setXxx methods, and remove the pop code. If
modifications used DelegatorInterface, replace that with
GenericDelegator.
Aside from those changes, this commit is backwards compatible.
No, it is not backwards compatible.
When a java class is compiled, the bytecode requests an
interface
named 'foo', or a class named 'foo'. If 'foo' changes from
class to
interface, then pre-compiled classes will *not* load.
Please, change GenericDelegator back to a class.
If DelegatorInterface wasn't used, and was just not uptodate
with the
method signatures, wouldn't the simpler thing have been to
improve
DelegatorInterface, then to change the class itself? It seems
more
work to change the class to an interface.
I have external code(webslinger) that needs to support multiple
versions of ofbiz(one all the way back to 512946). This
change makes
that impossible. I have to have multiple versions of ofbiz
installed(pre/post this change), and compile the class once
for each
ofbiz version.
Which is easier: rewrite all your Webslinger code to reference
DelegatorInterface instead of GenericDelegator, or just
recompile your
existing code without making any changes?
That's just it, I wouldn't have to recompile *at all*, if
GenericDelegator stayed a class. Nor would anyone else.
I don't have a problem with reverting it, but GenericDelegator will
become an interface eventually. If you take a look at David's
ExecutionContext branch, that is what he has planned.
Why? We already had DelegatorInterface, that has existed for years;
it was just never fleshed out.
There was a lot of discussion about this in the context of the
reasons/goals behind the executioncontext branch(es). The basic
idea is
to move the framework to be accessible through a set of interfaces
that
are in a single place, a low-level component that other framework
components will depend on, and then all code will use the framework
through the interfaces instead of going directly to classes (which
will
just be internal implementations of the framework interfaces and not
generally used directly).
For the rationale behind this, please see the write up I sent to this
mailing list a few weeks ago about the ExecutionContext and related
stuff.
Sure, understand all that. But this broke ABI. And I understand that
such a set of changes will *have* to break ABI.
If this change is to support the ExecutionContext branch, then it
should stay in that branch, 'til it is ready.
That is one thing I DO agree with, which is why I was doing all of the
work I did in a branch and refactoring dependent code there.
I'm seeing this done in the reverse order. Introduce a *new*
interface, that existing implementations will use. Alter all users to
use the interface. When all users are so modified, rename the
implementation to whatever.
What has happened, is that the last step was done first.
Profound.
-David
