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

Reply via email to