David, Thank you very much for the reply! That certainly clears up a lot of confusion.
I noticed the context folder and that you put interfaces in there, but I didn't understand the purpose. Maybe a better name for that folder would be api - since it will contain much more than the ExecutionContext. Maybe have something like framework/api/context, framework/api/entity, framework/api/security, etc. I have solved the conflicting dependency issue with the ExecutionContext. I have it working. Right now it only follows the execution path down to the entity level. I stopped there because I felt that (ultimately) doing permission checks on individual fields would be a performance hit. We can look at that in more detail later. I would like to get it committed. Once it is committed, then we can start making changes to have code get its resources from the ExecutionContext. I started working on the AuthorizationManager. I will probably have most of it fleshed out by the end of this weekend. My hope is that we can get the security redesign finished, and once that is done, we can start building out the ExecutionContext the way you have envisioned. Putting interfaces into a single jar is a good idea and a worthwhile goal, so I'm on board with that effort. -Adrian --- On Tue, 8/11/09, David E Jones <[email protected]> wrote: > From: David E Jones <[email protected]> > Subject: Re: Discussion: ExecutionContext > To: [email protected] > 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 <[email protected]> > wrote: > >>>>> From: Adrian Crum <[email protected]> > >>>>> 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: [email protected] > >>>>> Date: Friday, July 17, 2009, 5:07 PM > >>>>> > >>>>> --- On Fri, 7/17/09, David E Jones > <[email protected]> > >>>>> 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 > >>>>> > >>>>> > >>>>> > >>>>> > >>>> > >
