Am 2018-04-25 um 09:54 schrieb Claude Brisson:
Any thoughts on this? From my side, apart from this potential point, the
tools are ready.
There are several issues I have noticed which I'd like to have resolved
before 3.0. I won't be able to comment on before the end of the next week.
Michael
On 22/03/2018 01:25, Claude Brisson wrote:
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]
---------------------------------------------------------------------
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]
