From: David E Jones <d...@me.com>
Subject: Re: Discussion: ExecutionContext
To: dev@ofbiz.apache.org
Date: Tuesday, August 11, 2009, 10:55 PM
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
