On Sat, 30 Mar 2002, Struts-dev Newsgroup wrote:
> Date: Sat, 30 Mar 2002 21:10:01 -0800
> From: Struts-dev Newsgroup <[EMAIL PROTECTED]>
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: Multi Struts Config files and path context wish
>
> Subject: Multi Struts Config files and path context wish
> From: Vic Cekvenich <[EMAIL PROTECTED]>
> ===
> Tiles can do multi confi like this, via CSV:
> <init-param>
> <param-name>definitions-config</param-name>
>
><param-value>/WEB-INF/tiles-defs.xml,/WEB-INF/tiles-tests-defs.xml,/WEB-INF/tiles-tutorial-defs.xml,
> /WEB-INF/tiles-examples-defs.xml</param-value>
> </init-param>
> Validator does it like this, multi item:
> <plug-in className="org.apache.struts.validator.ValidatorPlugIn">
> <set-property property="pathname" value="/WEB-INF/validator-rules.xml"/>
> <set-property property="pathname" value="/WEB-INF/validation.xml"/>
> </plug-in>
>
This is actually getting changed as we speak -- it depends on *very*
non-inuitive behavior of the setPathname() method. In a standard
JavaBean, calling setPathname() will always replace the previous value --
this technique would only work if it added each value to a list. If
that's the behavior you want, the method should be addPathname() or
something instead.
> But to have multi config on Struts-config.xml we will require a path?
> The reason I do not want a path is that on a project, it is sometimes
> hard to spearate who is working on what module like that.
> Also, path in url might not be sectioned like that.
> I like how validator and tiles do it a bit better.
>
For multi-app support, I'm going to start with the assumption that we want
to use a path prefix to distinguish the sub-applications (that's the way
many other frameworks do it, it's consistent with how servlet containers
deal with webapps, ...). Given that, we have to communicate two pieces of
information to the controller servlet for each subapp:
- The path prefix for that subapp
- The struts-config.xml file to be used.
The current technique embeds the path prefix in the name of the servlet
initialization parameter, and therefore means it is *not* stored inside
the struts-config.xml file for that subapp. In this way, you can design a
subapp without knowing or caring ahead of time what the path prefix will
be (again, this is consistent with webapp design, where you don't have to
know what the context path will be).
Going to a comma-delimited list of struts-config files gives up this
ability to keep the config files independent of the path - therefore I
don't particularly care for that approach here.
> my 2 c.
> Vic
>
Craig
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
