Pending core split

classic Classic list List threaded Threaded
55 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Re: Pending core split

Darran Lofthouse


On 01/07/14 14:26, Stan Silvert wrote:

> On 7/1/2014 9:01 AM, Stuart Douglas wrote:
>>
>>> I understand. Perhaps I should have said, 'working out of the box on
>>> core'. domain-http is currently in core, which is what I'm talking about
>>> here.
>>
>> I don't follow your logic here. You are basically saying that unless
>> we can have keycloak in core then there is no point having a core?
> Of course that's not what I'm saying.  I'm saying that domain-http is
> currently in core.  Web console and other clients use domain-http.  If
> we want keycloak to authenticate domain-http then keycloak must also be
> in core.

I really don't see where you are getting this 'must' from, we may have a
requirement of 'we must be able to enable KeyCloak in our platforms' but
where are you getting the 'we must include KeyCloak in the core
distribution' from?

> There are many possible solutions:
> * Don't do the split
> * Do the split, but allow core to see the full set of modules.
> * Move domain-http out of core.

In another discussion just starting I have also raised the question
could the definition of the management interfaces also be moved into a
subsystem.

The management interfaces are required in domain mode to allow a slave
to connection back and the app server instances to connect back but in
standalone mode I do also see them as something that should be optional.

> * Allow the extra dependencies.
> * Redesign domain-http

 From the perspective of security integration that is already the path
we are moving down.

> * others?
>
>>
>> Core can't actually do anything out of the box, it is a runtime that
>> other distributions will build on.
>>
>> Stuart
>>
>>
>>>>
>>>>
>>>>
>>>>
>>>>>
>>>>>>
>>>>>> In all honesty we are highly unlikely to ever have accepted a PR that
>>>>>> added all these dependencies to the core in any case, so it is a
>>>>>> problem that would have had to be solved at some point anyway.
>>>>>>
>>>>>> Stuart
>>>>>>
>>>>>> Stan Silvert wrote:
>>>>>>> I'm starting to have doubts about this split.
>>>>>>>
>>>>>>> Right now I'm trying to integrate the Keycloak (client-side) adapter
>>>>>>> into build-core so that the web console can use Keycloak for
>>>>>>> authentication. The problem is that there is a huge web of
>>>>>>> dependencies
>>>>>>> that must be moved over from build to build-core.
>>>>>>>
>>>>>>> What exactly is the split trying to solve?
>>>>>>>
>>>>>>> Stan
>>>>>>>
>>>>>>> On 6/27/2014 12:19 PM, Stuart Douglas wrote:
>>>>>>>> Hi all,
>>>>>>>>
>>>>>>>> So I am moderately confident that we will be ready to split out
>>>>>>>> Wildfly
>>>>>>>> core into a separate repository early next week (I'm not saying
>>>>>>>> that it
>>>>>>>> will definitely happen in this time frame, just that it should be
>>>>>>>> possible).
>>>>>>>>
>>>>>>>> Once this is ready to go I think the basic process will be:
>>>>>>>>
>>>>>>>> - Code freeze on Master
>>>>>>>> - Create the core repo, push new rewritten core history
>>>>>>>> - Release core 1.0.0.Beta1
>>>>>>>> - Create PR against core WF repo that deletes everything in
>>>>>>>> core, and
>>>>>>>> uses the core 1.0.0.Beta1 release
>>>>>>>> - End of code freeze
>>>>>>>>
>>>>>>>> Stuart
>>>>>>>> _______________________________________________
>>>>>>>> wildfly-dev mailing list
>>>>>>>> [hidden email]
>>>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> wildfly-dev mailing list
>>>>>>> [hidden email]
>>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>
>>>
>
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Pending core split

Darran Lofthouse
In reply to this post by Stuart Douglas


On 01/07/14 14:42, Stuart Douglas wrote:

>
>
> Stan Silvert wrote:
>> On 7/1/2014 9:01 AM, Stuart Douglas wrote:
>>>
>>>> I understand. Perhaps I should have said, 'working out of the box on
>>>> core'. domain-http is currently in core, which is what I'm talking about
>>>> here.
>>>
>>> I don't follow your logic here. You are basically saying that unless
>>> we can have keycloak in core then there is no point having a core?
>> Of course that's not what I'm saying. I'm saying that domain-http is
>> currently in core. Web console and other clients use domain-http. If we
>> want keycloak to authenticate domain-http then keycloak must also be in
>> core.
>>
>
> I don't follow your logic. If we want web console and other clients to
> use keycloak then keycloak must be present, but I really can't see why
> you think it *must* be in core.
>
> IMHO the way this should work is that we identify the extension points
> you need to integrate keycloak,

WildFly Elytron would be the fundamental core of this.

