<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    We just had a quick call, here is the summary:<br>
    <br>
    <meta http-equiv="content-type" content="text/html; charset=UTF-8">
    Tomaz Cerar<br>
    Stan Silvert<br>
    Darran Lofthouse<br>
    Thomas Heute<br>
    Stian Thorgersen<br>
     <br>
    WF "distributions":<br>
        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)<br>
        WF Web = WF Core + Servlet Container (Tomcat alternative)<br>
        WF Full = What we have today<br>
     <br>
    Future:<br>
        Support for extensions on host controller<br>
        Elytron<br>
     <br>
    Plan:<br>
        Keep KC integration pluggable and added in WF Full first (could
    go down to WF Web or whatever other profiles but after).<br>
            Domain HTTP module needs an "optional" dependency on KC<br>
        No need to wait on Elytron<br>
     <br>
    Additional link/info:
<a class="moz-txt-link-freetext" href="https://community.jboss.org/wiki/WildFly9-HTTPManagementInterfaceConfiguration">https://community.jboss.org/wiki/WildFly9-HTTPManagementInterfaceConfiguration</a><br>
    <br>
    Thomas<br>
    <br>
    <br>
    <br>
    <div class="moz-cite-prefix">On 07/03/2014 04:11 PM, David M. Lloyd
      wrote:<br>
    </div>
    <blockquote cite="mid:53B56487.2090706@redhat.com" type="cite">
      <pre wrap="">On 07/03/2014 09:02 AM, Stan Silvert wrote:
</pre>
      <blockquote type="cite">
        <pre wrap="">On 7/3/2014 9:21 AM, Stuart Douglas wrote:
</pre>
        <blockquote type="cite">
          <pre wrap="">

Bob McWhirter wrote:
</pre>
          <blockquote type="cite">
            <pre wrap="">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.

</pre>
          </blockquote>
          <pre wrap="">
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.
</pre>
        </blockquote>
        <pre wrap="">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.
</pre>
      </blockquote>
      <pre wrap="">
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.

</pre>
    </blockquote>
    <br>
  </body>
</html>