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
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.