[wildfly-dev] EE Features in WildFly Core

[James Perkins]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20171101/75df0d8c/attachment-0001.html