Status of executioncontext20091231

[David E Jones <de...@me.com>]

Adrian,

Like I mentioned a week or so ago I'm finally getting around to taking a peek at the executioncontext20091231 branch. It looks like you've made a lot of progress, and that's great!

Could you comment on the general status and the top things on your to do list for it?

In addition to your general thoughts I'm wondering about a few things I ran into while reviewing it, and trying to build it (and will eventually try to run it too):

1. There are currently a few issues keeping it from compiling:
   a. like various classes are declared to implement the ExecutionArtifact interface but don't implement the "run" method on that interface (on a side note a more specific name might be helpful like even runExecutionArtifactInternal or something in order to avoid name conflicts); was your plan to do something special with this "run" method?
   b. there are quite a few methods scattered about that have a @Override annotation but that don't override anything; this shows as an error in Eclipse, though now as I test the build with the run method commented out I see that it doesn't block compilation

2. It looks like your primary focus initially is to implement the context-sensitive security using the ExecutionContext to keep track of the ArtifactPath so you know how you got to the artifact you are in. How is that security configured? I apologize that I haven't dug into this a whole lot (have that next on my list), but I don't see any entity definitions for database-driven security or an XSD for an XML file or anything like that. I see the interfaces and classes you've started working on, is the intent to run everything through a Java API somehow?

3. I'd like to get back to the stuff I was working in my branch from July, and redoing it based on the current interfaces and changes made in the trunk and the new executioncontext20091231 branch. That would mean deprecating the current delegator and dispatcher factory methods and changing everything (including the Service Engine dispatch context) to get the delegator and dispatcher (and perhaps other things in the future) from the ExecutionContext. This means significant refactoring as I did before and lots of changes to go into the branch. I'm in a position where I'd like to get this done fairly quickly (like within the next couple/few weeks), but I won't try to imply that this is small or simple or will represent a small number of changes since it will require abstracting various parts of the entity and service engines into the new "api" component as interfaces for parts of those tools. However, if you're not going to work with me on this and avoid making changes that invalidate lots of work like with the last branch, then I won't bother doing it, and if this potential project comes through that might help pay for it I guess I'll end up doing it outside of the main project just like has been done with all of the other multi-tenant implementations so far.

4. I'd also like to finish the design for a data model to externalize security configuration, along the lines of what I wrote in the OFBTECH/OFBiz+Security+Redesign document, including the comment I added later to normalize the SecurityArtifactAuth entity. This of course relates to #2 above.

Anyway, thanks for all of your work on this. It's a great direction in general and it's great to see progress on it.

-David

Re: Status of executioncontext20091231

[Adrian Crum <ad...@yahoo.com>]

David,

Thank you for taking the time to review the code. Comments inline.

--- On Tue, 1/19/10, David E Jones <de...@me.com> wrote:
> Could you comment on the general status and the top things
> on your to do list for it?

The general status is in the BranchReadMe.txt file. The next thing I have planned is to implement security checking at the entity field level. Right now only the entity is checked.

> 1. There are currently a few issues keeping it from
> compiling:
>    a. like various classes are declared to
> implement the ExecutionArtifact interface but don't
> implement the "run" method on that interface (on a side note
> a more specific name might be helpful like even
> runExecutionArtifactInternal or something in order to avoid
> name conflicts); was your plan to do something special with
> this "run" method?

That was thrown in at the last minute based on Adam's suggestion. I wasn't aware it caused a compilation problem. I will check into that soon.

>    b. there are quite a few methods
> scattered about that have a @Override annotation but that
> don't override anything; this shows as an error in Eclipse,
> though now as I test the build with the run method commented
> out I see that it doesn't block compilation

That's odd - my copy of Eclipse is what put those compiler directives in there. Feel free to remove any that are causing warnings.

> 2. It looks like your primary focus initially is to
> implement the context-sensitive security using the
> ExecutionContext to keep track of the ArtifactPath so you
> know how you got to the artifact you are in. How is that
> security configured? I apologize that I haven't dug into
> this a whole lot (have that next on my list), but I don't
> see any entity definitions for database-driven security or
> an XSD for an XML file or anything like that. I see the
> interfaces and classes you've started working on, is the
> intent to run everything through a Java API somehow?

You are correct - my primary goal is to get the security-aware artifacts working. The OOTB implementation is based on the entity engine. You can find the entities defined in the security component, and there is plenty of demo data to see how to use it. There is a user login "artifact-user" that has permission to use the Example component.

> 3. I'd like to get back to the stuff I was working in my
> branch from July, and redoing it based on the current
> interfaces and changes made in the trunk and the new
> executioncontext20091231 branch. That would mean deprecating
> the current delegator and dispatcher factory methods and
> changing everything (including the Service Engine dispatch
> context) to get the delegator and dispatcher (and perhaps
> other things in the future) from the ExecutionContext. This
> means significant refactoring as I did before and lots of
> changes to go into the branch. I'm in a position where I'd
> like to get this done fairly quickly (like within the next
> couple/few weeks), but I won't try to imply that this is
> small or simple or will represent a small number of changes
> since it will require abstracting various parts of the
> entity and service engines into the new "api" component as
> interfaces for parts of those tools. However, if you're not
> going to work with me on this and avoid making changes that
> invalidate lots of work like with the last branch, then I
> won't bother doing it, and if this potential project comes
> through that might help pay for it I guess I'll end up doing
> it outside of the main project just like has been done with
> all of the other multi-tenant implementations so far.

As I have said before - both on the list and on the phone - it wasn't my intention to have competing branches, it just worked out that way. I really tried to use your branch but I couldn't. It would be helpful if we could put that behind us and move forward.

I never intentionally invalidate your work. If I do something that conflicts with your plans, it is probably because I don't know about them. It might help to put your ideas in writing so others can follow along.

> 4. I'd also like to finish the design for a data model to
> externalize security configuration, along the lines of what
> I wrote in the OFBTECH/OFBiz+Security+Redesign document,
> including the comment I added later to normalize the
> SecurityArtifactAuth entity. This of course relates to #2
> above.

That has been done already.

> Anyway, thanks for all of your work on this. It's a great
> direction in general and it's great to see progress on it.

It's good to know there will be others working on it. I put a lot of time into it, and I still wasn't sure if any of that effort would make its way into the project.

I put the branch on the shelf for a little while so I can work on some things in the trunk. I will let you know when I can work on it some more, and maybe then you can let me know how I can help with your plans.

-Adrian