[wildfly-dev] EE Features in WildFly Core

[Darran Lofthouse]

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 at 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 <
> brian.stansberry at redhat.com> 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 at 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
>>> 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 at 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 at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>
>
>
> --
> James R. Perkins
> JBoss by Red Hat
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20171102/2634d41a/attachment.html