You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@velocity.apache.org by Christopher Schultz <ch...@christopherschultz.net> on 2020/02/05 17:54:51 UTC
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:
<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-unsubscribe@velocity.apache.org
For additional commands, e-mail: user-help@velocity.apache.org
Re: Problems with commons-beanutils-1.9.4
Posted by Nathan Bubna <nb...@gmail.com>.
I should have noticed i was responding on the user thread. Sorry. Taking
this just to dev, since users probably won't need to hear my response.
If you're willing to commit the change for 3.0, even though you don't use
it, that'd be great. I think you are right that just yanking the code and
documenting it in the changelog makes sense. And yeah, this alone is
probably not worth a 2.0.1 release, so i guess leave it be.
Thanks, Chris!
On Thu, Feb 6, 2020 at 7:15 AM Christopher Schultz <
chris@christopherschultz.net> wrote:
> -----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 <
> > chris@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-unsubscribe@velocity.apache.org
> >> For additional commands, e-mail: user-help@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: user-unsubscribe@velocity.apache.org
> For additional commands, e-mail: user-help@velocity.apache.org
>
>
Re: [OT] Problems with commons-beanutils-1.9.4
Posted by Mike Kienenberger <mk...@gmail.com>.
I'm still maintaining a project using a Velocity 1.8-snapshot and struts.
If I recall, I think the lack of a path forward for struts was why I did
not upgrade to 2.x.
But I'm also stuck with an ancient version of struts, so my situation may
be unique.
On Sat, Mar 14, 2020 at 9:47 AM Christopher Schultz <
chris@christopherschultz.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Claude,
>
> On 2/7/20 02:09, Claude Brisson wrote:
> > On 20-02-06 16 h 15, Christopher Schultz wrote:
> >
> >> 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.
> >
> > Does it also mean that you are stuck with Velocity 1.7?
>
> Yes.
>
> > I'm pretty sure that the struts tools could be easily upgraded to
> > work with tools 3.x, but they should probably be hosted by the
> > struts project...
>
> That would be nice, but I don't know if there is any appetite over
> there to take-on this project.
>
> I might be able to find time to maintain it myself, but I'd want to
> make sure at least a few other people in that community cared enough
> to keep it going, too.
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
>
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl5s4GIACgkQHPApP6U8
> pFhsmw/9ENxOVTd93a6Mt2353ITH9FVrFWdmGGrPxtL/HKL8CNKoG+Xy1HCoczOW
> vVpkX2aCu4MNllKO6I+zV6OE6k6aKFsnpgbycPHkodL1qmk9U9lNlIoGLhcYRvrV
> ACqn+Yety3J4Tem4gIbPTCmpAtLvyEquJqY11yLDvDdg3De4uVMuyqQAccr9s1v7
> 8+n5QwqShXd+TTmj+bFWaPrig9uuNy7h3R6tmxNdLmqrk2fs4trfFGbHbcUS5lwH
> ycamhSFHl7OHXc2/4M3tAYMt4pV3fKyvBsni0/l1VnXmQyu5o6XqdZHPstGaOAeL
> xRr2x4GtaCItKEr3jo+Gwz8Z8jZhBiCsD1TbbPQBPXcmK71GAXY7+i9XrpwuvMEW
> KRzgijCpXE3IRkcRt9bGTFMRW6SDyTcZkCH9eg+c/m6WTD1tf4FSZGSrpoqIUA/0
> PXyc2gtw3ez0M8qTA3FDiKIu9T7vMLeBC/SoSudjwWwJFgu5POb5bi74PpqIasFe
> xWBoelzd2qcVvgo4F1hctZ2JQdL+jkAzHY5la3DjVE8L5MXX75fUUsJezRhFhCKQ
> 2BtzjeijH48cAFjlJi/1PGsN9TF/aZnGocYlazHIjvAz8sJbRjc2f+FPhRQzNjBW
> sStpMTeQ2NL3KhYh6jX3y99+5Cxf4+Nx23d7RKRi4TNVL/BpmeE=
> =QNg+
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
> For additional commands, e-mail: dev-help@velocity.apache.org
>
>
Re: [OT] Problems with commons-beanutils-1.9.4
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Claude,
On 2/7/20 02:09, Claude Brisson wrote:
> On 20-02-06 16 h 15, Christopher Schultz wrote:
>
>> 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.
>
> Does it also mean that you are stuck with Velocity 1.7?
Yes.
> I'm pretty sure that the struts tools could be easily upgraded to
> work with tools 3.x, but they should probably be hosted by the
> struts project...
That would be nice, but I don't know if there is any appetite over
there to take-on this project.
I might be able to find time to maintain it myself, but I'd want to
make sure at least a few other people in that community cared enough
to keep it going, too.
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl5s4GIACgkQHPApP6U8
pFhsmw/9ENxOVTd93a6Mt2353ITH9FVrFWdmGGrPxtL/HKL8CNKoG+Xy1HCoczOW
vVpkX2aCu4MNllKO6I+zV6OE6k6aKFsnpgbycPHkodL1qmk9U9lNlIoGLhcYRvrV
ACqn+Yety3J4Tem4gIbPTCmpAtLvyEquJqY11yLDvDdg3De4uVMuyqQAccr9s1v7
8+n5QwqShXd+TTmj+bFWaPrig9uuNy7h3R6tmxNdLmqrk2fs4trfFGbHbcUS5lwH
ycamhSFHl7OHXc2/4M3tAYMt4pV3fKyvBsni0/l1VnXmQyu5o6XqdZHPstGaOAeL
xRr2x4GtaCItKEr3jo+Gwz8Z8jZhBiCsD1TbbPQBPXcmK71GAXY7+i9XrpwuvMEW
KRzgijCpXE3IRkcRt9bGTFMRW6SDyTcZkCH9eg+c/m6WTD1tf4FSZGSrpoqIUA/0
PXyc2gtw3ez0M8qTA3FDiKIu9T7vMLeBC/SoSudjwWwJFgu5POb5bi74PpqIasFe
xWBoelzd2qcVvgo4F1hctZ2JQdL+jkAzHY5la3DjVE8L5MXX75fUUsJezRhFhCKQ
2BtzjeijH48cAFjlJi/1PGsN9TF/aZnGocYlazHIjvAz8sJbRjc2f+FPhRQzNjBW
sStpMTeQ2NL3KhYh6jX3y99+5Cxf4+Nx23d7RKRi4TNVL/BpmeE=
=QNg+
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
Re: Problems with commons-beanutils-1.9.4
Posted by Nathan Bubna <nb...@gmail.com>.
Or maybe even just put a 3.x compatible version of the Struts tools up on
github as an independent fork. Probably easier than talking the Struts devs
into it.
On Thu, Feb 6, 2020 at 11:10 PM Claude Brisson <cl...@renegat.net.invalid>
wrote:
> On 20-02-06 16 h 15, Christopher Schultz wrote:
>
> > 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.
>
> Does it also mean that you are stuck with Velocity 1.7? I'm pretty sure
> that the struts tools could be easily upgraded to work with tools 3.x,
> but they should probably be hosted by the struts project...
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
> For additional commands, e-mail: dev-help@velocity.apache.org
>
>
Re: Problems with commons-beanutils-1.9.4
Posted by Claude Brisson <cl...@renegat.net.INVALID>.
On 20-02-06 16 h 15, Christopher Schultz wrote:
> 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.
Does it also mean that you are stuck with Velocity 1.7? I'm pretty sure
that the struts tools could be easily upgraded to work with tools 3.x,
but they should probably be hosted by the struts project...
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
Re: Problems with commons-beanutils-1.9.4
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----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 <
> chris@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-unsubscribe@velocity.apache.org
>> For additional commands, e-mail: user-help@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-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
Re: Problems with commons-beanutils-1.9.4
Posted by Claude Brisson <cl...@renegat.net.INVALID>.
On 20-02-07 17 h 44, Nathan Bubna wrote:
> As for setClass(Class cls), couldn't we just change it to:
>
> public void setClass(String classname) {
> setClassname(classname);
> }
>
> Seems like that would keep the class="org.com.Foo" config syntax working
> and avoid the security issue, right?
Nah, because what happens is that the "class" property is filtered
beforehand by beanutils introspector.
What I did is provide the xml digester with a alias, mapping "class"
towards "classname".
I'm gonna push your suggestion also, though, as it might help for other
configuration methods when running under a security manager.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
Re: Problems with commons-beanutils-1.9.4
Posted by Nathan Bubna <nb...@gmail.com>.
Yeah, moving to jetty-maven-plugin would be good. I use that heavily at
work.
As for setClass(Class cls), couldn't we just change it to:
public void setClass(String classname) {
setClassname(classname);
}
Seems like that would keep the class="org.com.Foo" config syntax working
and avoid the security issue, right?
On Thu, Feb 6, 2020 at 10:52 PM Claude Brisson <cl...@renegat.net.invalid>
wrote:
> Hi.
>
> I suspect the class= problem only happens when running under a security
> manager. I had set up the cargo maven plugin to run the showcase example
> under a security manager, but it was failing under window so for now
> it's commented in the showcase pom file.
>
> There are several other problems with the cargo plugin:
> - version 1.6.x tries to download jetty using http rather than https,
> which now fails since maven2 repository now requires https
> - version 1.7.x fixes the problem but gives a "Could not find or load
> main class" error when trying to launch jetty, I didn't investigate why
> - jetty is never cached (other than in /tmp) and downloaded each time
> (why on earth isn't cargo using the maven repository?!)
>
> and IMO the roadmap is to just drop cargo: anyone wanting to test the
> showcase webapp using another container can just do it with the .war
> file, we can switch to directly using the jetty-maven-plugin, without
> the added complexity of a generic J2EE container manager.
>
> I wonder if just dropping the method is enough: anyone with an old
> format configuration will have trouble identifying the cause of the
> problem. Isn't there any way to tweak beanutils into binding class= to
> setClassname() ?
>
>
> Claude
>
> On 20-02-05 19 h 09, 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?
> >
> > On Wed, Feb 5, 2020 at 9:55 AM Christopher Schultz <
> > chris@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-unsubscribe@velocity.apache.org
> >> For additional commands, e-mail: user-help@velocity.apache.org
> >>
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
> For additional commands, e-mail: dev-help@velocity.apache.org
>
>
Re: Problems with commons-beanutils-1.9.4
Posted by Claude Brisson <cl...@renegat.net.INVALID>.
Hi.
I suspect the class= problem only happens when running under a security
manager. I had set up the cargo maven plugin to run the showcase example
under a security manager, but it was failing under window so for now
it's commented in the showcase pom file.
There are several other problems with the cargo plugin:
- version 1.6.x tries to download jetty using http rather than https,
which now fails since maven2 repository now requires https
- version 1.7.x fixes the problem but gives a "Could not find or load
main class" error when trying to launch jetty, I didn't investigate why
- jetty is never cached (other than in /tmp) and downloaded each time
(why on earth isn't cargo using the maven repository?!)
and IMO the roadmap is to just drop cargo: anyone wanting to test the
showcase webapp using another container can just do it with the .war
file, we can switch to directly using the jetty-maven-plugin, without
the added complexity of a generic J2EE container manager.
I wonder if just dropping the method is enough: anyone with an old
format configuration will have trouble identifying the cause of the
problem. Isn't there any way to tweak beanutils into binding class= to
setClassname() ?
Claude
On 20-02-05 19 h 09, 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?
>
> On Wed, Feb 5, 2020 at 9:55 AM Christopher Schultz <
> chris@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-unsubscribe@velocity.apache.org
>> For additional commands, e-mail: user-help@velocity.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
Re: Problems with commons-beanutils-1.9.4
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----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 <
> chris@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-unsubscribe@velocity.apache.org
>> For additional commands, e-mail: user-help@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: user-unsubscribe@velocity.apache.org
For additional commands, e-mail: user-help@velocity.apache.org
Re: Problems with commons-beanutils-1.9.4
Posted by Nathan Bubna <nb...@gmail.com>.
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 <
chris@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-unsubscribe@velocity.apache.org
> For additional commands, e-mail: user-help@velocity.apache.org
>
>