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...

[Adrian Crum]

Tim,

Now that I understand what David has in mind, I think I can answer. The
changes will affect anyone who has modified their copy of OFBiz or
anyone who has built modifications based on OFBiz. It affects java code
and any scripts that reference java classes.

The impact on users shouldn't be too great - mostly requiring changing
import statements.

-Adrian


Tim Ruppert wrote:

> David, if you wouldn't mind digging in a bit deeper here for me - to
> explain it to the laymen - is this backward compatibility issue only a
> concern for people who are changing the framework and need to upgrade
> their own instances (vendor branches could be a problem here), or if
> not, how does this effect the rest of us with customizations / custom
> applications out there?
>
> I just want to get a better understanding of what's next with changes
> like this - so, any examples would be great.  Thanks.
>
> Cheers,
> Tim
> --
> Tim Ruppert
> HotWax Media
> http://www.hotwaxmedia.com
>
> o:801.649.6594
> f:801.649.6595
>
> On Aug 11, 2009, at 11:55 PM, David E Jones wrote:
>
>> The general concepts I'm trying to support, and unfortunately these
>> conflict with changing things in a backward-compatible way, are:
>

[David E. Jones-2]

Thanks Adrian. I was just starting to answer this but your answer  
looks good.

The main thing that would be affected, as Adrian said, is that people  
would have to change import statements and recompile in order for  
their Java code to work with the framework after these sorts of changes.

-David


On Aug 12, 2009, at 1:28 PM, Adrian Crum wrote:

> Tim,
>
> Now that I understand what David has in mind, I think I can answer.  
> The changes will affect anyone who has modified their copy of OFBiz  
> or anyone who has built modifications based on OFBiz. It affects  
> java code and any scripts that reference java classes.
>
> The impact on users shouldn't be too great - mostly requiring  
> changing import statements.
>
> -Adrian
>
>
> Tim Ruppert wrote:
>> David, if you wouldn't mind digging in a bit deeper here for me -  
>> to explain it to the laymen - is this backward compatibility issue  
>> only a concern for people who are changing the framework and need  
>> to upgrade their own instances (vendor branches could be a problem  
>> here), or if not, how does this effect the rest of us with  
>> customizations / custom applications out there?
>> I just want to get a better understanding of what's next with  
>> changes like this - so, any examples would be great.  Thanks.
>> Cheers,
>> Tim
>> --
>> Tim Ruppert
>> HotWax Media
>> http://www.hotwaxmedia.com
>> o:801.649.6594
>> f:801.649.6595
>> On Aug 11, 2009, at 11:55 PM, David E Jones wrote:
>>> The general concepts I'm trying to support, and unfortunately  
>>> these conflict with changing things in a backward-compatible way,  
>>> are:

[Tim Ruppert]

Ok - thanks for the info gents - I really appreciate it.

Cheers,
Tim
--
Tim Ruppert
HotWax Media
http://www.hotwaxmedia.com

o:801.649.6594
f:801.649.6595

On Aug 12, 2009, at 1:41 PM, David E Jones wrote:

>
> Thanks Adrian. I was just starting to answer this but your answer  
> looks good.
>
> The main thing that would be affected, as Adrian said, is that  
> people would have to change import statements and recompile in order  
> for their Java code to work with the framework after these sorts of  
> changes.
>
> -David
>
>
> On Aug 12, 2009, at 1:28 PM, Adrian Crum wrote:
>
>> Tim,
>>
>> Now that I understand what David has in mind, I think I can answer.  
>> The changes will affect anyone who has modified their copy of OFBiz  
>> or anyone who has built modifications based on OFBiz. It affects  
>> java code and any scripts that reference java classes.
>>
>> The impact on users shouldn't be too great - mostly requiring  
>> changing import statements.
>>
>> -Adrian
>>
>>
>> Tim Ruppert wrote:
>>> David, if you wouldn't mind digging in a bit deeper here for me -  
>>> to explain it to the laymen - is this backward compatibility issue  
>>> only a concern for people who are changing the framework and need  
>>> to upgrade their own instances (vendor branches could be a problem  
>>> here), or if not, how does this effect the rest of us with  
>>> customizations / custom applications out there?
>>> I just want to get a better understanding of what's next with  
>>> changes like this - so, any examples would be great.  Thanks.
>>> Cheers,
>>> Tim
>>> --
>>> Tim Ruppert
>>> HotWax Media
>>> http://www.hotwaxmedia.com
>>> o:801.649.6594
>>> f:801.649.6595
>>> On Aug 11, 2009, at 11:55 PM, David E Jones wrote:
>>>> The general concepts I'm trying to support, and unfortunately  
>>>> these conflict with changing things in a backward-compatible way,  
>>>> are:
>

