wrote:

Just sending this e-mail to check how we feel about EE APIs leaking into WildFly Core. The WildFly Elytron subsystem already contains JACC related configuration so has a dependency on the JACC APIs - JASPIC is about to be added next which will also need a dependency on the JASPIC API so I wanted to check if we are happy with this or if we want to get this corrected. I see a few options but other inspiration is also welcome. 1 - Do Nothing Just continue adding EE related security configuration to the WildFly Elytron subsystem. 2 - Move the Elytron subsystem to WildFly We have been over this in the past so I think we agree this would not work for us. 3 - Dynamically exclude portions of the model if not being used for EE management. This would help the subsystem be specific for it's server process but TBH does not solve the underlying problem as it would still be within WildFly Core. 4 - Add an elytron-ee subsystem to WildFly Capabilities allow two subsystems to work together well, main issue now security related config could be across two subsystems although very minor difference in the addres. 5 - Any other ideas? Regards, Darran Lofthouse. _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev

I'm a +1 to what Brian said. I also think if we keep adding EE stuff to core then we've defeated the purpose of the split. While for dev it's kind of a PITA the split is good for things like Arquillian where they can have a dependency on WildFly Core and not require a dependency on any version of WildFly Full. The same is likely true for any project that just manages a server. On Wed, Nov 1, 2017 at 7:52 AM, Brian Stansberry < brian.stansberry(a)redhat.com&gt; wrote: > I think for now, 1 - Do Nothing because the provisioning stuff is soon > enough going to allow something like 3. How? > > A package related to elytron will have an optional dependency on a > package related to jaspic. Since it's optional it won't be included in a > default provisioned server. > > A jaspic "feature" (part of the elytron configuration) will have a hard > dependency on that jaspic package. So if the provisioning spec includes > that feature, the package will be included in the install. > > Something in full could possibly also have a hard dependency on jaspic. > (Maybe not I don't know the EE details.) If so having that thing present > would also ensure the jaspic package is included. > > The semi-edge case is the user provisions something with no hard dep on > the jaspic package, and then wants to come along with the CLI/HAL and > configure jaspic. Won't work. The management handlers should deal with that > with some nice error message. > > Another variant is the jaspic package is an optional dep but is included > by default, avoiding the semi-edge case. So the dist is bigger than needed, > but the provisioning tool makes it easier to exclude it than it is now, > since the provisioning file can declare that the jaspic package isn't > wanted via a simple exclude element. > > Bottom line is I think the provisioning tooling is going to ease the pain > of slimming enough that jumping through hoops to make our feature packs > smaller becomes less necessary. > > > On Wed, Nov 1, 2017 at 8:22 AM, Darran Lofthouse < > darran.lofthouse(a)jboss.com&gt; wrote: > >> Just sending this e-mail to check how we feel about EE APIs leaking into >> WildFly Core. The WildFly Elytron subsystem already contains JACC related >> configuration so has a dependency on the JACC APIs - JASPIC is about to be >> added next which will also need a dependency on the JASPIC API so I wanted >> to check if we are happy with this or if we want to get this corrected. >> >> I see a few options but other inspiration is also welcome. >> >> 1 - Do Nothing >> >> Just continue adding EE related security configuration to the WildFly >> Elytron subsystem. >> >> 2 - Move the Elytron subsystem to WildFly >> >> We have been over this in the past so I think we agree this would not >> work for us. >> >> 3 - Dynamically exclude portions of the model if not being used for EE >> management. >> >> This would help the subsystem be specific for it's server process but >> TBH does not solve the underlying problem as it would still be within >> WildFly Core. >> >> 4 - Add an elytron-ee subsystem to WildFly >> >> Capabilities allow two subsystems to work together well, main issue now >> security related config could be across two subsystems although very minor >> difference in the addres. >> >> 5 - Any other ideas? >> >> Regards, >> Darran Lofthouse. >> >> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> > > > > -- > Brian Stansberry > Manager, Senior Principal Software Engineer > Red Hat > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -- James R. Perkins JBoss by Red Hat _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev