Am 2018-03-21 um 06:17 schrieb Christopher Schultz:
All,

Using velocity-tools 2.0.

I've been exploring what it takes to get my application working under a
SecurityManager and it seems that o.a.v.t.view.VelocityView tries to
load a few configuration files from their default locations even when a
specific configuration file has been specified by a subclass like
VelocityLayoutServlet:

   <servlet>
     <servlet-name>velocity</servlet-name>
     <servlet-class>
       com.chadis.web.servlet.VelocityLayoutServlet
     </servlet-class>

     <init-param>
       <param-name>org.apache.velocity.tools</param-name>
       <param-value>/WEB-INF/tools.xml</param-value>
     </init-param>
   ...


What ends up happening is that VelocityView checks for the default
configuration files tools.xml and tools.properties (in the current
working directory) and so FilePermissions must be given to the whole JVM
-- because VelocityView (or ConfigurationUtils) doesn't make the attempt
in a PrivilegedAction.

I think this can be done in a more friendly way, but I'm not sure what
is best for the community.

We could add a PrivilegedAction to the mix when a SecurityManager is
present. This way, the velocity library could be granted read access to
these specific files (instead of the whole JVM). This would impact the
smallest number of users.

We could remove the attempts to load these configuration files out of
the CWD. This would probably affect the largest number of users
(although relying on the CWD to find a default configuration file is ...
bad practice).

Or we could change the way Velocity*Servlet use VelocityView so that
default configuration files are only loaded when there is no explicit
configuration file.

Thoughts?

Personally, I was never a huge fan of this autoconfig. It was overly comples. A few only understood. This also lead to subtile bugs which Maven Doxia leaving them open for years which I finally fixed last year.

I would personally expact an empty toolbox present, if nothing has been configured by the user. Even if this will break stuff, we can do so for 3.0 with ease. See https://issues.apache.org/jira/browse/DOXIASITETOOLS-93.

Michael

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to