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: > > <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 > -----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 > >
