Problems with commons-beanutils-1.9.4
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 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: [...] 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 2. Set the properties on ToolConfiguration for each 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 -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl47AWoACgkQHPApP6U8 pFjVyBAAvdRdAdtXrprLTvb8yInxLeKv8YYOXIxEcY12VgEcr9bBozd1CIdADZxq bKZhHRyaCJTkmNZ0q9HOX7le8LGHkYhSLh//idcoFFvobvfXXBRvXxWhL1nosH8x xgia0X+LrvKYHYKdwf2fEkYPBRHAyL6VmoYl4b5TN8omKJfQS9c5FWTRSP1luBST DlyV0p17rTrkZq+sZiZt1ErH/sTqTJ8aay9W5uAiXyk7Er7xDlwYPlAibaAL/+Xv 73B5+kNty59PLmUOrCyG66bgxtaxsKMbNgup6XhL0nRz34IhMmWFhFaQ0WD0cuQq 6d2jLrSVogktjdW7mJl+vIvHNJXVi3ywhPSOKRL5zdFLckBVXTFfZu3Id5waCg7k dhftiU7TUXNHkPg8jTmSRJKr+30TIiV2TLvGzlmMvhAclMhQoXNrN5mkry3uvhtT TAcBUZMLxQvQ/vHmT+mPD746OfYrHAID0aExfTsnToM9txhC8svmZw+weGBRJJLY h2vXOSKJE8Uqe8snSLUaw8jzVoDWCWAo65RLgMWpbGSv2xpvYn/gfvG4GDmb7MHX 9IWU3LoFraSifOs39mtqMK/CCl6MFR7Pmp5MKO6p4jxw/17402flfEl0aPhFRRSi wk5Ap8CLg5UQbyUv8Va0j14SVTK7osl7OMCx6aKT2cql5z4+ba8= =GNJs -END PGP SIGNATURE- - To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org For additional commands, e-mail: user-h...@velocity.apache.org
Re: Problems with commons-beanutils-1.9.4
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? On Wed, Feb 5, 2020 at 9:55 AM Christopher Schultz < ch...@christopherschultz.net> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > 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: > > > > > [...] > > > > 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 > 2. Set the properties on ToolConfiguration for each > > 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 > -BEGIN PGP SIGNATURE- > Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ > > iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl47AWoACgkQHPApP6U8 > pFjVyBAAvdRdAdtXrprLTvb8yInxLeKv8YYOXIxEcY12VgEcr9bBozd1CIdADZxq > bKZhHRyaCJTkmNZ0q9HOX7le8LGHkYhSLh//idcoFFvobvfXXBRvXxWhL1nosH8x > xgia0X+LrvKYHYKdwf2fEkYPBRHAyL6VmoYl4b5TN8omKJfQS9c5FWTRSP1luBST > DlyV0p17rTrkZq+sZiZt1ErH/sTqTJ8aay9W5uAiXyk7Er7xDlwYPlAibaAL/+Xv > 73B5+kNty59PLmUOrCyG66bgxtaxsKMbNgup6XhL0nRz34IhMmWFhFaQ0WD0cuQq > 6d2jLrSVogktjdW7mJl+vIvHNJXVi3ywhPSOKRL5zdFLckBVXTFfZu3Id5waCg7k > dhftiU7TUXNHkPg8jTmSRJKr+30TIiV2TLvGzlmMvhAclMhQoXNrN5mkry3uvhtT > TAcBUZMLxQvQ/vHmT+mPD746OfYrHAID0aExfTsnToM9txhC8svmZw+weGBRJJLY > h2vXOSKJE8Uqe8snSLUaw8jzVoDWCWAo65RLgMWpbGSv2xpvYn/gfvG4GDmb7MHX > 9IWU3LoFraSifOs39mtqMK/CCl6MFR7Pmp5MKO6p4jxw/17402flfEl0aPhFRRSi > wk5Ap8CLg5UQbyUv8Va0j14SVTK7osl7OMCx6aKT2cql5z4+ba8= > =GNJs > -END PGP SIGNATURE- > > - > To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org > For additional commands, e-mail: user-h...@velocity.apache.org > >
Re: Problems with commons-beanutils-1.9.4
-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: > > class="org.apache.velocity.tools.generic.AlternatorTool" /> [...] > > > 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 2. Set > the properties on ToolConfiguration for each > > 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 2GjIMMux9oxcnJNd64Xwh
