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 <cla...@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 <
> > 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
> >>
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
> For additional commands, e-mail: dev-h...@velocity.apache.org
>
>
