Re: [wildfly-dev] Capabilities/requirements and deployments

On Sep 18, 2015, at 8:36 AM, David M. Lloyd <david.lloyd(a)redhat.com&gt; 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&gt; 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