Niall,
(First, let me say that I'm very happy to see such a great response so fast. I really appreciate the time you took to research my problem and make suggestions. I expected to suffer several rounds of "go away and complain to the velocity tools guys" before getting anything useful. Thanks!)
I have to say I don't use velocity and so I don't really understand how your using Struts without an Action, but anyway here goes...
Well, what's really going on is that I'm using a utility that should be able to grab a global-forward from the struts configuration. I figured that getting that value would be independent of the request actually being touched by the Struts controller at some point.
When modules were introduced in Struts 1.1 ActionServlet was modified so that every time a request was processed it stores the ModuleConfig as a parameter in the request under the key Globals.MODULE_KEY [if you look at the ActionServlet.process() method it calles RequestUtils.selectModule() which does this].
I noticed this, and it became part of my hacked solution (which was actually hacked into velocity-tools, not struts). Velocity tools does not mention its (in-)compatibility with either Struts 1.0 or Struts 1.1., so I figured it would be compatible with both. That is, velocity tools 1.0 seemed to work fine with struts 1.0 /and/ 1.1, so it follows that an upgrade from that should also work with struts 1.1.
I understand you saying (paraphrasing) "if the ModuleConfig is not in the request scope it should use the application scope" in your context, but in a Struts 1.1 context then it should be there and Struts code relying on that seems reasonable to me. What seems strange to me is that you are using Velocity's Struts tools outside of Struts.
I guess I look at it from the other side of the fence (literally, I guess): I want Struts to give me information about its configuration, and it seems like it should give up that information whether or not I've actually sent my request through the ActionServlet.
However if thats a valid use case in the Velocity world then maybe a change to the Velocity tools to call the RequestUtils.selectModule() method as the ActionServlet does would be the best approach.
Honestly, I'm not sure whether or not this counts as a "valid use case in the velocity world". Since the velocity-tools site doesn't specifically state that use of the Struts* tools /requires/ the ActionServlet, though it shows a diagram which has ActionServlet handling the request and then forwarding to the VelocityViewServlet (the one that handles requests for velocity templates).
Here's a good question: If I were to use the <struts:forward> tag from the Struts taglib, and hit that JSP directly without going through a Struts action, should I expect the same behavior? If so, then I'm just breaking the rules and should shut up :)
Short term I guess without going through ActionServlet you have to get the default module config stored in the request under the appropriate key.
This is exactly my hacked solution. It's funny... the method that calls RequestUtils.forwardURL actually obtains the ModuleConfig in the very first line of the method:
ModuleConfig moduleConfig = RequestUtils.getModuleConfig(request, app);
My solution was to add this code immediately before the call to RequestUtils.forwardURL:
if(null == request.getAttribute(Globals.MODULE_KEY))
request.setAttribute(Globals.MODULE_KEY, moduleConfig);This seems to emulate the requirements that the ActionServlet fulfills. I'll look into what AcionServlet does to see if there are any other laws I'm breaking. I want to make sure that I'm not just getting lucky, here, and not risking some other instabilities.
Thanks again for the great reply!
-chris
signature.asc
Description: OpenPGP digital signature