[David E. Jones-2]

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
>
>
> 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 <[hidden email]> wrote:
>>>>>> From: Adrian Crum <[hidden email]>
>>>>>> 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: [hidden email]
>>>>>> Date: Friday, July 17, 2009, 5:07 PM
>>>>>>
>>>>>> --- On Fri, 7/17/09, David E Jones <[hidden email]>
>>>>>> 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
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>

[Adrian Crum]

Changing import statements is no big deal from my perspective. The issue
I had was in naming the new interfaces something different than the
existing concrete classes they replace - that would involve a lot of
rewriting.

-Adrian

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
>>
>>
>> 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 <[hidden email]> wrote:
>>>>>>> From: Adrian Crum <[hidden email]>
>>>>>>> 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: [hidden email]
>>>>>>> Date: Friday, July 17, 2009, 5:07 PM
>>>>>>>
>>>>>>> --- On Fri, 7/17/09, David E Jones <[hidden email]>
>>>>>>> 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
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>
>
>

[Joe Eckard]

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

[Adrian Crum]

David E Jones wrote:
> That sounds pretty backwards Adrian, ie do the security changes and then
> do the execution context.

Actually, no. The ExecutionContext was first mentioned in the security
redesign document. The multi-tenancy aspect was mentioned afterward.

My employer has no need for multi-tenancy. However, my employer could
really use the new security design. So, I'm trying to get the new
security design into the project in a way that is compatible with your
multi-tenancy plans.

The changes I committed meet *those* goals. I don't see where my commits
prevent you from implementing multi-tenancy. If your goal is to have
code reference the delegator as an interface, then what's the problem? I
did that for you. If you want to have the delegator interface in a
different folder, then fine - move it there.

As I keep saying, it doesn't have to be "all or nothing." We can bring
the concepts into the project a little at a time. I don't see the
multi-tenancy thing being completed any time soon - there is far too
much work to be done. In the meantime, why hold up the security redesign?

-Adrian

[David E. Jones-2]

On Aug 12, 2009, at 3:51 PM, Adrian Crum wrote:

> David E Jones wrote:
>> That sounds pretty backwards Adrian, ie do the security changes and  
>> then do the execution context.
>
> Actually, no. The ExecutionContext was first mentioned in the  
> security redesign document. The multi-tenancy aspect was mentioned  
> afterward.
>
> My employer has no need for multi-tenancy. However, my employer  
> could really use the new security design. So, I'm trying to get the  
> new security design into the project in a way that is compatible  
> with your multi-tenancy plans.
>
> The changes I committed meet *those* goals. I don't see where my  
> commits prevent you from implementing multi-tenancy. If your goal is  
> to have code reference the delegator as an interface, then what's  
> the problem? I did that for you. If you want to have the delegator  
> interface in a different folder, then fine - move it there.
>
> As I keep saying, it doesn't have to be "all or nothing." We can  
> bring the concepts into the project a little at a time. I don't see  
> the multi-tenancy thing being completed any time soon - there is far  
> too much work to be done. In the meantime, why hold up the security  
> redesign?

