Hash: SHA256


(Apologies for the cross-post, but this is a very dev-y response.
After this message in the thread, I will reply only on the dev@ list).

On 2/5/20 1:09 PM, Nathan Bubna wrote:
> Thanks for drilling into that, Chris! I was reading, but have no
> time to help with such things right now. I imagine the beanutils
> folks made that change as a security fix. Probably time for us to
> deprecate/kill the setClass option, if it's unreliable. Any chance
> you're up for that?

Sure. It's easy to do; just drop the method completely.

I might argue for a transitional period where we change setClass() to
either issue a WARN log message or even throw an exception, but anyone
upgrading to commons-beanutils-1.9.4 or later will find that it stops
working and that method never ever gets called, so it's kind of wasted

Anyone upgrading velocity-tools will likely be upgrading
commons-beanutils as well (and vice-versa), so the only people who
need the nudge to change their configurations are those who aren't
likely to upgrade. Again, wasted effort.

So I think just removing the setClass(Class) method is the proper
course of action.

I suspect there is no reason for a 2.0.1 release, so this would be a
change only in 3.0?

3.0 completely dropped support for Struts, which is a requirement for
me, so I don't have any current stake in velocity-tools 3.0. I'm happy
to do the work (delete 4 lines of code; document; commit) but I won't
have anything to test it with other than the existing unit tests.

- -chris

> On Wed, Feb 5, 2020 at 9:55 AM Christopher Schultz < 
> ch...@christopherschultz.net> wrote:
> All,
> This may be an uncommon configuration, but I just upgraded from 
> velocity-tools-2.0 with commons-beanutils-1.9.3 to 
> commons-beanutils-1.9.4 and all my stuff broke.
> I spent a few hours tracking it down and I happened to have my
> toolbox configured like this:
> <tools> <toolbox scope="application"> <tool
> class="org.apache.velocity.tools.generic.AlternatorTool" /> [...] 
> </toolbox> </tools>
> I was getting a message on webapp start that looked like this:
> FactoryConfiguration from 4 sources  with 2 toolboxes: Toolbox
> 'application' with 1 properties [scope -auto-> application; ] and
> 12 tools: Tool 'null' => null
> and some other weird things like:
> Tool 'dateFormat' => null with 1 properties [key -auto->
> dateFormat; ]
> The problem is that I was using the "class" attribute in my XML
> config instead of "classname".
> velocity-tools uses commons-digester, which uses commons-beanutils
> to:
> 1. Create an instance of ToolConfiguration for each <tool> 2. Set
> the properties on ToolConfiguration for each <tool>
> Then velocity-tools tries to instantiate the class you specify, put
> it into the toolbox, etc. The problem is with step #2 above.
> ToolConfiguration has two relevant setters, here:
> public void setClass(Class); public void setClassname(String);
> Before commons-beanutils-1.9.4, setting the "class" attribute in
> the XML would:
> 1. Find the "class" property on ToolConfiguration 2. Use
> Class.forName() to get an instance of java.lang.Class representing
> whatever class you wanted to use 3. Call
> ToolConfiguration.setClass(Class) with that instance of 
> java.lang.Class.
> With commons-beanutils-1.9.4, that process fails at one point or 
> another because commons-beanutils is no longer willing to
> instantiate objects of type java.lang.Class (or no longer willing
> to assign properties of java.lang.Class, it doesn't really
> matter).
> But because ToolConfiguration is designed to accept class names and
> do it's own object instantiation, you can side-step the "problem" 
> introduced by commons-beanutils-1.9.4 by simply using the other 
> attribute: classname
> When you use "classname", commons-beanutils will:
> 1. Find the "classname" property on ToolConfiguration 2. Call
> ToolConfiguration.setClassname(String) with the String value 
> obtained from the XML attribute
> ... and you are good to go.
> I hope nobody else gets bitten by this, but in case you do, there
> is a simple solution.
> -chris
>> ---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org
>> For additional commands, e-mail: user-h...@velocity.apache.org
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/


To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org

Reply via email to