Craig,
There are a few problems with that approach:
1. If you just have multiple <struts-config> elements, you end up not having
a root element. That will cause the Digester to throw an exception when
starting up.
2. So I added an element named <root> and put multiple <struts-config>
elements under the root. The problem then becomes the code in the
ActionServlet is looking for struts-config to be the root element.
3. Next, I extended the ActionServlet and overrode the initDigester method,
changing the calls in the digester to reference */struts-config everywhere.
That would work, but AddDataSourceRule is a private class, so I had to copy
that from ActionServlet.
After changing web.xml to use my new ActionServlet, I was able to get a
"module" approach with a reorganized struts-config.xml from struts-example
(I broke it up into global, login, registration, subscription, and admin).
Worked beautifully. Of course, the struts-config.dtd would need to reflect
this rework too.
--
Dan Miser
http://www.distribucon.com
----- Original Message -----
From: "Craig R. McClanahan" <[EMAIL PROTECTED]>
> I haven't actually tried this, but conceptually it should work -- could
> someone please try it and confirm to the list?
>
> The basic thought is that a single struts-config.xml file can actually
> have more than one <struts-config> section in it. Given, this you can
> logically divide your overall configuration into "modules" or whatever,
> and have each development group maintain their own stuff in their own
> struts-config.xml file. Then, when you deploy the app, part of the
> process would be simply combining all the struts-config.xml files into a
> single one (simple concatenation).
>
> It's worth a shot ...
>
> Craig
>
>