Actually, I have no intention of implementing multi-tenancy support, I  
suppose unless someone comes along and pays me to do it or something.

The point is to add in the flexibility for these things. It's true we  
can certainly implement some things and not others, but please  
understand (as I mentioned before) that the changes you made conflict  
with the changes I was working on in the branch, in somewhat major  
ways, and will require a fair amount of manual rework to get things  
going again there.

That said, I still haven't seen how you resolved the dependency issue,  
even on the security side of things. If we have an execution context  
that depends on the service engine, which depends on the entity  
engine, and the entity engine contains or depends on the execution  
context, then we have a circular dependency. Short of combining those  
components onto a single classpath we have a problem.

With that problem instead of going in the direction of making MORE  
dependencies between the framework components, I decided on a  
direction to go for LESS dependencies between the framework components  
by using a set of interfaces that represent the main tools in the  
framework and provide the most common API elements that people might  
need/want.

In other words, this refactoring is not just for multi-tenancy  
purposes, and in fact that is just a nice side effect (ie those along  
with many things will be easier to implement). As I see it for the  
security implementation we'll have these dependency problems as well  
and we need some solution for them...

-David

[Adrian Crum]

David E Jones wrote:
> That said, I still haven't seen how you resolved the dependency issue,
> even on the security side of things. If we have an execution context
> that depends on the service engine, which depends on the entity engine,
> and the entity engine contains or depends on the execution context, then
> we have a circular dependency. Short of combining those components onto
> a single classpath we have a problem.

What I meant was I solved the cross-dependency problem in the
ExecutionContext interface itself. Anyone who tries out the branch can
see that, and they can see that the execution path aspect of it works.
That is a prerequisite to getting the new security design implemented.

> With that problem instead of going in the direction of making MORE
> dependencies between the framework components, I decided on a direction
> to go for LESS dependencies between the framework components by using a
> set of interfaces that represent the main tools in the framework and
> provide the most common API elements that people might need/want.

I agree, and I'm willing to help in that effort. Again, it's not a
show-stopper for getting the security redesign implemented.

I'll continue developing the security redesign in the branch I created.

On the issue of reducing cross dependencies, why can't that be done in
the trunk? We could do it one component at a time. Doing it that way
would be fairly simple and it would be easy to test.

I saw in your commit log that you were mulling over which methods should
be kept in the interfaces, and that some methods are unnecessary. Let's
focus on the goal of eliminating cross dependencies and just allow
Eclipse to extract interfaces. Leave the decision of which methods
should or shouldn't be kept for another time.

Let's say we're working on the entity component. Just extract interfaces
from the commonly used classes, move them to framework/api, update
import statements, compile, test, commit. It seems pretty
straightforward to me.

-Adrian

[Adrian Crum-2]

--- On Wed, 8/12/09, Adrian Crum <[hidden email]> wrote:

> Let's say we're working on the entity component. Just
> extract interfaces from the commonly used classes, move them
> to framework/api, update import statements, compile, test,
> commit. It seems pretty straightforward to me.

Crow tastes nasty.

After trying to implement my example, I can see the problems. Wow, that is ugly. One thing is certain, we're very good at painting ourselves into corners.

-Adrian






     

[Ruth Hoffman-2]

