Yes, it'd be great to soon release the tools since the engine is out.
And yes, autoconfig hasn't to be the default. Why not starting with an
empty toolbox by default if it eases things for integrators. But there
are two different things here:
1) *default* tools (loaded from tools.xml files inside each
velocity-tools jar)
2) *standard* user toolbox configuration files
For 1), what about a "load-default-tools" param in the descriptor? (As
usual, we would first check init-params for the concerned servlet/filter
and then, if not found, the context-params). It can be false by default
for 3.0, if you guys think that that's the way to go. As long as we
diligently document it when releasing.
For 2), I'm pretty sure no standard configuration file should be ever
checked if an explicit configuration is provided, of course (but, by the
way, why is it problematic whenever those files aren't there? Oh, I see,
the SecurityManager doesn't want me to read files that do not exist,
funny but perfectly logical). Would it be harmful to still check for
those standard locations whenever no explicit location is given be
harmful (other than itching the SecurityManager)?
So if I understand correctly, we *also* need to use PrivilegedActions.
Does it boils down to wrapping system calls in
AccessController.doPrivileged() calls? Where and how are those calls
authorized? Sorry, I never used the PrivilegedActions and
SecurityManager paradigm yet. If you have some good pointers or
suggestions...
I don't really understand either why we're speaking of the CWD whereas
all the VelocityView knows is the webapp root. But I may have missed
something.
Claude
On 21/03/2018 22:23, Nathan Bubna wrote:
If we're talking 2.x, then adding a PrivilegedAction sounds better. If 3.0
(which, i think needs to happen anyway, right Claude?), then i'd agree with
Michael. The auto config would be better off as something users need to
explicitly turn on, not the default any longer.
On Wed, Mar 21, 2018 at 2:03 PM, Michael Osipov <[email protected]> wrote:
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