> looking at your kcauth branch this looks
> fairly simple, basically just a way to add some handlers and
> Authentication mechanisms. You then have the keycloak module use these
> extension points to integrate with core. IMHO this will give a much
> cleaner result and keeps all the keycloak related stuff in the keycloak
> module.
>
>
>> There are many possible solutions:
>> * Don't do the split
>
> The split has been on the table for over 6 months, it is going ahead.
>
>> * Do the split, but allow core to see the full set of modules.
> This makes no sense. If it has all the modules it is not core.
>
>> * Move domain-http out of core.
>> * Allow the extra dependencies.
>> * Redesign domain-http
>
> If by redesign you mean add some extension points to allow keycloak to
> hook into it without requiring keycloak code in domain-http then this is
> exactly what we should do.
>
> If you want a hand with this I should be able to help you out.

Just keep in mind the security code that exists today is being re-worked
and a lot will be replaced.

We will be having one security solution that applies to the whole app
server whether that be management or ee.

>
> Stuart
>
>> * others?
>>
>>>
>>> Core can't actually do anything out of the box, it is a runtime that
>>> other distributions will build on.
>>>
>>> Stuart
>>>
>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>>>
>>>>>>> In all honesty we are highly unlikely to ever have accepted a PR that
>>>>>>> added all these dependencies to the core in any case, so it is a
>>>>>>> problem that would have had to be solved at some point anyway.
>>>>>>>
>>>>>>> Stuart
>>>>>>>
>>>>>>> Stan Silvert wrote:
>>>>>>>> I'm starting to have doubts about this split.
>>>>>>>>
>>>>>>>> Right now I'm trying to integrate the Keycloak (client-side) adapter
>>>>>>>> into build-core so that the web console can use Keycloak for
>>>>>>>> authentication. The problem is that there is a huge web of
>>>>>>>> dependencies
>>>>>>>> that must be moved over from build to build-core.
>>>>>>>>
>>>>>>>> What exactly is the split trying to solve?
>>>>>>>>
>>>>>>>> Stan
>>>>>>>>
>>>>>>>> On 6/27/2014 12:19 PM, Stuart Douglas wrote:
>>>>>>>>> Hi all,
>>>>>>>>>
>>>>>>>>> So I am moderately confident that we will be ready to split out
>>>>>>>>> Wildfly
>>>>>>>>> core into a separate repository early next week (I'm not saying
>>>>>>>>> that it
>>>>>>>>> will definitely happen in this time frame, just that it should be
>>>>>>>>> possible).
>>>>>>>>>
>>>>>>>>> Once this is ready to go I think the basic process will be:
>>>>>>>>>
>>>>>>>>> - Code freeze on Master
>>>>>>>>> - Create the core repo, push new rewritten core history
>>>>>>>>> - Release core 1.0.0.Beta1
>>>>>>>>> - Create PR against core WF repo that deletes everything in
>>>>>>>>> core, and
>>>>>>>>> uses the core 1.0.0.Beta1 release
>>>>>>>>> - End of code freeze
>>>>>>>>>
>>>>>>>>> Stuart
>>>>>>>>> _______________________________________________
>>>>>>>>> wildfly-dev mailing list
>>>>>>>>> [hidden email]
>>>>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> wildfly-dev mailing list
>>>>>>>> [hidden email]
>>>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>>
>>>>
>>
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Pending core split

Darran Lofthouse
In reply to this post by Tomaž Cerar-2
On 03/07/14 10:28, Tomaž Cerar wrote:

> I think that for start we can make it by default enablable in full distro.
>
> Once this is done, and extra work is done on trimming down dependencies
> to go as near JDK as possible
> it could be moved to core distro.
>
> Rome was not build in a day, why would KeyCloak integration /
> implementation be done in just one step.
>
> Isn't it better that we start somewhere to get it out to the people to
> test it as soon as possible
> and when it is ready we decide where it is best resting place and how to
> get there.

+1 That has been my thinking when I suggested we follow an approach of
get it enableable by default rather than enabled by default as we reach
the point it is useable.

>
>
>
> On Thu, Jul 3, 2014 at 11:19 AM, Darran Lofthouse
> <[hidden email] <mailto:[hidden email]>> wrote:
>
>
>       > The central question is, do we want Keycloak to work out of the box?
>       > Before this issue was known, everyone answered "yes".
>
>     I think here we had reached the point we were answering the question "do
>     we want it enableable out of the box?" and the answer to that was "yes"
>
>     What has not been defined since the split started is what "out of the
>     box" actually means now, are we talking out of the box for the core or
>     out of the box for a complete assembled server?
>
>     On 01/07/14 12:55, Stan Silvert wrote:
>      > On 6/30/2014 10:43 PM, Stuart Douglas wrote:
>      >> It really sounds like this should not be part of core, but should be
>      >> something extra that just integrates with the core.
>      > That may be true, but it's not a decision that should depend on
>     how many
>      > modules must be added.
>      >
>      > The central question is, do we want Keycloak to work out of the box?
>      > Before this issue was known, everyone answered "yes".
>      >
>      > Should we really determine our feature set based on how many
>     modules it
>      > requires?   I don't think we want do that, which is why I'm having
>      > doubts about the current approach.
>      >
>      >>
>      >> In all honesty we are highly unlikely to ever have accepted a PR
>     that
>      >> added all these dependencies to the core in any case, so it is a
>      >> problem that would have had to be solved at some point anyway.
>      >>
>      >> Stuart
>      >>
>      >> Stan Silvert wrote:
>      >>> I'm starting to have doubts about this split.
>      >>>
>      >>> Right now I'm trying to integrate the Keycloak (client-side)
>     adapter
>      >>> into build-core so that the web console can use Keycloak for
>      >>> authentication.  The problem is that there is a huge web of
>     dependencies
>      >>> that must be moved over from build to build-core.
>      >>>
>      >>> What exactly is the split trying to solve?
>      >>>
>      >>> Stan
>      >>>
>      >>> On 6/27/2014 12:19 PM, Stuart Douglas wrote:
>      >>>> Hi all,
>      >>>>
>      >>>> So I am moderately confident that we will be ready to split
>     out Wildfly
>      >>>> core into a separate repository early next week (I'm not
>     saying that it
>      >>>> will definitely happen in this time frame, just that it should be
>      >>>> possible).
>      >>>>
>      >>>> Once this is ready to go I think the basic process will be:
>      >>>>
>      >>>> - Code freeze on Master
>      >>>> - Create the core repo, push new rewritten core history
>      >>>> - Release core 1.0.0.Beta1
>      >>>> - Create PR against core WF repo that deletes everything in
>     core, and
>      >>>> uses the core 1.0.0.Beta1 release
>      >>>> - End of code freeze
>      >>>>
>      >>>> Stuart
>      >>>> _______________________________________________
>      >>>> wildfly-dev mailing list
>      >>>> [hidden email] <mailto:[hidden email]>
>      >>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>      >>>
>      >>> _______________________________________________
>      >>> wildfly-dev mailing list
>      >>> [hidden email] <mailto:[hidden email]>
>      >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>      >
>      > _______________________________________________
>      > wildfly-dev mailing list
>      > [hidden email] <mailto:[hidden email]>
>      > https://lists.jboss.org/mailman/listinfo/wildfly-dev
>      >
>     _______________________________________________
>     wildfly-dev mailing list
>     [hidden email] <mailto:[hidden email]>
>     https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Pending core split

Darran Lofthouse
Should have added, I think it is the split that has complicated what by
default means now.

To me the critical point is that the full security services we can
provide need to be included in the final distribution that will be used
which to me does not automatically mean the core distribution.

On 03/07/14 10:45, Darran Lofthouse wrote:

