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

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