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.

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

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.

-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



-- Ted Husted, Junit in Action - <http://www.manning.com/massol/>, Struts in Action - <http://husted.com/struts/book.html>, JSP Site Design - <http://www.amazon.com/exec/obidos/ISBN=1861005512>.



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to