[wildfly-dev] Capabilities/requirements and deployments

[David M. Lloyd]

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