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
