Ok, so it seems that picketbox shouldn't emerge as a layer. During the transient period where elytron relies on it, we would not support (using layers) elytron+jacc without implying the inclusion of a vault layer.
vault layer would  be a rename of the picketbox layer in servlet FP.
vault-tool (module and script) could appear as a layer in full FP if we think it is worth it in the first cloud scenario we are addressing (otherwise one would need to install a full server to get it).

On 05/12/2018 15:01, Darran Lofthouse wrote:
We could also imagine the user will only install Elytron and there will be no such thing as PicketBox at some point.

On Wed, Dec 5, 2018 at 1:58 PM Jean-Francois Denise <jdenise@redhat.com> wrote:

The subsystem. So we could imagine that user would install both elytron and picketbox.


On 05/12/2018 14:56, Darran Lofthouse wrote:
Do you mean Elytron or the Elytron Subsystem?

I believe yes the subsystem does have that dependency but it is only temporary until PicketBox is removed.

On Wed, Dec 5, 2018 at 1:51 PM Jean-Francois Denise <jdenise@redhat.com> wrote:

Darran,

elytron seems to have a dependency on picketbox for jacc support. Am I right?


On 05/12/2018 12:04, Darran Lofthouse wrote:
Yes we can remove it entirely ;-)

On Tue, Dec 4, 2018 at 11:13 PM Carlo de Wolf <cdewolf@redhat.com> wrote:
On 04-12-18 23:15, Brian Stansberry wrote:
Picketbox layer

Because we want at some point to get rid-off this dependency, I am
wandering if we should really define a layer for it. Could be that any
dependency on it would imply the use of legacy-security layer. Picketbox
is implicit when legacy-security layer is provisioned.

The independent use is the management vault. Using that shouldn't require everything in the current p-b module though. And arguably you could say that use case means you need the vault tool and thus whatever layer has it. (You don't need the vault tool though, not on the server.)

Can we change the management vault somehow to not need PicketBox at all anymore?

Carlo
_______________________________________________
wildfly-dev mailing list
wildfly-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev