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

[Brian Stansberry]

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
>


-- 
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat