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 wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev

The point of the core platform is to evolve the base manageable runtime independent of the traditional application server. This allows for many different frameworks and server runtimes to be based on WildFly. It’s a very real request we have had for a long time. The core platform has had a goal from the very beginning to have minimal deps, so if you find yourself adding deps, then it either needs an alternative solution, or it doesn’t belong in core.

On Jun 30, 2014, at 4:47 PM, Stan Silvert <ssilvert(a)redhat.com&gt; 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 >> wildfly-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > _______________________________________________ > wildfly-dev mailing list > wildfly-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat

On 6/30/2014 6:03 PM, Jason Greene wrote: > The point of the core platform is to evolve the base manageable runtime independent of the traditional application server. This allows for many different frameworks and server runtimes to be based on WildFly. It’s a very real request we have had for a long time. > > The core platform has had a goal from the very beginning to have minimal deps, so if you find yourself adding deps, then it either needs an alternative solution, or it doesn’t belong in core. I spent most of last week trying out alternatives and teasing out dependencies. No joy so far. What if we moved domain-http into web-build? That would mean that the web console would not be available in core-build, but I'm not sure it makes sense to be there anyway. Does web console even run against core-build?

> > On Jun 30, 2014, at 4:47 PM, Stan Silvert <ssilvert(a)redhat.com&gt; 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 >>> wildfly-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > -- > Jason T. Greene > WildFly Lead / JBoss EAP Platform Architect > JBoss, a division of Red Hat > _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev

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 > wildfly-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev

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 > wildfly-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev

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 >>> wildfly-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev

On Tue, Jul 1, 2014 at 2:25 PM, Vaclav Tunka <vtunka(a)redhat.com <mailto:vtunka@redhat.com>> wrote: My impression is Keycloak does not belong into the categories above, but maybe I don't know all the details. You don't have all details, but your reasoning is completely sound. Idea is to have keycloak auth mechanism as an option to have SSO for admin console. But that doesn't mean it needs all those dependencies in the core. We need to distinguish between, auth mechanism that should go to domain-http and keycloak subsystem which is completely different beast and should go to probably full distro.

-- tomaz _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev

On 7/1/2014 8:48 AM, Stan Silvert wrote: > On 7/1/2014 8:32 AM, Tomaž Cerar wrote: >> On Tue, Jul 1, 2014 at 2:25 PM, Vaclav Tunka <vtunka(a)redhat.com >> <mailto:vtunka@redhat.com>> wrote: >> >> My impression is Keycloak does not belong into the categories >> above, but maybe I don't know all the details. >> >> >> >> You don't have all details, but your reasoning is completely sound. >> >> Idea is to have keycloak auth mechanism as an option to have SSO for >> admin console. >> But that doesn't mean it needs all those dependencies in the core. >> >> We need to distinguish between, auth mechanism that should go to >> domain-http >> and keycloak subsystem which is completely different beast and should >> go to probably full distro. > We don't necessarily need the keycloak subsystem in order to use > keycloak for authenticating domain-http. But keycloak subsystem is not > the thing that pulls in all the dependencies. It's the keycloak adapter > that does this. > > So if we want keycloak to authenticate domain-http out of the box then > we have to include all this stuff with it. That wasn't a problem before > the split. Almost everything it needed was already there. > "All this stuff" is really just Apache Http Client, Jackson and Bouncycastle.

"Stuff", that Bill said, sounds ok to be part of core. At least in its most bare versions (as all 3 libs can have many modules) RestEasy should never get pulled in, as it requires servlets again... On Tue, Jul 1, 2014 at 3:36 PM, Stan Silvert <ssilvert(a)redhat.com <mailto:ssilvert@redhat.com>> wrote: On 7/1/2014 9:33 AM, Bill Burke wrote: > > On 7/1/2014 8:48 AM, Stan Silvert wrote: >> On 7/1/2014 8:32 AM, Tomaž Cerar wrote: >>> On Tue, Jul 1, 2014 at 2:25 PM, Vaclav Tunka <vtunka(a)redhat.com <mailto:vtunka@redhat.com> >>> <mailto:vtunka@redhat.com <mailto:vtunka@redhat.com>>> wrote: >>> >>> My impression is Keycloak does not belong into the categories >>> above, but maybe I don't know all the details. >>> >>> >>> >>> You don't have all details, but your reasoning is completely sound. >>> >>> Idea is to have keycloak auth mechanism as an option to have SSO for >>> admin console. >>> But that doesn't mean it needs all those dependencies in the core. >>> >>> We need to distinguish between, auth mechanism that should go to >>> domain-http >>> and keycloak subsystem which is completely different beast and should >>> go to probably full distro. >> We don't necessarily need the keycloak subsystem in order to use >> keycloak for authenticating domain-http. But keycloak subsystem is not >> the thing that pulls in all the dependencies. It's the keycloak adapter >> that does this. >> >> So if we want keycloak to authenticate domain-http out of the box then >> we have to include all this stuff with it. That wasn't a problem before >> the split. Almost everything it needed was already there. >> > "All this stuff" is really just Apache Http Client, Jackson and > Bouncycastle. > > Resteasy got pulled in as well. Maybe that was an error on my part? _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org> https://lists.jboss.org/mailman/listinfo/wildfly-dev _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev

