Yes. I actually thought of that issue after I replied to you.
Another option you can look into is subclassing the ControllerConfig class
and specify your new Config class in the className attribute of the
controller element in each of your modules. You could then build in the
functionality to configure extra "module-scoped" variable.
I think you could do it more simply. In org.apache.struts.util.RequestUtils, there's this method:
public static String getModuleName(HttpServletRequest request, ServletContext context) {
return ModuleUtils.getInstance().getModuleName(request, context);
}
So now, in any situation where you have a request and a servlet context, you can look up the current module name. Using this, you can construct unique names for things stored in the application (servlet) context. This is what Struts does, of course. Depending on what's easiest for you, you can locate this expertise anyplace. The simplest would probably be in a method in a subclass of org.apache.struts.action.Action which you would then subclass for all of your application methods. Then write a couple of methods like
public Object getModuleAttribute(HttpServletRequest request, String name)
public void setModuleAttribute(HttpServletRequest request, String name, Object attr)
and inside those methods, use RequestUtils to lookup the module name, and then lookup a java.util.Map under a "well-known name" like {module}/MODULE_CONTEXT_MAP and... there you have it.
It's a little bit oblique, but then Modules were kind of retrofitted into the Struts structure. This could probably be made easier in future releases if people had ideas, or even better, patches to the source code!
Joe
--
Joe Germuska
[EMAIL PROTECTED]
http://blog.germuska.com
"We want beef in dessert if we can get it there."
-- Betty Hogan, Director of New Product Development, National Cattlemen's Beef Association
smime.p7s
Description: S/MIME cryptographic signature
