We just had a quick call, here is the summary:
WF Core = bare minimum (CLI included, DMR over HTTP, no console),
CLI/DMR over HTTP would be secured the way it is already (ie: without KC)
WF Web = WF Core + Servlet Container (Tomcat alternative)
WF Full = What we have today
Support for extensions on host controller
Keep KC integration pluggable and added in WF Full first (could go
down to WF Web or whatever other profiles but after).
Domain HTTP module needs an "optional" dependency on KC
No need to wait on Elytron
On 07/03/2014 04:11 PM, David M. Lloyd wrote:
On 07/03/2014 09:02 AM, Stan Silvert wrote:
> On 7/3/2014 9:21 AM, Stuart Douglas wrote:
>> Bob McWhirter wrote:
>>> I admitted haven’t been paying super-close attention, but as a member
>>> of several teams which build stuff upon AS/WildFly, I’d prefer that
>>> anything -core makes zero assumptions, and is as close to a nil
>>> container as possible.
>>> Then, let me mix in what I need.
>>> If the minimal baseline includes much more than nothing, then the
>>> overhead of building upon WildFly has increased. When you put things
>>> into WildFly ‘by default’, you might be satisfying the 80% case, but
>>> there will still be 20% that won’t want whatever is jammed into the
>>> box and will consider it gratuitous for their needs.
>>> I vote for -core being only MSC/Modules/DeploymentUnitProcessor
>>> stuff, and a pert-near empty standalone.xml.
>> That is the intention.
>> You also need to keep in mind that you can't actually do anything with
>> core without first installing some extensions. Nothing works out of
>> the box on core, because there is nothing there to do any work.
> Nothing works out of the box on core?
> Does this mean web console doesn't work?
> Does this mean CLI doesn't work?
> I think it's perfectly acceptable to choose yes or no to any of these,
> but we need to answer those questions to move forward.
In point of fact, no we don't. In order to move forward, we need to
terminate this pointless email thread. The core split is necessarily
going to be incremental and iterative - we are still quite a ways away
from being able to apply this kind of broad principle, and anyway it has
zero bearing on what you need to be doing, AFAICT.
Splitting up a monolithic codebase as big and complex as WildFly isn't
something that can or should be armchair quarterbacked. Either help
directly in a pragmatic and incremental manner, or just let it happen as
it needs to happen; competent hands are on the helm.