I can work on getting patches for multiple Struts
configuration files to work.
How should we go about specifying the config files in
the web.xml file? Here's a couple of ideas I have:
1.) Perhaps we could have them named config[x]
replacing "x" with a number. I.e...
<init-param>
<param-name>config1</param-name>
<param-value>/WEB-INF/struts-config1.xml</param-value>
</init-param>
<init-param>
<param-name>config2</param-name>
<param-value>/WEB-INF/struts-config2.xml</param-value>
</init-param>
2.) Change the current "config" parameter to support a
comma delimited list of config files. I.e...
<init-param>
<param-name>config</param-name>
<param-value>/WEB-INF/struts-config1.xml,/WEB-INF/struts-config2.xml</param-value>
</init-param>
What if anything should be done about duplicates
between files? It appears that the current framework
allows duplicates.
As far as the DTD goes I agree wholeheartedly. I
think we should change the root element to <struts>
and change the DOCTYPE to:
<!DOCTYPE struts-config PUBLIC
"-//Apache Software Foundation//DTD Struts
Configuration 1.2//EN"
"http://jakarta.apache.org/struts/dtds/struts-config_1_2.dtd";>
or we can leave it at 1.1, but let people with
existing snapshots know that their DTD is now
deprecated.
-james
[EMAIL PROTECTED]
http://www.ejcenter.com/struts/
--- Ted Husted <[EMAIL PROTECTED]> wrote:
> I agree with Martin, in that I think the most
> important thing is support
> for multiple Struts configuration files.
>
> The other piece to the puzzle is the Service
> Manager, since this lets
> you extend the ActionServlet without subclassing it,
> so that the modules
> could also configure their own services.
>
> These two things together may be able to provide the
> solutions most
> people need when they ask for multiple
> ActionServlets.
>
> Encouraging multiple ActionServlets too soon could
> create a host of
> other problems. It may still be needed in some
> circumstances, but,
> personally, I think multiple configs and pluggable
> services is a cleaner
> approach, that will lead to applications that are
> easier to maintain.
>
> Ideally, it should also be possible to declare the
> validation, services,
> and messages from the same configuration file, to
> allow everything to be
> handled together. It's possible that we need to add
> a root element to
> the file, so that <struts-config> is only part of
> the scheme, and other
> configurations, like <form-validation> can be nested
> within.
>
> <struts>
> <struts-config>
> ..
> </struts-config>
> <form-validation>
> ..
> </form-validation>
> <services>
> ..
> </services>
> <messages>
> ..
> </messages>
> </struts>
>
> Of course, we should continue to et these be loaded
> as separate files
> too, as convenient to the developer.
>
>
> -- Ted Husted, Husted dot Com, Fairport NY USA.
> -- Custom Software ~ Technical Services.
> -- Tel +1 716 737-3463
> -- http://www.husted.com/struts/
>
>
> [EMAIL PROTECTED] wrote:
> >
> > Personally, I am firmly in the second camp
> (reading multiple config files).
> > My reasoning is as follows.
> >
> > I am working on a large project that will result
> in a common framework, and
> > product modules which plug in to that framework.
> The common framework, and
> > all of the product modules, will use Struts.
> Product modules can be
> > installed and uninstalled by our customers.
> >
> > Using some kind of 'include' mechanism solves the
> problem of different
> > product teams stepping on each others' toes when
> editing the Struts
> > configuration. However, it makes installation and
> uninstallation somewhat
> > harder, because those applications will have to
> understand the structure of
> > the Struts configuration file.
> >
> > Using multiple configuration files allows me to
> have one config file for the
> > common framework, and then one more for each
> product. Each product team can
> > concentrate on its own config file, and the
> installer and uninstaller only
> > have to worry about which files to add or remove,
> and not about what they
> > contain or how to modify them.
> >
> > --
> > Martin Cooper
> >
> > ----- Original Message -----
> > From: "James Holmes" <[EMAIL PROTECTED]>
> > To: <[EMAIL PROTECTED]>
> > Sent: Saturday, October 13, 2001 4:29 PM
> > Subject: Re: [PROPOSAL] XMLMessageResources
> >
> > > It seems there has been some discussion in the
> past
> > > about a new config file DTD that would support
> having
> > > "multiples" so that individuals could work on a
> > > particular section without affecting others. It
> seems
> > > there is also the camp that would rather just
> have the
> > > servlet read multiple config files. I am
> indifferent
> > > (at this point) to which solution i think should
> be
> > > adopted, but think that Struts could certainly
> be more
> > > "team development" friendly by choosing one and
> then
> > > offering it. I have some extra bandwith and
> would
> > > like to get involved in the "core" struts
> development.
> > > Craig/Ted/Others, I'd be happy to develop one
> or
> > > both. I guess I'd like to know what people want
> to
> > > see developed and what has the highest
> likelyhood of
> > > being incorporated into Struts and I will
> develop it.
> > >
> > > What about the whole debate on multiple
> ActionServlets
> > > per WAR? If I were to "solve" this would this
> be
> > > something that could go into the core?
> > >
> > > -james
> > > [EMAIL PROTECTED]
> > > http://www.ejcenter.com/struts/
> > >
> > >
> > > --- Ted Husted <[EMAIL PROTECTED]> wrote:
> > > > Can we join this with the idea of having
> multiple
> > > > Struts configuration
> > > > files, or, on a related front, multiple
> workflow
> > > > configuration files?
> > > >
> > > > [EMAIL PROTECTED] wrote:
> > > > >
> > > > > The Struts 1.1 TODO list contains the
> following
> > > > item:
> > > > >
> > > > > "XmlMessageResources. Implementation of
> > > > MessageResources and
> > > > > MessageResourcesFactory that loads message
> keys
> > > > and strings from one or more
> > > > > XML resources or files."
> > > > >
> > > > > I have an implementation of this which I
> would
> > > > like to contribute to Struts.
> > > > > The implementation is a drop-in replacement
> for
> > > > the existing
> > > > > PropertyMessageResources. In fact, it is
> derived
> > > > from it, and so shares the
> > > > > same file naming scheme for locale-specific
> > > > messages.
> > > >
> > > > "SCHACHTER,MICHAEL (HP-NewJersey,ex2)" wrote:
> > > > >
> > > > > Martin,
> > > > >
> > > > > In the jakarta-commons-sandbox, there's a
> folder
> > > > > called "resources" containing Struts
> > > > MessageResources
> > > > > and some other classes that I was working
> on, but
> > > > had
> > > > > to put off for a while.
> > >
> > >
> > >
> __________________________________________________
> > > Do You Yahoo!?
> > > Make a great connection at Yahoo! Personals.
> > > http://personals.yahoo.com
__________________________________________________
Do You Yahoo!?
Make a great connection at Yahoo! Personals.
http://personals.yahoo.com