> On 03/07/14 10:28, Tomaž Cerar wrote:
>> I think that for start we can make it by default enablable in full
>> distro.
>>
>> Once this is done, and extra work is done on trimming down dependencies
>> to go as near JDK as possible
>> it could be moved to core distro.
>>
>> Rome was not build in a day, why would KeyCloak integration /
>> implementation be done in just one step.
>>
>> Isn't it better that we start somewhere to get it out to the people to
>> test it as soon as possible
>> and when it is ready we decide where it is best resting place and how to
>> get there.
>
> +1 That has been my thinking when I suggested we follow an approach of
> get it enableable by default rather than enabled by default as we reach
> the point it is useable.
>
>>
>>
>>
>> On Thu, Jul 3, 2014 at 11:19 AM, Darran Lofthouse
>> <[hidden email] <mailto:[hidden email]>> wrote:
>>
>>
>>       > The central question is, do we want Keycloak to work out of
>> the box?
>>       > Before this issue was known, everyone answered "yes".
>>
>>     I think here we had reached the point we were answering the
>> question "do
>>     we want it enableable out of the box?" and the answer to that was
>> "yes"
>>
>>     What has not been defined since the split started is what "out of the
>>     box" actually means now, are we talking out of the box for the
>> core or
>>     out of the box for a complete assembled server?
>>
>>     On 01/07/14 12:55, Stan Silvert wrote:
>>      > On 6/30/2014 10:43 PM, Stuart Douglas wrote:
>>      >> It really sounds like this should not be part of core, but
>> should be
>>      >> something extra that just integrates with the core.
>>      > That may be true, but it's not a decision that should depend on
>>     how many
>>      > modules must be added.
>>      >
>>      > The central question is, do we want Keycloak to work out of the
>> box?
>>      > Before this issue was known, everyone answered "yes".
>>      >
>>      > Should we really determine our feature set based on how many
>>     modules it
>>      > requires?   I don't think we want do that, which is why I'm having
>>      > doubts about the current approach.
>>      >
>>      >>
>>      >> In all honesty we are highly unlikely to ever have accepted a PR
>>     that
>>      >> added all these dependencies to the core in any case, so it is a
>>      >> problem that would have had to be solved at some point anyway.
>>      >>
>>      >> Stuart
>>      >>
>>      >> Stan Silvert wrote:
>>      >>> I'm starting to have doubts about this split.
>>      >>>
>>      >>> Right now I'm trying to integrate the Keycloak (client-side)
>>     adapter
>>      >>> into build-core so that the web console can use Keycloak for
>>      >>> authentication.  The problem is that there is a huge web of
>>     dependencies
>>      >>> that must be moved over from build to build-core.
>>      >>>
>>      >>> What exactly is the split trying to solve?
>>      >>>
>>      >>> Stan
>>      >>>
>>      >>> On 6/27/2014 12:19 PM, Stuart Douglas wrote:
>>      >>>> Hi all,
>>      >>>>
>>      >>>> So I am moderately confident that we will be ready to split
>>     out Wildfly
>>      >>>> core into a separate repository early next week (I'm not
>>     saying that it
>>      >>>> will definitely happen in this time frame, just that it
>> should be
>>      >>>> possible).
>>      >>>>
>>      >>>> Once this is ready to go I think the basic process will be:
>>      >>>>
>>      >>>> - Code freeze on Master
>>      >>>> - Create the core repo, push new rewritten core history
>>      >>>> - Release core 1.0.0.Beta1
>>      >>>> - Create PR against core WF repo that deletes everything in
>>     core, and
>>      >>>> uses the core 1.0.0.Beta1 release
>>      >>>> - End of code freeze
>>      >>>>
>>      >>>> Stuart
>>      >>>> _______________________________________________
>>      >>>> wildfly-dev mailing list
>>      >>>> [hidden email]
>> <mailto:[hidden email]>
>>      >>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>      >>>
>>      >>> _______________________________________________
>>      >>> wildfly-dev mailing list
>>      >>> [hidden email] <mailto:[hidden email]>
>>      >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>      >
>>      > _______________________________________________
>>      > wildfly-dev mailing list
>>      > [hidden email] <mailto:[hidden email]>
>>      > https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>      >
>>     _______________________________________________
>>     wildfly-dev mailing list
>>     [hidden email] <mailto:[hidden email]>
>>     https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>>
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Pending core split

Stan Silvert
In reply to this post by Darran Lofthouse
On 7/3/2014 5:19 AM, Darran Lofthouse wrote:

>
> > The central question is, do we want Keycloak to work out of the box?
> > Before this issue was known, everyone answered "yes".
>
> I think here we had reached the point we were answering the question
> "do we want it enableable out of the box?" and the answer to that was
> "yes"
>
> What has not been defined since the split started is what "out of the
> box" actually means now, are we talking out of the box for the core or
> out of the box for a complete assembled server?

We now have three "out of the boxes".  Three distributions.  So what is
available by default on these three distros?
core-build
web-build
full-build

First, which of these should have dmr over http available by default,
out of the box?
Second, of those with dmr over http available, which should have
keycloak available by default, out of the box?

For now, let's make no distinction about what is enabled by default.  We
only care about what is available by default.

>
> On 01/07/14 12:55, Stan Silvert wrote:
>> On 6/30/2014 10:43 PM, Stuart Douglas wrote:
>>> It really sounds like this should not be part of core, but should be
>>> something extra that just integrates with the core.
>> That may be true, but it's not a decision that should depend on how many
>> modules must be added.
>>
>> The central question is, do we want Keycloak to work out of the box?
>> Before this issue was known, everyone answered "yes".
>>
>> Should we really determine our feature set based on how many modules it
>> requires?   I don't think we want do that, which is why I'm having
>> doubts about the current approach.
>>
>>>
>>> In all honesty we are highly unlikely to ever have accepted a PR that
>>> added all these dependencies to the core in any case, so it is a
>>> problem that would have had to be solved at some point anyway.
>>>
>>> Stuart
>>>
>>> Stan Silvert wrote:
>>>> I'm starting to have doubts about this split.
>>>>
>>>> Right now I'm trying to integrate the Keycloak (client-side) adapter
>>>> into build-core so that the web console can use Keycloak for
>>>> authentication.  The problem is that there is a huge web of
>>>> dependencies
>>>> that must be moved over from build to build-core.
>>>>
>>>> What exactly is the split trying to solve?
>>>>
>>>> Stan
>>>>
>>>> On 6/27/2014 12:19 PM, Stuart Douglas wrote:
>>>>> Hi all,
>>>>>
>>>>> So I am moderately confident that we will be ready to split out
>>>>> Wildfly
>>>>> core into a separate repository early next week (I'm not saying
>>>>> that it
>>>>> will definitely happen in this time frame, just that it should be
>>>>> possible).
>>>>>
>>>>> Once this is ready to go I think the basic process will be:
>>>>>
>>>>> - Code freeze on Master
>>>>> - Create the core repo, push new rewritten core history
>>>>> - Release core 1.0.0.Beta1
>>>>> - Create PR against core WF repo that deletes everything in core, and
>>>>> uses the core 1.0.0.Beta1 release
>>>>> - End of code freeze
>>>>>
>>>>> Stuart
>>>>> _______________________________________________
>>>>> wildfly-dev mailing list
>>>>> [hidden email]
>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>
>>>> _______________________________________________
>>>> wildfly-dev mailing list
>>>> [hidden email]
>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Pending core split

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

        -Bob


On Jul 3, 2014, at 8:54 AM, Stan Silvert <[hidden email]> wrote:

> On 7/3/2014 5:19 AM, Darran Lofthouse wrote:
>>
>>> The central question is, do we want Keycloak to work out of the box?
>>> Before this issue was known, everyone answered "yes".
>>
>> I think here we had reached the point we were answering the question
>> "do we want it enableable out of the box?" and the answer to that was
>> "yes"
>>
>> What has not been defined since the split started is what "out of the
>> box" actually means now, are we talking out of the box for the core or
>> out of the box for a complete assembled server?
>
> We now have three "out of the boxes".  Three distributions.  So what is
> available by default on these three distros?
> core-build
> web-build
> full-build
>
> First, which of these should have dmr over http available by default,
> out of the box?
> Second, of those with dmr over http available, which should have
> keycloak available by default, out of the box?
>
> For now, let's make no distinction about what is enabled by default.  We
> only care about what is available by default.
>
>>
>> On 01/07/14 12:55, Stan Silvert wrote:
>>> On 6/30/2014 10:43 PM, Stuart Douglas wrote:
>>>> It really sounds like this should not be part of core, but should be
>>>> something extra that just integrates with the core.
>>> That may be true, but it's not a decision that should depend on how many
>>> modules must be added.
>>>
>>> The central question is, do we want Keycloak to work out of the box?
>>> Before this issue was known, everyone answered "yes".
>>>
>>> Should we really determine our feature set based on how many modules it
>>> requires?   I don't think we want do that, which is why I'm having
>>> doubts about the current approach.
>>>
>>>>
>>>> In all honesty we are highly unlikely to ever have accepted a PR that
>>>> added all these dependencies to the core in any case, so it is a
>>>> problem that would have had to be solved at some point anyway.
>>>>
>>>> Stuart
>>>>
>>>> Stan Silvert wrote:
>>>>> I'm starting to have doubts about this split.
>>>>>
>>>>> Right now I'm trying to integrate the Keycloak (client-side) adapter
>>>>> into build-core so that the web console can use Keycloak for
>>>>> authentication.  The problem is that there is a huge web of
>>>>> dependencies
>>>>> that must be moved over from build to build-core.
>>>>>
>>>>> What exactly is the split trying to solve?
>>>>>
>>>>> Stan
>>>>>
>>>>> On 6/27/2014 12:19 PM, Stuart Douglas wrote:
>>>>>> Hi all,
>>>>>>
>>>>>> So I am moderately confident that we will be ready to split out
>>>>>> Wildfly
>>>>>> core into a separate repository early next week (I'm not saying
>>>>>> that it
>>>>>> will definitely happen in this time frame, just that it should be
>>>>>> possible).
>>>>>>
>>>>>> Once this is ready to go I think the basic process will be:
>>>>>>
>>>>>> - Code freeze on Master
>>>>>> - Create the core repo, push new rewritten core history
>>>>>> - Release core 1.0.0.Beta1
>>>>>> - Create PR against core WF repo that deletes everything in core, and
>>>>>> uses the core 1.0.0.Beta1 release
>>>>>> - End of code freeze
>>>>>>
>>>>>> Stuart
>>>>>> _______________________________________________
>>>>>> wildfly-dev mailing list
>>>>>> [hidden email]
>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>
>>>>> _______________________________________________
>>>>> wildfly-dev mailing list
>>>>> [hidden email]
>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
>
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Pending core split

Stuart Douglas


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.

Stuart

