RE: Splitting struts-config into multiple jar and read them as re source stream

[Tom Drake <To...@tavant.com>]

Yes, but concrete mechanisms for (re-)loading configurations could be
pluggable, and therefore optional. One can imagine storing struts config
files in a central database, and providing a loader that could load / reload
them from there. The location of the configuration files doesn't seem to be
very important to struts at the end of the day, just that the information is
loaded.

-----Original Message-----
From: Craig R. McClanahan [mailto:craigmcc@apache.org] 
Sent: Wednesday, March 24, 2004 12:52 AM
To: Struts Developers List
Subject: Re: Splitting struts-config into multiple jar and read them as
resource stream


Quoting Martin Cooper <ma...@apache.org>:

> On Tue, 23 Mar 2004, Martin Cooper wrote:
> 
> > On Tue, 23 Mar 2004, Craig R. McClanahan wrote:
> >
> > > Quoting Ted Husted <hu...@apache.org>:
> > >
> > > > On Tue, 23 Mar 2004 11:53:55 +0100, Filippo Munafò wrote:
> > > > > Perfect! What you did in JSF is exatcly what we need:
> > > > >
> > > > > "the controller servlet automatically recognize 
> > > > > 'META-INF/struts- config.xml' resources in any JAR files that 
> > > > > were included in the application."
> > > > >
> > > > > When in struts?
> > > > >
> > > > > Can I help?
> > > >
> > > > I think we do the same sort of thing in Commons Chain, n'est 
> > > > pas?
> > > >
> > >
> > > This particular functionality was in relationship to automatically
> finding and
> > > loading struts-config.xml files (contributed by JAR files dropped 
> > > in to
> the
> > > WAR) without having to explicitly note them in context init 
> > > parameters.
> It
> > > doesn't really relate to per-request processing.
> > >
> > > I can't do this today, but anyone who wants to help on this need 
> > > only
> submit an
> > > enhancement request (with a patch) to ActionServlet.init() to scan 
> > > the configuration resources in addition to what it already does.  
> > > The secret
> sauce
> > > is to use ClassLoader.findResources() to get the list of URLs to 
> > > be
> processed.
> >
> > Before anyone does dash off and write this, I'd like to have a brief 
> > discussion about this in relation to multi-module applications, and 
> > removing any need to modify web.xml when adding or removing modules. 
> > This is something I did in a project about a year ago, very 
> > successfully, so I think it's worth adding to the Struts core.
> 
> So the earlier suggestion / idea was to automatically scan for a 
> Struts config file in a jar's META-INF. This is a nice idea, but by 
> itself, it doesn't work in a multi-module application. The problem is 
> that each module has its own config file, and that config file does 
> not include the name of the module (and neither should it, IMHO).
> 
> The approach I have used in the past is to create the following 
> structure within the web app:
> 
>   WEB-INF/
>     modules/
>       default/
>         config/
>           struts-config.xml
>           ... other config files ...
>         jsp/
>           ...
>       moduleX/
>         ...
>       moduleY/
>         ...
>       ...
> 
> I subclassed ActionServlet so that I could reimplement the config 
> locating code, but it actually wasn't much work at all.
> 
> The really cool thing about this approach is that adding or removing a 
> module is as simple as adding or removing files and directories. Not 
> one file needs to be edited. This is great for those of us who don't 
> trust installers to do the right thing. ;-)
> 
> > In a similar vein, I'd like to talk about separating out the config 
> > reading somewhat, to allow for alternative mechanisms.
> 
> The point here is that it should be possible to configure Struts in 
> any of the following ways:
> 
> * Just what we do today, reading the file names from web.xml.
> * Auto-locating the config file from META-INF (for 1-module apps).
> * The above-described mechanism for multi-module apps.
> * Not using Digester at all, possibly not even using XML files.
> 
> What do people think?

The only important con I can think of is that you'd need a Servlet 2.3 or
later platform for this to actually work (in order to gain access to
ServletContext.getResourcePaths()).  Other than that, it's perfectly
reasonable (and certainly reasonable for Struts 2.x).

> 
> --
> Martin Cooper

Craig


---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org