-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Nathan,
(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 effort. 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 >> >> > -----BEGIN PGP SIGNATURE----- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl48LZYACgkQHPApP6U8 pFh0OBAAnFBWGITPXf8wc3nTgRZnvUknwNqgems6vmCELUbKeQWIUDfrNNuW5n73 ZDs2mwZVQOXYf0wc8bOALSHqdNdizSlHILl3OlKe5+mXUFTCGdVzWwsANveAndeV jvsc8wTGyEG54Zn//pCPCWeZvHVB2IHQAOJZvQz1k/2hAGlWajRH1mVm1zpX+c3m WTpnp6UQy64V5JRimXiLZaISbN0L1ilYBX+TO/o9Qcx/q1IQMh0ByNLqtbg+vQrB Z1HizlcajdKZwFscOnBIwfJo7fRPs/e6dYKlMh0TWLNhRUBzGRJO1c4fQTlAH8zJ +u9mVlPl9pFDa8Zbjhs0zVwpxjtSoZqGU+QUJy9+6ksIZVhMfwFRFsOvE5EP2mO3 OPz1nL6G8DkMFoniEet9D1Vhb6ApF+0NxZ5ASTb4Fpurq3B098G3kjQo2xxsSIw0 2GjIMMux9oxcnJNd64XwhpTcXgRW5w04KD/QF1O+wkgW3NJ8MxCUn75MMB+rhv2b iL4/jycPjcdKL54NsMMgZQ0aVjHIG//vavYqs1EZQtmlCfAirPRpW8r4dxnleFs8 LvQq+SAAOvXURjeZdkQAOfsMXvbNe9QoFZnNhnEjSBbE/vh5UHafHv9oDVL2jTxK nxRZw+IWYernMhurvaB/1ksdoZWo+chDSdaa06PtppG+e+aPDVw= =Gxhj -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
