[wildfly-dev] Capabilities/requirements and deployments

[Jason T. Greene]

If that happened it would down the deployment because capabilities are translated to hard service deps 

Sent from my iPhone

> On Sep 18, 2015, at 8:36 AM, David M. Lloyd <david.lloyd at redhat.com> wrote:
> 
> I don't like this because if a domain is removed at runtime, it could have unpredictable effects.  I'd rather force the model to stay consistent whenever we can.
> 
>> On 09/18/2015 08:31 AM, Jason T. Greene wrote:
>> 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
> 
> -- 
> - DML