On 26-Oct-06, at 8:38 PM, Adam Winer wrote:
On 10/26/06, Stefan Podkowinski <[EMAIL PROTECTED]> wrote:
My case for creating the patch was that some frameworks require to
have config files in the classpath, so we decided to just put all of
them there, incl. spring etc. This convention also works for creating
standalone apps where no web-inf directory is available. I think it
should just be up to the developer to decide. In fact, I've only came
accross two frameworks so far that insisted on the web-inf location,
which is sitemesh (patch available through jira on this) and trinidad
(same as well now ;))
Actually, it's probably many more than that. Many, many
J2EE web frameworks, component libs, etc. just do all of their
configuration in WEB-INF/web.xml. That counts as insisting
on WEB-INF to me!
Since we are strictly a webapp framework - there is no
such thing as "standalone Trinidad" - it's hard to see
any developer gain from moving it around within the file
system. Auto-loading from the classpath - supporting both
WEB-INF/trinidad-config.xml in the webapp and
META-INF/trinidad-config.xml on the classpath - is a
more potentially useful feature, esp. since we could pretty
easily support precedence rules where WEB-INF wins.
Personally, I like to (at least have the option to) collect config
files in a sub-directory of WEB-INF. In a large app, there's plenty
of other stuff that has to live under WEB-INF, and keeping config
files seperated out into a sub-directory (or even several sub-
directories) can help keep things organized.
I don't see a good reason not to at least make this an option. The
tool-vendor argument doesn't carry much weight for me; tools only
need to do a tiny bit more work, and the framework feature set should
be driven by how it will be used, not by how it might be supported in
some tool chain or other.
+1 to having this configurable.
--
Laurie Harper
Open Source advocate, Java geek: http://www.holoweb.net/laurie
Founder, Zotech Software: http://www.zotechsoftware.com/
