Most everything knows how to get at the configuration for the default module. You see, most configuration data is available in two places: 1) application scope under a combination of whatever the key is that identifies that given piece of data -- plus a module identifier. 2) in request scope [if you go through the controller] under the key identifying that piece of data, but without the module identifier.
Some things will go on to app scope and pull things from there. The data you're working with if you don't go through the controller to get at things (ie. you don't go through an action to get at your JSP pages) will be the data for the main (default) module. Only by going through the controller (ie. invoking pages through actions) will the controller have the opportunity to determine which module is being invoked and place the data relevant to that module in the request. That's why things work as expected if you put your configuration into the default config file.
Still clear as mud?
RULE: Always go through the controller. (always use an action to get at a JSP) This is a really strong recommendation for folks not using modules, but it really becomes an absolute must when you are using modules. Sorry, but there's no way go get around it without rewriting Struts to be a filter instead of a servlet (... which might possibly happen in Struts 2.x.x - we've speculated on this point)
You can let yourself get carried away with it like a lot of folks do and hide your JSPs off under WEB-INF, if you like (TONS of folks do this, and I've taken to it as well). This will make it impossible to access a resource unless you go through an action. This both ensures that the user can't inadvertantly access the page directly, and ensures you write an action to reach it. It's really a handy trick on a lot of levels.
Users can bookmark actions just like they can pages. They're just storing the URL. Yes, you'll have to have request parameters cluttering your URL, but it can be done. They can handle it (or, I should say, the browser can) just fine. I can't count the times I've saved queries on pricegrabber.com -- same principle.
I haven't examined your files yet. Sorry, but I really don't have time right now :-( What I would do if I were you is to make everything go through an action and see if you're still having problems. If you're always going through the controller, everything should always be A-OK. If you do continue to have problems once you've fixed your application to act as I have stated, please do let us know.
Here's another perspective: If you don't go through the controller, how is the page supposed to know which module you're invoking it from? I guess you could hard-code it -- and you could actually get at your configuration data (study source code and user guide) if you knew which module you were in. Unfortunately, without hard-coding it or going through the controller, there's no way a page has a clue which module it's a part of. That information is something that is perculiar only to your Struts configuartion - and the controller is the only one capable of changing which module you're in. Is it becoming any clearer why this is a requirement?
If we ever do swap over to having the controller be a filter instead of a servlet, we'll be able to tell very easily if a JSP lives in a certain module and will be able to go directly to pages if we so choose. Until then, you've simply got to get over whatever reasons you have for not prefacing all pages with an action and ... like Nike would say ... "Just Do It!"
HTH!
Eddie
-- Eddie Bush
Many thanks for the explainations. Things like this are not present on tutorials on Net. It must be time for me to buy a big book about Struts ;)
I see the need to place the JSP under WEB-INF directory, but is it possible, according recommandations, to let a minimum of JSP out of the WEB-INF directory for the front pages of a webapp ?
However, I'm going to follow your recommandations to make those modules work. Don't waste time on it, I'll bother you only if it's still not working :)
Thomas
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
