[wildfly-dev] Should management interfaces be in a subsystem?

[Darran Lofthouse]

The Elytron Subsystem fits that 100%, the Elytron Subsystem is providing 
a set of services that return either standard Java types or types 
defined within the Elytron project.

If another subsystem chooses to provide a set of services with the same 
set of capabilities then the whole Elytron subsystem could be removed. 
Of course the core of the server is still going to depend on Elytron 
APIs but the subsystem providing those services is interchangeable.

As an example within KeyCloak they are currently looking at adding realm 
support to their subsystem, should they also provide the remaining 
services they could technically create a distribution based on WildFly 
100% backed by KeyCloak and drop the Elytron subsystem.  At the same 
time we end up with no hard dependencies on any other providers of these 
services.

Regards,
Darran Lofthouse.


On 18/04/15 15:12, Jason T. Greene wrote:
> So, to me, the major benefits of something being a subsystem is that it is either optional or replaceable. Does elytron, at least the core of it, fit this? If not perhaps it should be part of the core model?
>
>> On Apr 17, 2015, at 9:39 AM, Brian Stansberry <brian.stansberry at redhat.com> wrote:
>>
>> A kernel schema bump to 2.0 is fine, thanks. For sure we will be making
>> some changes so the chances of it being wasted effort are nil.
>>
>>> On 4/17/15 9:31 AM, Darran Lofthouse wrote:
>>> Thanks Brian,
>>>
>>> So this does sound like I should go ahead and bump the schema and
>>> management versions so I can continue with my tasks and I will send in a
>>> PR as soon as we move to 2.0.x development.
>>>
>>> Enhancements to the interface definitions can continue along that path
>>> until we feel ready to move them.
>>>
>>> Regards,
>>> Darran Lofthouse.
>>>
>>>
>>>> On 17/04/15 15:26, Brian Stansberry wrote:
>>>> Long term answer:
>>>>
>>>> Yes, I think they should be in a subsystem.
>>>>
>>>> Short term answer:
>>>>
>>>> That will be a lot of work, particularly in regards to providing the
>>>> necessary compatibility and, possibly, migration support. So I think we
>>>> need to get further along on our list of must have stuff before we
>>>> attack this problem in a lot of depth. If we can get to it, great.
>>>>
>>>> I believe the capabilities and requirements stuff should clean up a lot
>>>> of the issues around kernel stuff needing things provided by by
>>>> subsystems. The distinction should disappear, and it all becomes just
>>>> things providing capabilities and other things consuming them. So a
>>>> logical path to follow here is once that part is done, we can figure out
>>>> how to deal with the compatibility and migration aspects, and if we have
>>>> a good solution move on to the relatively easy part of new parsers,
>>>> ResourceDefinitions etc.
>>>>
>>>>> On 4/17/15 8:24 AM, Darran Lofthouse wrote:
>>>>> The reason this is coming up now is I am working on adding references to
>>>>> Elytron services from the interfaces, also I know there is plenty of
>>>>> demand for additional configuration options on these.
>>>>>
>>>>> So the question is should the management interface definitions be a part
>>>>> of a subsystem of their own or should they remain a top level?
>>>>>
>>>>> My vote would be make them a part of a subsystem, my main justifications
>>>>> being: -
>>>>>      - They are going to be dependent on capabilities supplied by other
>>>>> subsystems.
>>>>>      - We already have non-optimal code in there to access subsystem
>>>>> supplied services so can clean this up.
>>>>>      - In standalone mode they should not be strictly necessary, it should
>>>>> be possible to remove all remote administration for standalone.
>>>>>
>>>>> Even in the case of a slave host controller, if that host controller
>>>>> pulls it's Elytron definition from the master it could also pull it's
>>>>> management interface definitions from master.
>>>>>
>>>>> Regards,
>>>>> Darran Lofthouse.
>>>>>
>>>>> _______________________________________________
>>>>> wildfly-dev mailing list
>>>>> wildfly-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>>
>> --
>> Brian Stansberry
>> Senior Principal Software Engineer
>> JBoss by Red Hat
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>