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