On Tue, 19 Jun 2001, Dan Miser wrote:
> 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.
>
Argh, I knew there had to be some fly in the ointment ...
> 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.
That seems like an approach worth considering, since it doesn't break old
struts-config.xml files,
> --
> Dan Miser
> http://www.distribucon.com
>
Craig
> ----- 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
> >
> >
>
>