"Stuff", that Bill said, sounds ok to be part of core. At least in its most bare versions (as all 3 libs can have many modules) RestEasy should never get pulled in, as it requires servlets again... On Tue, Jul 1, 2014 at 3:36 PM, Stan Silvert <ssilvert(a)redhat.com&gt; wrote: On 7/1/2014 9:33 AM, Bill Burke wrote: > > On 7/1/2014 8:48 AM, Stan Silvert wrote: >> On 7/1/2014 8:32 AM, Tomaž Cerar wrote: >>> On Tue, Jul 1, 2014 at 2:25 PM, Vaclav Tunka <vtunka(a)redhat.com >>> <mailto:vtunka@redhat.com>> wrote: >>> >>> My impression is Keycloak does not belong into the categories >>> above, but maybe I don't know all the details. >>> >>> >>> >>> You don't have all details, but your reasoning is completely sound. >>> >>> Idea is to have keycloak auth mechanism as an option to have SSO for >>> admin console. >>> But that doesn't mean it needs all those dependencies in the core. >>> >>> We need to distinguish between, auth mechanism that should go to >>> domain-http >>> and keycloak subsystem which is completely different beast and should >>> go to probably full distro. >> We don't necessarily need the keycloak subsystem in order to use >> keycloak for authenticating domain-http. But keycloak subsystem is not >> the thing that pulls in all the dependencies. It's the keycloak adapter >> that does this. >> >> So if we want keycloak to authenticate domain-http out of the box then >> we have to include all this stuff with it. That wasn't a problem before >> the split. Almost everything it needed was already there. >> > "All this stuff" is really just Apache Http Client, Jackson and > Bouncycastle. > > Resteasy got pulled in as well. Maybe that was an error on my part? _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev

On 7/1/2014 9:36 AM, Stan Silvert wrote: >> "All this stuff" is really just Apache Http Client, Jackson and >> Bouncycastle. >> >> > Resteasy got pulled in as well. Maybe that was an error on my part? Resteasy is not required for the adapter.

On 7/1/2014 9:51 AM, Stan Silvert wrote: > On 7/1/2014 9:46 AM, Bill Burke wrote: >> On 7/1/2014 9:36 AM, Stan Silvert wrote: >>>> "All this stuff" is really just Apache Http Client, Jackson and >>>> Bouncycastle. >>>> >>>> >>> Resteasy got pulled in as well. Maybe that was an error on my part? >> Resteasy is not required for the adapter. >> >> > Then we've got a problem in a module.xml somwhere. > > jackson-jaxrs depends on javax.ws.rs.ap depends on resteasy-jaxrs Adapter doesn't depend on jackson-jaxrs either. <module xmlns="urn:jboss:module:1.1" name="org.keycloak.keycloak-undertow-adapter"> <resources> <!-- Insert resources here --> </resources> <dependencies> <module name="javax.api"/> <module name="org.bouncycastle"/> <module name="org.codehaus.jackson.jackson-core-asl"/> <module name="org.codehaus.jackson.jackson-mapper-asl"/> <module name="org.codehaus.jackson.jackson-xc"/> <module name="org.apache.httpcomponents" /> <module name="javax.servlet.api"/> <module name="org.jboss.logging"/> <module name="io.undertow.core"/> <module name="io.undertow.servlet"/> <module name="org.keycloak.keycloak-adapter-core"/> <module name="org.keycloak.keycloak-core"/> </dependencies> </module> I think you did some work to refactor the undertow adapter right? So it didn't need the servlet dependency?

Bill

Please also keep in mind the relative complexity of what this does to the dependency set it brings in. For example, I imagine you essentially have a small number of cookie cutter HTTP requests, with the most complex aspect being processing a token. Do you really need jackson object bindings for that? I realize this argument may seem counter-intuitive because its basically an argument against reuse, but thats the challenge we have in core.

Here are some other options already in core that you could potentially use: - DMR - While it’s primary purpose is not JSON processing it gives you a detyped map like API that can be used for this purpose - JDK URL connections - While not the best API, it can get the job done

