Joe Germuska wrote:
So, I was just about to add support for static access to the "current" ActionContext using ThreadLocal, and then I realized that ...
...snip...
... member? Is there some artful way to hide it more? Of course, we'd have
public static void setCurrentInstance(ActionContext ctx)
Why not just put the ThreadLocal the same place you put these methods wrapping it? Interfaces can't have static methods so you'll have to have it on some concrete class somewhere, yes?
-Paul
Um. yeah, good point. I didn't think that through.
Still, if by "these methods wrapping it" you mean the ComposableRequestProcessor (which is currently in charge of instantiating an ActionContext)... that doesn't seem right.
ActionContext could have an inner class which implements holding behavior, reachable as a singleton static field. This seems a bit overwrought too, but it would work.
public interface ActionContext extends Context { public static final ContextHolder = new ContextHolder();
public static final Class ContextHolder {
private ContextHolder() { }
public ActionContext getCurrentContext() {}
public void setCurrentContext(ActionContext) { }
}If we had an "application-level" counterpart to the ActionContext (the app "API bean" which has been discussed here before), I think I'd be more willing to make that an abstract class, and then it might be a good place to put a static method for this.
I've wanted that API bean for a while, so I think I'm going to consider it for a bit, especially because this ThreadLocal idea is not something people have been aggressively clamoring for.
I haven't caught up yet on the chain implementation. We have ActionContext as an interface. Is there going to be a way to let the user provide a different instance, or is extending ComposableRequestProcessor the recommended approach? If a factory is created to produce ActionContext instances, the getCurrentContext() method can be placed there, reducing the "arbitrary" vibe.
That does solve two problems; right now the way of choosing an alternate ActionContext implementation is to extend ComposableRequestProcessor and override the "contextInstance()" method. A factory didn't seem necessary, although I think that you've just raised a pretty good use case for moving the instantiation responsibility out to a Factory which could serve these two purposes. I'm not convinced yet, but I'm definitely interested in thinking about it.
In general, I find bootstrapping Factory processes kind of tedious when you have to get down to reading properties files in and such; I was pursuing it for a while using commons-discovery for day-job projects but once I started seeing good IoC containers, I dropped it cold. In this specific case, I don't know that there is much need for configuring the factory, so we could just put the factory class name as a <controller> attribute (or return to the idea of nesting a <request-processor> attribute in the <controller>.
Of course now this all reminds me of some of my general dissatisfactions with the current Struts config process -- but I don't want to get stuck on that again! I think the API bean musings will bump up against the same question.
But since this isn't a burningly important feature, I'm happy to let it bump around for a while and see what people think.
Joe
-- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com "Narrow minds are weapons made for mass destruction" -The Ex
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
