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() ?


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 <
ch...@christopherschultz.net> wrote:

Hash: SHA256


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:

   <toolbox scope="application">
     <tool 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 <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

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
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/


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

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

Reply via email to