- Undertow HTTP Client API - this was really just created for the proxy code, so it will be lacking compared to httpclient, but it or the former option might meet your needs.

- FlexBase64 - This is a one class base64 encoder/decoder that is already in core, is fast, and can be used with buffers, streams, and arrays. As mentioned in another email, there is really no replacement for bouncy castle, and so is a good candidate to be added. Again, I totally get it if you don’t want to hack something together *just* for wildfly to be in wildfly core, but thats not a bad thing IMO.

On Tue, Jul 1, 2014 at 2:25 PM, Vaclav Tunka <vtunka(a)redhat.com <mailto:vtunka@redhat.com>> wrote: My impression is Keycloak does not belong into the categories above, but maybe I don't know all the details. You don't have all details, but your reasoning is completely sound. Idea is to have keycloak auth mechanism as an option to have SSO for admin console. But that doesn't mean it needs all those dependencies in the core. We need to distinguish between, auth mechanism that should go to domain-http and keycloak subsystem which is completely different beast and should go to probably full distro.

-- tomaz _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev

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. This has nothing to do with 'working out of the box', e.g. Servlet and EJB will 'work out of the box', as long as you pick a distribution that includes them.

> >> >> 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 >>>> wildfly-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>> >>> _______________________________________________ >>> wildfly-dev mailing list >>> wildfly-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >

Looking at the code of https://github.com/keycloak/keycloak/blob/master/integration/undertow/src... i think there could be better way other than using ServletExtension to achieve same thing for what you need in domain-http. It can stay as is for subsystem stuff. Also lots of classes in that module, have nothing to do with core SSO need in domain-http (Servlet*) as there will be no servlet requests coming that way. In short I think just moving some code around and modifying few classes we could get rid of many dependancies. On Tue, Jul 1, 2014 at 2:52 PM, Stan Silvert <ssilvert(a)redhat.com <mailto:ssilvert@redhat.com>> wrote: On 7/1/2014 8:49 AM, Stuart Douglas wrote: > > > 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. > > This has nothing to do with 'working out of the box', e.g. Servlet and > EJB will 'work out of the box', as long as you pick a distribution > that includes them. 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. > > > > >> >>> >>> 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 >>>>> wildfly-dev(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org> >>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>> >>>> _______________________________________________ >>>> wildfly-dev mailing list >>>> wildfly-dev(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org> >>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org> https://lists.jboss.org/mailman/listinfo/wildfly-dev

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

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 >>>>>> wildfly-dev(a)lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>>> >>>>> _______________________________________________ >>>>> wildfly-dev mailing list >>>>> wildfly-dev(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>> >

There are many possible solutions: > * 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. Stuart

>> >> Stuart > Yes, that's pretty much what I was thinking. Thanks for the offer to > help. > > If there are no objections, I'll pursue the "redesign domain-http" > solution. > > This means: > * By default, Keycloak is not available in core. But it could possibly > be added. > * Keycloak will be available in web-build and full build. > * Approximately 20 modules will be moved from full build to web-build. Do you know which modules? Web build is supposed to be a lightweight build that basically just provides a web server, that can be used as a Tomcat equivalent or as the base for a product that only requires a web server. Stuart

> * Delivery of Keycloak integration will be delayed. I don't know by how > much yet. > > Sound OK?

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.

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.

* Allow the extra dependencies. * Redesign domain-http

* 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 >>>>>>> wildfly-dev(a)lists.jboss.org >>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>>>> >>>>>> _______________________________________________ >>>>>> wildfly-dev mailing list >>>>>> wildfly-dev(a)lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>> >> _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev

> 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 >>>> wildfly-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>> >>> _______________________________________________ >>> wildfly-dev mailing list >>> wildfly-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev

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 > <darran.lofthouse(a)jboss.com <mailto:darran.lofthouse@jboss.com>> 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 > >>>> wildfly-dev(a)lists.jboss.org > <mailto:wildfly-dev@lists.jboss.org> > >>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev > >>> > >>> _______________________________________________ > >>> wildfly-dev mailing list > >>> wildfly-dev(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org> > >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > > _______________________________________________ > > wildfly-dev mailing list > > wildfly-dev(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org> > > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/wildfly-dev > >

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 >>>>> wildfly-dev(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>> >>>> _______________________________________________ >>>> wildfly-dev mailing list >>>> wildfly-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev

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&lt;ssilvert(a)redhat.com&gt; 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 >>>>>>> wildfly-dev(a)lists.jboss.org >>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>>>> _______________________________________________ >>>>>> wildfly-dev mailing list >>>>>> wildfly-dev(a)lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>> _______________________________________________ >>>> wildfly-dev mailing list >>>> wildfly-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev

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.

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

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