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

[Brian Stansberry]

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