> -Bob
>
>
> On Jul 3, 2014, at 8:54 AM, Stan Silvert<[hidden email]>  wrote:
>
>> On 7/3/2014 5:19 AM, Darran Lofthouse wrote:
>>>> The central question is, do we want Keycloak to work out of the box?
>>>> Before this issue was known, everyone answered "yes".
>>> I think here we had reached the point we were answering the question
>>> "do we want it enableable out of the box?" and the answer to that was
>>> "yes"
>>>
>>> What has not been defined since the split started is what "out of the
>>> box" actually means now, are we talking out of the box for the core or
>>> out of the box for a complete assembled server?
>> We now have three "out of the boxes".  Three distributions.  So what is
>> available by default on these three distros?
>> core-build
>> web-build
>> full-build
>>
>> First, which of these should have dmr over http available by default,
>> out of the box?
>> Second, of those with dmr over http available, which should have
>> keycloak available by default, out of the box?
>>
>> For now, let's make no distinction about what is enabled by default.  We
>> only care about what is available by default.
>>
>>> On 01/07/14 12:55, Stan Silvert wrote:
>>>> On 6/30/2014 10:43 PM, Stuart Douglas wrote:
>>>>> It really sounds like this should not be part of core, but should be
>>>>> something extra that just integrates with the core.
>>>> That may be true, but it's not a decision that should depend on how many
>>>> modules must be added.
>>>>
>>>> The central question is, do we want Keycloak to work out of the box?
>>>> Before this issue was known, everyone answered "yes".
>>>>
>>>> Should we really determine our feature set based on how many modules it
>>>> requires?   I don't think we want do that, which is why I'm having
>>>> doubts about the current approach.
>>>>
>>>>> In all honesty we are highly unlikely to ever have accepted a PR that
>>>>> added all these dependencies to the core in any case, so it is a
>>>>> problem that would have had to be solved at some point anyway.
>>>>>
>>>>> Stuart
>>>>>
>>>>> Stan Silvert wrote:
>>>>>> I'm starting to have doubts about this split.
>>>>>>
>>>>>> Right now I'm trying to integrate the Keycloak (client-side) adapter
>>>>>> into build-core so that the web console can use Keycloak for
>>>>>> authentication.  The problem is that there is a huge web of
>>>>>> dependencies
>>>>>> that must be moved over from build to build-core.
>>>>>>
>>>>>> What exactly is the split trying to solve?
>>>>>>
>>>>>> Stan
>>>>>>
>>>>>> On 6/27/2014 12:19 PM, Stuart Douglas wrote:
>>>>>>> Hi all,
>>>>>>>
>>>>>>> So I am moderately confident that we will be ready to split out
>>>>>>> Wildfly
>>>>>>> core into a separate repository early next week (I'm not saying
>>>>>>> that it
>>>>>>> will definitely happen in this time frame, just that it should be
>>>>>>> possible).
>>>>>>>
>>>>>>> Once this is ready to go I think the basic process will be:
>>>>>>>
>>>>>>> - Code freeze on Master
>>>>>>> - Create the core repo, push new rewritten core history
>>>>>>> - Release core 1.0.0.Beta1
>>>>>>> - Create PR against core WF repo that deletes everything in core, and
>>>>>>> uses the core 1.0.0.Beta1 release
>>>>>>> - End of code freeze
>>>>>>>
>>>>>>> Stuart
>>>>>>> _______________________________________________
>>>>>>> wildfly-dev mailing list
>>>>>>> [hidden email]
>>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>> _______________________________________________
>>>>>> wildfly-dev mailing list
>>>>>> [hidden email]
>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>> _______________________________________________
>>>> wildfly-dev mailing list
>>>> [hidden email]
>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>
>> _______________________________________________
>> wildfly-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Pending core split

Darran Lofthouse
In reply to this post by Bob McWhirter
+1 In terms of security capabilities I think the core must be developed
in a way that leaves it ready for security services to be added but that
those services should be added in the distributions built on top of the
core.

This thread has really had most of it's traffic in relation to enabling
KeyCloak but I anticipate we would also have similar discussions when it
comes to enabling capabilities provided by PicketLink.

WildFly ELytron is being developed to provide SPIs to allow different
providers to be used IMO choosing which providers to make available is
something that should happen when the higher level distribution is
defined - that should also be the point the default out of the box
policy is defined as again different distributions would have different
requirements.

Regards,
Darran Lofthouse.


On 03/07/14 14:05, 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.
>
> -Bob
>
>
> On Jul 3, 2014, at 8:54 AM, Stan Silvert <[hidden email]> wrote:
>
>> On 7/3/2014 5:19 AM, Darran Lofthouse wrote:
>>>
>>>> The central question is, do we want Keycloak to work out of the box?
>>>> Before this issue was known, everyone answered "yes".
>>>
>>> I think here we had reached the point we were answering the question
>>> "do we want it enableable out of the box?" and the answer to that was
>>> "yes"
>>>
>>> What has not been defined since the split started is what "out of the
>>> box" actually means now, are we talking out of the box for the core or
>>> out of the box for a complete assembled server?
>>
>> We now have three "out of the boxes".  Three distributions.  So what is
>> available by default on these three distros?
>> core-build
>> web-build
>> full-build
>>
>> First, which of these should have dmr over http available by default,
>> out of the box?
>> Second, of those with dmr over http available, which should have
>> keycloak available by default, out of the box?
>>
>> For now, let's make no distinction about what is enabled by default.  We
>> only care about what is available by default.
>>
>>>
>>> On 01/07/14 12:55, Stan Silvert wrote:
>>>> On 6/30/2014 10:43 PM, Stuart Douglas wrote:
>>>>> It really sounds like this should not be part of core, but should be
>>>>> something extra that just integrates with the core.
>>>> That may be true, but it's not a decision that should depend on how many
>>>> modules must be added.
>>>>
>>>> The central question is, do we want Keycloak to work out of the box?
>>>> Before this issue was known, everyone answered "yes".
>>>>
>>>> Should we really determine our feature set based on how many modules it
>>>> requires?   I don't think we want do that, which is why I'm having
>>>> doubts about the current approach.
>>>>
>>>>>
>>>>> In all honesty we are highly unlikely to ever have accepted a PR that
>>>>> added all these dependencies to the core in any case, so it is a
>>>>> problem that would have had to be solved at some point anyway.
>>>>>
>>>>> Stuart
>>>>>
>>>>> Stan Silvert wrote:
>>>>>> I'm starting to have doubts about this split.
>>>>>>
>>>>>> Right now I'm trying to integrate the Keycloak (client-side) adapter
>>>>>> into build-core so that the web console can use Keycloak for
>>>>>> authentication.  The problem is that there is a huge web of
>>>>>> dependencies
>>>>>> that must be moved over from build to build-core.
>>>>>>
>>>>>> What exactly is the split trying to solve?
>>>>>>
>>>>>> Stan
>>>>>>
>>>>>> On 6/27/2014 12:19 PM, Stuart Douglas wrote:
>>>>>>> Hi all,
>>>>>>>
>>>>>>> So I am moderately confident that we will be ready to split out
>>>>>>> Wildfly
>>>>>>> core into a separate repository early next week (I'm not saying
>>>>>>> that it
>>>>>>> will definitely happen in this time frame, just that it should be
>>>>>>> possible).
>>>>>>>
>>>>>>> Once this is ready to go I think the basic process will be:
>>>>>>>
>>>>>>> - Code freeze on Master
>>>>>>> - Create the core repo, push new rewritten core history
>>>>>>> - Release core 1.0.0.Beta1
>>>>>>> - Create PR against core WF repo that deletes everything in core, and
>>>>>>> uses the core 1.0.0.Beta1 release
>>>>>>> - End of code freeze
>>>>>>>
>>>>>>> Stuart
>>>>>>> _______________________________________________
>>>>>>> wildfly-dev mailing list
>>>>>>> [hidden email]
>>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>>
>>>>>> _______________________________________________
>>>>>> wildfly-dev mailing list
>>>>>> [hidden email]
>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>
>>>> _______________________________________________
>>>> wildfly-dev mailing list
>>>> [hidden email]
>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Pending core split

Stan Silvert
In reply to this post by Stuart Douglas
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.

>
> Stuart
>
>>     -Bob
>>
>>
>> On Jul 3, 2014, at 8:54 AM, Stan Silvert<[hidden email]>  wrote:
>>
>>> On 7/3/2014 5:19 AM, Darran Lofthouse wrote:
>>>>> The central question is, do we want Keycloak to work out of the box?
>>>>> Before this issue was known, everyone answered "yes".
>>>> I think here we had reached the point we were answering the question
>>>> "do we want it enableable out of the box?" and the answer to that was
>>>> "yes"
>>>>
>>>> What has not been defined since the split started is what "out of the
>>>> box" actually means now, are we talking out of the box for the core or
>>>> out of the box for a complete assembled server?
>>> We now have three "out of the boxes".  Three distributions. So what is
>>> available by default on these three distros?
>>> core-build
>>> web-build
>>> full-build
>>>
>>> First, which of these should have dmr over http available by default,
>>> out of the box?
>>> Second, of those with dmr over http available, which should have
>>> keycloak available by default, out of the box?
>>>
>>> For now, let's make no distinction about what is enabled by
>>> default.  We
>>> only care about what is available by default.
>>>
>>>> On 01/07/14 12:55, Stan Silvert wrote:
>>>>> On 6/30/2014 10:43 PM, Stuart Douglas wrote:
>>>>>> It really sounds like this should not be part of core, but should be
>>>>>> something extra that just integrates with the core.
>>>>> That may be true, but it's not a decision that should depend on
>>>>> how many
>>>>> modules must be added.
>>>>>
>>>>> The central question is, do we want Keycloak to work out of the box?
>>>>> Before this issue was known, everyone answered "yes".
>>>>>
>>>>> Should we really determine our feature set based on how many
>>>>> modules it
>>>>> requires?   I don't think we want do that, which is why I'm having
>>>>> doubts about the current approach.
>>>>>
>>>>>> In all honesty we are highly unlikely to ever have accepted a PR
>>>>>> that
>>>>>> added all these dependencies to the core in any case, so it is a
>>>>>> problem that would have had to be solved at some point anyway.
>>>>>>
>>>>>> Stuart
>>>>>>
>>>>>> Stan Silvert wrote:
>>>>>>> I'm starting to have doubts about this split.
>>>>>>>
>>>>>>> Right now I'm trying to integrate the Keycloak (client-side)
>>>>>>> adapter
>>>>>>> into build-core so that the web console can use Keycloak for
>>>>>>> authentication.  The problem is that there is a huge web of
>>>>>>> dependencies
>>>>>>> that must be moved over from build to build-core.
>>>>>>>
>>>>>>> What exactly is the split trying to solve?
>>>>>>>
>>>>>>> Stan
>>>>>>>
>>>>>>> On 6/27/2014 12:19 PM, Stuart Douglas wrote:
>>>>>>>> Hi all,
>>>>>>>>
>>>>>>>> So I am moderately confident that we will be ready to split out
>>>>>>>> Wildfly
>>>>>>>> core into a separate repository early next week (I'm not saying
>>>>>>>> that it
>>>>>>>> will definitely happen in this time frame, just that it should be
>>>>>>>> possible).
>>>>>>>>
>>>>>>>> Once this is ready to go I think the basic process will be:
>>>>>>>>
>>>>>>>> - Code freeze on Master
>>>>>>>> - Create the core repo, push new rewritten core history
>>>>>>>> - Release core 1.0.0.Beta1
>>>>>>>> - Create PR against core WF repo that deletes everything in
>>>>>>>> core, and
>>>>>>>> uses the core 1.0.0.Beta1 release
>>>>>>>> - End of code freeze
>>>>>>>>
>>>>>>>> Stuart
>>>>>>>> _______________________________________________
>>>>>>>> wildfly-dev mailing list
>>>>>>>> [hidden email]
>>>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>>> _______________________________________________
>>>>>>> wildfly-dev mailing list
>>>>>>> [hidden email]
>>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>> _______________________________________________
>>>>> wildfly-dev mailing list
>>>>> [hidden email]
>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Pending core split

