I think it sounds really good, certainly something worth breaking
backwards compatibility for. However I would be concerned about having
a release branch that is radically different than trunk (the 4.0
scenario). I'd like to see a new release branch as soon as possible
after the dust has settled.
-Joe
On Aug 12, 2009, at 4:18 PM, David E Jones wrote:
On a related note, what do people think of these objectives?
Are they interesting or helpful to you?
Is enabling these things worth not having backward compatibility in
the framework?
Any general opinions or related things that we should throw in while
we're mucking things up?
-David
On Aug 11, 2009, at 11:55 PM, David E Jones wrote:
I mentioned a little bit before about centralizing the interfaces
into a single component that does not depend on the other
components and that other components can depend on. These will
become the basic set of tools available for application logic build
on the OFBiz framework.
The general concepts I'm trying to support, and unfortunately these
conflict with changing things in a backward-compatible way, are:
1. create interfaces and backing objects that can be used in all
tools to represent the context in which the artifacts execute, and
have the framework artifacts themselves use this context too
2. provide a factory interface that a singleton object can use to
create the execution context and all of the objects it depends on
(based on interfaces in the context component); once all code is
using the execution context instead of getting at resources in
other ways it will be possible to change the context in which logic
executes easily; this will facilitate multi-tenant customizations
of OFBiz, and also become a central part of what we will need for
runtime context-sensitive security
3. based on this it should be possible for code using the OFBiz
framework to not include very many jars, and in fact should mostly
just need the framework context jar
4. this sort of increased isolation between the framework
implementation and application code will make unit testing easier,
for those that really want to do low-level stubbed unit tests
The problem with these goals is that there is no way (not that I
can think of anyway) to implement them without changing the
framework in non-backward compatible ways. I am trying to do so in
such a way that mostly just packages and compiling against
interfaces instead of objects will need to be done, but that is
still something that needs lots of changes and so will need to be
phased in over a fair amount of effort... which is why I went for
the branch with more comprehensive changes instead of trying to do
it all in-place as a series of backward-compatible changes.
To be more specific here are some things in what you have done that
won't meet the goals listed above:
1. the GenericDelegator interface needs to be in the shared context
component instead of in the entity component where there would be a
circular dependency with the ExecutionContext and other related
interfaces
2. we don't want a factory specifically for the delegator, at least
not one that would be commonly used by higher level code; code
should always get the delegator and other objects from the
ExecutionContext, even when it needs a specific named delegator and
it should just pass that name into the ExecutionContext
I hope that makes things more clear, and in the spirit of
communication will help us to collaborate on this.
On a side note, you may be right that with a smaller set of goals,
like just doing an ExecutionContext for security reasons and not
change things to get all framework tool objects (like the delegator
and dispatcher) from the ExecutionContext then we could probably do
it with mostly backward compatible, and more incremental, changes.
-David