31 Jul
2007
31 Jul
'07
2:44 p.m.
Hi Sergiu,
I don't understand why one must move log4j and
ehcache configuration
out of the jar. Anyway, log4j should be moved to WEB-INF/classes, for
easy access to the logging configuration.
This is simply a packaging preference. You could edit log4j.properties
inside xwiki.jar (any modern Zip tool such as 7-Zip will do this) but I
prefer to have all configuration files I may want to change outside jars.
I also don't understand why is the access
restricted to WEB/INF... The
configuration is usually there, right? Anyway, I think the latest
version of the code does not need this, but I'm not sure. By the way,
what version of XWiki are you using?
I'm using 1.0. The access restriction for /WEB-INF solve a bug in the
way XWiki looks for its own configuration files. The way it looks for,
you get a SecurityException whenever the Web Container is running inside
a SecurityManagerm such as when Tomcat is started with the "-security"
flag. See my other post, where I provide a JSP page with a snipset of
XWiki code and show you how it could be changed to work correctly with a
security manager.
Regarding log4j.appender.file.File, this is what
should be done
anyway, as I don't like having the log file right in the application
directory. It should be in a directory for logs, either the one in
tomcat, or the one for all system logs (on linux it's /var/log/). I
always change the location to /tmp/xwiki.log. I don't know how can
log4j be configured to use one of these directories regardless of the
platform, since c:\ and tomcat-5.5.23 are very unstable properties to
place in there.
I tried to use system properties to point to the log file location, but
this didn't work. So far I'm stuck with a system-dependent absolute
pathname. :-(
Regarding the reflection permissions, I think actually
Velocity is
responsible for this. I found
http://issues.apache.org/jira/browse/VELTOOLS-66 stating that it
cannot access classes defined in the container, only those included in
JARs. We should find all the classes that are used directly and make a
wrapper for them, as the wrapper would work fine, even if it does not
do anything other than forwarding the call.
See:
http://struts.apache.org/2.0.6/docs/sunone-70.html
http://forums.theplanet.com/lofiversion/index.php/charts/t35104.html
http://garethevans.blogspot.com/2005/06/fun-with-tomcat-and-its-default.html
Those state that Struts itself needs reflection permissions. And it
looks like other popular frameworks like Hibernate and Spring also need it.
Now my ISP state it cannot provide such a permission, because Java SE
docs (See jdk-1_5_0-doc/docs/guide/security/permissions.html) states that:
"|suppressAccessChecks: |/Extreme caution should be taken before
granting this permission to code/ ... This is dangerous in that
information (possibly confidential) and methods normally unavailable
would be accessible to malicious code."
To be honest, I don't think this would be a problem as most popular
framework rely on it. As far as I know Java and other web environments,
every installation of mod_php and mod_perl under Apache or IIS would be
subject to the same risks. But I need arguments to convince my ISP, any
help would be apreciated.
My ISP also uses http://jira.xwiki.org/jira/browse/XWIKI-348 and
http://www.xwiki.org/xwiki/bin/view/AdminGuide/InstallationTomcat as
"proof" that XWiki can't run on shared hosting. :-( Maybe some XWiki
developer can fix those docs so they don't state anymore that shared
hosting is impossible, but instead that it just requires proper
configuration, like any application would need when the Security Manager
is on.
[]s, Fernando Lozano