Thanks.
It made me think that we could also rely on annotations to replace the
tools autoloading feature. It should have a declarative step, like
enabling an o.a.v.v.AutoLoad, so that @Scoped tools are loaded in their
respective toolboxes.
On 06/21/2018 03:07 AM, Nathan Bubna wrote:
Thanks
Thanks, Claude! This looks great!
On Wed, Jun 20, 2018 at 5:50 PM Claude Brisson
wrote:
> I reviewed the configuration process of the VelocityView, and it's now
> much pickier about files i/o (no more CWD accesses), plus doing sensible
> accesses via privileged actions.
>
> I activated Java Secu
I reviewed the configuration process of the VelocityView, and it's now
much pickier about files i/o (no more CWD accesses), plus doing sensible
accesses via privileged actions.
I activated Java Security for the showcase example (ran by the cargo
maven plugin), and it's running with this policy
On 04/25/2018 07:43 PM, Michael Osipov wrote:
Am 2018-03-22 um 01:25 schrieb Claude Brisson:
Yes, it'd be great to soon release the tools since the engine is out.
And yes, autoconfig hasn't to be the default. Why not starting with
an empty toolbox by default if it eases things for integrators
Thanks.
I didn't find online any good example of running some tests under a
custom securiy manager.
Is this documentation relevant?
http://maven.apache.org/surefire/maven-surefire-plugin/examples/junit.html#Using_a_Security_Manager_All_providers
--
Claude
On 05/07/2018 10:03 PM, Christo
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Claude,
On 3/21/18 8:25 PM, Claude Brisson wrote:
> Yes, it'd be great to soon release the tools since the engine is
> out.
Apologies for not replying sooner.
> And yes, autoconfig hasn't to be the default. Why not starting with
> an empty toolbox
Honestly, i'm content either way, this doesn't much affect me. So, whatever
y'all think is best works for me.
On Wed, Apr 25, 2018 at 12:54 AM, Claude Brisson wrote:
> Any thoughts on this? From my side, apart from this potential point, the
> tools are ready.
>
> Claude
>
>
>
> On 22/03/2018 0
Am 2018-04-25 um 09:54 schrieb Claude Brisson:
Any thoughts on this? From my side, apart from this potential point, the
tools are ready.
There are several issues I have noticed which I'd like to have resolved
before 3.0. I won't be able to comment on before the end of the next week.
Michael
Am 2018-03-22 um 01:25 schrieb Claude Brisson:
Yes, it'd be great to soon release the tools since the engine is out.
And yes, autoconfig hasn't to be the default. Why not starting with an
empty toolbox by default if it eases things for integrators. But there
are two different things here:
1) *
Any thoughts on this? From my side, apart from this potential point, the
tools are ready.
Claude
On 22/03/2018 01:25, Claude Brisson wrote:
Yes, it'd be great to soon release the tools since the engine is out.
And yes, autoconfig hasn't to be the default. Why not starting with an
empty to
Yes, it'd be great to soon release the tools since the engine is out.
And yes, autoconfig hasn't to be the default. Why not starting with an
empty toolbox by default if it eases things for integrators. But there
are two different things here:
1) *default* tools (loaded from tools.xml files insi
If we're talking 2.x, then adding a PrivilegedAction sounds better. If 3.0
(which, i think needs to happen anyway, right Claude?), then i'd agree with
Michael. The auto config would be better off as something users need to
explicitly turn on, not the default any longer.
On Wed, Mar 21, 2018 at 2:
Am 2018-03-21 um 06:17 schrieb Christopher Schultz:
All,
Using velocity-tools 2.0.
I've been exploring what it takes to get my application working under a
SecurityManager and it seems that o.a.v.t.view.VelocityView tries to
load a few configuration files from their default locations even when a
All,
Using velocity-tools 2.0.
I've been exploring what it takes to get my application working under a
SecurityManager and it seems that o.a.v.t.view.VelocityView tries to
load a few configuration files from their default locations even when a
specific configuration file has been specified by a s
14 matches
Mail list logo
