[wildfly-dev] Capabilities/requirements and deployments

[Jason T. Greene]

Why not use optional capabilities? That would more closely match old behavior.

> On Sep 18, 2015, at 8:19 AM, David M. Lloyd <david.lloyd at redhat.com> wrote:
> 
> While working on moving the EJB subsystem to support Elytron, I 
> encountered a dilemma regarding cap/req.
> 
> Elytron exposes security domains as capabilities.  EJB deployments have 
> the ability to specify which security domain is used for authorization 
> purposes.  This specification is by name.
> 
> The dilemma is:
> 
> 1) Allow EJB deployments to directly reference security domain names, 
> thus implicitly causing the EJB subsystem to require all or none of the 
> security domains that are or could be configured
> 2) Require the EJB subsystem to declare (in the model) what security 
> domains it uses, thus requiring only security domains that are used
> 
> Option 1 seems disadvantageous because if EJB requires no domains, it is 
> possible to break deployments without getting so much as a warning, but 
> if it requires all, then you can never make significant changes to your 
> security domain configuration.
> 
> Option 2 requires an extra level of configuration, but on the other 
> hand, it also allows tricks like providing a "local" name for each 
> security domain which the deployment can reference, which grants a small 
> but potentially useful degree of flexibility, and it has a better degree 
> of in-model referential integrity.
> 
> Option 2 also requires that any run-time operation to remove a security 
> domain from the EJB subsystem be verified against current deployments. 
> I wonder if we can do this with runtime-only resources and cap/req too?
> 
> I guess I've just talked myself into Option 2, but I'm thinking that 
> this is not going to be the only case like this as we further develop 
> cap/req-enabled subsystems.
> 
> Thoughts?
> -- 
> - DML
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev