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
