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
