To clarify "Do nothing" means we add more EE features to Core - i.e. JASPIC
is now on it's way.
On Wed, 1 Nov 2017 at 17:20 James Perkins <jperkins(a)redhat.com> wrote:
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 <
> 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> 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
>> 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?
>> Darran Lofthouse.
>> wildfly-dev mailing list
> Brian Stansberry
> Manager, Senior Principal Software Engineer
> Red Hat
> wildfly-dev mailing list
James R. Perkins
JBoss by Red Hat
wildfly-dev mailing list