My 2 cents:
I don't think it is as important to have backwards compatibility as it
is to have a well articulated plan for bringing all non-conforming
frameworks up to date. Personally, I wouldn't go any further discussing
this until I had a documented strategy. [And I don't mean "this may
work..." or "you might try that...". I mean a detailed plan for migration.
Ruth
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
>>
>>
>> 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 <[hidden email]> wrote:
>>>>>>> From: Adrian Crum <[hidden email]>
>>>>>>> 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: [hidden email]
>>>>>>> Date: Friday, July 17, 2009, 5:07 PM
>>>>>>>
>>>>>>> --- On Fri, 7/17/09, David E Jones <[hidden email]>
>>>>>>> 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
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>
>
>

[Adrian Crum-2]

--- On Tue, 8/11/09, David E Jones <[hidden email]> 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

I started doing this in the entity component in the branch I created. Based on your branch, I extracted some interfaces and tried to move them to the api folder. The problem is, the interfaces reference a lot of classes in the entity component. In order to avoid circular-dependency, I had to create factories in api that create the classes in the entity component. Things started getting REALLY messy.

I've reached the conclusion that it would be simpler and cleaner to just move the commonly used components (entity, security, and service) into a common folder (api), and then extract only the interfaces that really need extracting.

What do you think?

-Adrian



     

[David E. Jones-2]

On Aug 14, 2009, at 3:23 PM, Adrian Crum wrote:

> --- On Tue, 8/11/09, David E Jones <[hidden email]> 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
>
> I started doing this in the entity component in the branch I  
> created. Based on your branch, I extracted some interfaces and tried  
> to move them to the api folder. The problem is, the interfaces  
> reference a lot of classes in the entity component. In order to  
> avoid circular-dependency, I had to create factories in api that  
> create the classes in the entity component. Things started getting  
> REALLY messy.
>
> I've reached the conclusion that it would be simpler and cleaner to  
> just move the commonly used components (entity, security, and  
> service) into a common folder (api), and then extract only the  
> interfaces that really need extracting.
>
> What do you think?

Simpler yes (for the framework implementation at least, not for the  
code that uses it), cleaner... I don't know.

Please keep in mind that the branch I've been working on is not  
complete, and eventually there will be no dependencies from the  
context component code to the other components... ie that's the whole  
goal, it's just not done yet.

-David

[Adrian Crum-2]

--- On Fri, 8/14/09, David E Jones <[hidden email]> wrote:

> Simpler yes (for the framework implementation at least, not
> for the code that uses it), cleaner... I don't know.
>
> Please keep in mind that the branch I've been working on is
> not complete, and eventually there will be no dependencies
> from the context component code to the other components...
> ie that's the whole goal, it's just not done yet.

Then you must have access to some voodoo I'm not aware of. If an interface references a class in the entity component, then how will there be no dependency on it?

-Adrian



     

[David E. Jones-2]

On Aug 14, 2009, at 7:15 PM, Adrian Crum wrote:

> --- On Fri, 8/14/09, David E Jones <[hidden email]> wrote:
>
>> Simpler yes (for the framework implementation at least, not
>> for the code that uses it), cleaner... I don't know.
>>
>> Please keep in mind that the branch I've been working on is
>> not complete, and eventually there will be no dependencies
>> from the context component code to the other components...
>> ie that's the whole goal, it's just not done yet.
>
> Then you must have access to some voodoo I'm not aware of. If an  
> interface references a class in the entity component, then how will  
> there be no dependency on it?

That's where the choice I was talking about a long time ago comes  
in... there may be other options but these are the main two ones I've  
been working with:

1. create an interface for the class referenced by the other  
interface, making it part of the high level interfaces

2. remove the method from the interface, leaving it on the  
implementing class meaning you have to use a type cast to the  
implementing class in order to use it (and it won't work for other  
implementations of the interface)

This is not always an easy decision... so I imagine we'll have various  
discussions about specific methods. For my part I'm taking a first  
pass and trying to keep things at a high level and somewhat  
simplified, and we may decide to expand the interfaces in the future  
by adding the methods and creating additional interfaces. The  
distinction I'm trying to go for is those methods/classes that are  
likely to be used in applications that those that are lower-level.

-David

[Adrian Crum-2]

--- On Fri, 8/14/09, David E Jones <[hidden email]> wrote:

> On Aug 14, 2009, at 7:15 PM, Adrian Crum wrote:
>
> > --- On Fri, 8/14/09, David E Jones <[hidden email]>
> wrote:
> >
> >> Simpler yes (for the framework implementation at
> least, not
> >> for the code that uses it), cleaner... I don't
> know.
> >>
> >> Please keep in mind that the branch I've been
> working on is
> >> not complete, and eventually there will be no
> dependencies
> >> from the context component code to the other
> components...
> >> ie that's the whole goal, it's just not done yet.
> >
> > Then you must have access to some voodoo I'm not aware
> of. If an interface references a class in the entity
> component, then how will there be no dependency on it?
>
> That's where the choice I was talking about a long time ago
> comes in... there may be other options but these are the
> main two ones I've been working with:
>
> 1. create an interface for the class referenced by the
> other interface, making it part of the high level
> interfaces
>
> 2. remove the method from the interface, leaving it on the
> implementing class meaning you have to use a type cast to
> the implementing class in order to use it (and it won't work
> for other implementations of the interface)
>
> This is not always an easy decision... so I imagine we'll
> have various discussions about specific methods. For my part
> I'm taking a first pass and trying to keep things at a high
> level and somewhat simplified, and we may decide to expand
> the interfaces in the future by adding the methods and
> creating additional interfaces. The distinction I'm trying
> to go for is those methods/classes that are likely to be
> used in applications that those that are lower-level.

That's what I started to do, and I ended up with a lot of interfaces. Then there are classes that the interfaces reference, but are only used internally, so I moved those into the same folder as the interfaces. In the end I had twice as many files (interface plus implementation), and a folder that nearly mirrored the entity component. That's why I came to the conclusion that it would make more sense to just put the whole entity component in that folder.

Anyways, the branch I created builds and runs. Everything is still in the entity component though. If you start moving the interfaces to another folder, you will get a good grasp of the scope of the problem.

-Adrian



     

[Adrian Crum]

One problem I just ran into while implementing the security redesign:

EntityListIterator implements ListIterator, but code throughout the
project references EntityListIterator (a concrete class) instead of
ListIterator (an interface).

I would like to refactor that so that the interface is used instead of
the concrete class. What do you think?

-Adrian

Adrian Crum wrote:

> --- On Wed, 8/12/09, Adrian Crum <[hidden email]> wrote:
>
>> Let's say we're working on the entity component. Just
>> extract interfaces from the commonly used classes, move them
>> to framework/api, update import statements, compile, test,
>> commit. It seems pretty straightforward to me.
>
> Crow tastes nasty.
>
> After trying to implement my example, I can see the problems. Wow, that is ugly. One thing is certain, we're very good at painting ourselves into corners.
>
> -Adrian

[Adrian Crum]

Actually, I just converted EntityListIterator to an interface and
everything works fine. It ended up being a trivial change.

I'll wait for any objections before committing it.

-Adrian

Adrian Crum wrote:

> One problem I just ran into while implementing the security redesign:
>
> EntityListIterator implements ListIterator, but code throughout the
> project references EntityListIterator (a concrete class) instead of
> ListIterator (an interface).
>
> I would like to refactor that so that the interface is used instead of
> the concrete class. What do you think?
>
> -Adrian
>
> Adrian Crum wrote:
>> --- On Wed, 8/12/09, Adrian Crum <[hidden email]> wrote:
>>
>>> Let's say we're working on the entity component. Just
>>> extract interfaces from the commonly used classes, move them
>>> to framework/api, update import statements, compile, test,
>>> commit. It seems pretty straightforward to me.
>>
>> Crow tastes nasty.
>>
>> After trying to implement my example, I can see the problems. Wow,
>> that is ugly. One thing is certain, we're very good at painting
>> ourselves into corners.
>>
>> -Adrian
>
>

[David E. Jones-2]

On Aug 15, 2009, at 2:27 AM, Adrian Crum wrote:

> --- On Fri, 8/14/09, David E Jones <[hidden email]> wrote:
>> On Aug 14, 2009, at 7:15 PM, Adrian Crum wrote:
>>
>>> --- On Fri, 8/14/09, David E Jones <[hidden email]>
>> wrote:
>>>
>>>> Simpler yes (for the framework implementation at
>> least, not
>>>> for the code that uses it), cleaner... I don't
>> know.
>>>>
>>>> Please keep in mind that the branch I've been
>> working on is
>>>> not complete, and eventually there will be no
>> dependencies
>>>> from the context component code to the other
>> components...
>>>> ie that's the whole goal, it's just not done yet.
>>>
>>> Then you must have access to some voodoo I'm not aware
>> of. If an interface references a class in the entity
>> component, then how will there be no dependency on it?
>>
>> That's where the choice I was talking about a long time ago
>> comes in... there may be other options but these are the
>> main two ones I've been working with:
>>
>> 1. create an interface for the class referenced by the
>> other interface, making it part of the high level
>> interfaces
>>
>> 2. remove the method from the interface, leaving it on the
>> implementing class meaning you have to use a type cast to
>> the implementing class in order to use it (and it won't work
>> for other implementations of the interface)
>>
>> This is not always an easy decision... so I imagine we'll
>> have various discussions about specific methods. For my part
>> I'm taking a first pass and trying to keep things at a high
>> level and somewhat simplified, and we may decide to expand
>> the interfaces in the future by adding the methods and
>> creating additional interfaces. The distinction I'm trying
>> to go for is those methods/classes that are likely to be
>> used in applications that those that are lower-level.
>
> That's what I started to do, and I ended up with a lot of  
> interfaces. Then there are classes that the interfaces reference,  
> but are only used internally, so I moved those into the same folder  
> as the interfaces. In the end I had twice as many files (interface  
> plus implementation), and a folder that nearly mirrored the entity  
> component. That's why I came to the conclusion that it would make  
> more sense to just put the whole entity component in that folder.
>
> Anyways, the branch I created builds and runs. Everything is still  
> in the entity component though. If you start moving the interfaces  
> to another folder, you will get a good grasp of the scope of the  
> problem.

Um... have you looked at the branch I created and was working in?

I'm still wondering what your plans are. Did you start over because  
you reviewed the work I did and didn't like it and wanted to implement  
something instead, or have you not reviewed the work I did?

-David

[David E. Jones-2]

I hope you understand that this is yet another change that conflicts  
with what I put in the branch...

Again, is it your intention to ignore that work and move in a  
different direction making it difficult (or impossible without re-
changing various things) to get that finished and merged back in?

I suppose I've been out a lot for the last couple of weeks and so I  
haven't been able to finish this, so perhaps I have no say any more...  
except what I've said before that you REALLY need to think through to  
the end goal before trying to make interim steps that may turn out to  
not be helpful at all... and if no one else cares... why should I?

-David


On Aug 20, 2009, at 11:35 AM, Adrian Crum wrote:

> Actually, I just converted EntityListIterator to an interface and  
> everything works fine. It ended up being a trivial change.
>
> I'll wait for any objections before committing it.
>
> -Adrian
>
> Adrian Crum wrote:
>> One problem I just ran into while implementing the security redesign:
>> EntityListIterator implements ListIterator, but code throughout the  
>> project references EntityListIterator (a concrete class) instead of  
>> ListIterator (an interface).
>> I would like to refactor that so that the interface is used instead  
>> of the concrete class. What do you think?
>> -Adrian
>> Adrian Crum wrote:
>>> --- On Wed, 8/12/09, Adrian Crum <[hidden email]> wrote:
>>>
>>>> Let's say we're working on the entity component. Just
>>>> extract interfaces from the commonly used classes, move them
>>>> to framework/api, update import statements, compile, test,
>>>> commit. It seems pretty straightforward to me.
>>>
>>> Crow tastes nasty.
>>>
>>> After trying to implement my example, I can see the problems. Wow,  
>>> that is ugly. One thing is certain, we're very good at painting  
>>> ourselves into corners.
>>>
>>> -Adrian