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
On Aug 10, 2009, at 4:43 PM, Adrian Crum wrote:
One potential problem there (and it's not a biggie, just something
that needs clarification) - I implemented an ExecutionContext
factory because I recall you mentioning it somewhere. That would
require a decorator.
The implementation I have doesn't really require a factory. So, if
doing away with the factory is okay, then we can have
DispatchContext extend ExecutionContext.
-Adrian
David E Jones wrote:
Actually I was planning on using the ExecutionContext instead of
the DispatchContext. We could have a DispatchContext interface that
extends the ExecutionContext one if we can get that to make it
easier to update services written Java (ie just require something
like the Eclipse organize imports to get things working again).
-David
On Aug 10, 2009, at 4:13 PM, Adrian Crum wrote:
It seems to me that DispatchContext plays a similar role as
ExecutionContext - as far as being a container of artifacts used
by services. I'm thinking DispatchContext could decorate an
ExecutionContext instance, and then the service engine wouldn't
need to have another object to pass around.
-Adrian
Adrian Crum wrote:
I'm bumping this because I might have some time this weekend to
help.
David - I would like to work on converting some of the frequently
used lower-level concrete classes to interfaces. You didn't reply
when I suggested it before. Do you have any objections?
Also, if that conversion is done, it could be done in the trunk -
negating the need for a branch. In other words, once the higher
level code is using interfaces, you can muck around with the
implementations all you want.
-Adrian
--- On Fri, 7/17/09, Adrian Crum <adrian.c...@yahoo.com> wrote:
From: Adrian Crum <adrian.c...@yahoo.com>
Subject: Re: svn commit: r795024 [1/6] - in /ofbiz/branches/
executioncontext20090716: ./ applications/content/src/org/ofbiz/
content/content/ applications/order/src/org/ofbiz/order/order/
applications/party/src/org/ofbiz/party/party/ applications/
product/src/org/ofb...
To: dev@ofbiz.apache.org
Date: Friday, July 17, 2009, 5:07 PM
--- On Fri, 7/17/09, David E Jones <d...@me.com>
wrote:
There is a basic reason for this, and it's because I'm
lazy
and also not sure how many of these "lower level"
objects we
even want interfaces for.
My preference would be to change all of it to interfaces.
Higher level code should interact with interfaces - not
concrete classes (dependency inversion).
Keep in mind you're not alone in this effort - I'm
available to help.
-Adrian
