8:43 a.m.
Fair enough. In terms of cap/req though - if this is the desired
behavior, it would almost be better to just have no requirement at all.
But anything that does any detection (now or in the future) like "hey
is anything using this resource?" will return a false negative if it's
used by a deployment. If we went the other way and had an optional
requirement on all security domains, we'd need some hook to
automatically add new requirements every time a domain was added.
Either way seems not so good to me... maybe there's another approach though?
On 09/18/2015 08:38 AM, Jason T. Greene wrote:
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(a)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(a)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(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
> --
> - DML
--
- DML