Tomaž Cerar-2

On Thu, Jul 3, 2014 at 4:02 PM, Stan Silvert <[hidden email]> wrote:
Does this mean web console doesn't work?
No it doesn't, you can add if you need it
 
Does this mean CLI doesn't work?

CLI and domain mode both work.



_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Pending core split

David Lloyd-2
In reply to this post by Stan Silvert
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.

--
- DML
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Pending core split

Thomas Heute
We just had a quick call, here is the summary:

Tomaz Cerar
Stan Silvert
Darran Lofthouse
Thomas Heute
Stian Thorgersen
 
WF "distributions":
    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
 
Future:
    Support for extensions on host controller
    Elytron
 
Plan:
    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
 
Additional link/info: https://community.jboss.org/wiki/WildFly9-HTTPManagementInterfaceConfiguration

Thomas



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.



_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Pending core split

David Lloyd-2
Now that we've democratically wasted everyone's time fairly on this, can
we please all get back to work?

Note that all this dickering has not actually changed the course in any
measurable way - a sure sign of wasted effort.

On 07/03/2014 09:26 AM, Thomas Heute wrote:

> We just had a quick call, here is the summary:
>
> Tomaz Cerar
> Stan Silvert
> Darran Lofthouse
> Thomas Heute
> Stian Thorgersen
>
> WF "distributions":
>      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
>
> Future:
>      Support for extensions on host controller
>      Elytron
>
> Plan:
>      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
>
> Additional link/info:
> https://community.jboss.org/wiki/WildFly9-HTTPManagementInterfaceConfiguration
>
> Thomas
>
>
>
> 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.
>>
>

--
- DML
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Pending core split

Stuart Douglas
In reply to this post by Stan Silvert

> Nothing works out of the box on core?
> Does this mean web console doesn't work?
> Does this mean CLI doesn't work?
>

CLI will work, but there is nothing really there to manage, except for
logging and the core server (system properties, management interface etc).

You could deploy something, but as there are no subsystems the
deployment can't really do anything (there is no Servlet, no EJB etc).

The whole point of core is that it is a platform for other projects
(like the ones Bob mentioned earlier) to build on.

Stuart
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Pending core split

Thomas Heute
In reply to this post by David Lloyd-2
I think it just needed clarifications.

On 07/03/2014 04:29 PM, David M. Lloyd wrote:

> Now that we've democratically wasted everyone's time fairly on this, can
> we please all get back to work?
>
> Note that all this dickering has not actually changed the course in any
> measurable way - a sure sign of wasted effort.
>
> On 07/03/2014 09:26 AM, Thomas Heute wrote:
>> We just had a quick call, here is the summary:
>>
>> Tomaz Cerar
>> Stan Silvert
>> Darran Lofthouse
>> Thomas Heute
>> Stian Thorgersen
>>
>> WF "distributions":
>>       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
>>
>> Future:
>>       Support for extensions on host controller
>>       Elytron
>>
>> Plan:
>>       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
>>
>> Additional link/info:
>> https://community.jboss.org/wiki/WildFly9-HTTPManagementInterfaceConfiguration
>>
>> Thomas
>>
>>
>>
>> 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.
>>>
>>
>
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
123