The course you are now following is probably the best one. Set the application up as a single module, and just given each team a prefix for their actions and page directories, and have them use it as part of their everyday work, rather than let the module code do it. Since multiple configuration files are supported, they can also have their own struts-config file, which is the major source of contention. This way you have full access to the entire Struts feature-set, including path mapping.
The way modules are implemented now makes them very useful when you are deploying two completely independent modules, but less useful when you have teams that are cooperating on the application and also need to share some resources.
That makes sense. I had pretty much come to a similar conclusion. I was not really seeing the benefit of going the fully separated module route, but was frustrated that we could not get it to work.
We would like to support path mapping for the modules, but no one has figured out how to do that yet.
To answer your question about the JSP paths, you can use the forwardPath for this:
http://jakarta.apache.org/struts/userGuide/configuration.html#controller_config
You mean 'forwardPattern'? So just override the default and specify $P instead of $M$P...cool. I will gove that a whirl.
A link to this setting has been added to the "module" section of the user guide, so that it easier to find.
For multiple message resources, I believe you have to give each bundle its own name and then specify that bundle whenever it is to be used. But, the name space trick works here too. It's a simple file and not updated as often as the configs, so CVS can usually sort out any conflicts.
D'oh! I missed that one. So I can do something like:
<message-resources key="mymodule" parameter="resources.mymodule"/>
in one config file and something different in the other:
<message-resources key="othermodule" parameter="resources.othermodule"/>
Then in my JSP, do something like:
<bean:message bundle="mymodule" key="my.message.to.display"/> <bean:message bundle="othermodule" key="other.message.to.display"/>
and it will find the appopriate message in the appropriate bundle. Correct? Cool.
jeff
-Ted.
Jeffrey Bonevich wrote:
I have some questions regarding difficulties we have been having using multiple struts config files and modules at work. Here is the scenario:
We developed our first application in struts after having set some coding standards that seemed (at the time) pretty reasonable. Chief among them for purposes of this discussion is securing access to JSP pages by putting them under WEB-INF. We are in the process of integrating a second struts-based app into the main application, and originally planned to do so as two separate modules. However, I am running afoul of several limitations in the struts module support.
Firstly, we had originally gone with path-mapping for our actions. I figured out from the mailing lists pretty quick that using modules for path-mapped actions is not supported. Is there any plan to build such support into the next or some future release? When?
So I converted the apps to extension-mapped actions and proceeeded. However, I am hitting the "struts prepends module context to every path" wall: I can no longer create forwards to JSP pages in WEB-INF, but instead have to put them in module-specific subdirectories of the document root. Is there any reasonable way around this via the configs? Or do I have to create a custom "JSP page forward" action to handle this particular (but not peculiar) need?
Lastly, since going the module route was proving exceeding difficult, we decided to treat both apps as a single module, but with separate config files for each (as specified in web.xml). However, there appears to be a bug (feature?) in struts with message resource loading - the last set of resources loaded are the only ones that will be present. This appears to be because ModuleConfigImpl holds a hashmap of resource bundles with only a single possible key. As each set is added to the map, it displaces the previously added set. To get around this, I had to merge all properties from both apps into a single properties file - not desireable but it works. All the other parts of the configs (forms, actions, forwards, etc.) all seem to be additively accumulated. Is this exclusive loading of message resources truly a bug? Can't struts handle multiple sets of properties per module?
Answers, suggestions and workarounds would be most welcomed!
Thanx!
jeff
-- Jeffrey Bonevich Ann Arbor, Michigan bonevich at covad dot net jeff at bonevich dot com http://www.bonevich.com
"Make me a fire and I'm warm for a night. Set me on fire and I'm warm for the rest of my life." - Ancient Didactical Saying
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]