From: "Stan Silvert" <ssilvert(a)redhat.com&gt; To: keycloak-dev(a)lists.jboss.org Sent: Monday, 1 December, 2014 4:53:47 PM Subject: Re: [keycloak-dev] release? Stan? On 12/1/2014 10:08 AM, Bill Burke wrote: > So, is EAP subsystem complete? Documented? Can we do a Beta2 release > this week? > > Yes. All merged. Docs are updated. Should be ready to go. _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev

On 12/2/2014 4:52 AM, Stian Thorgersen wrote: > Should we upgrade to WF 8.2 and also do some changes to the distro before release? I don't see a reason not to go to WF 8.2. If we do that, let me know so I can run a quick smoke test on the subsystem before we release. > > With regards to distro we should move the adapters and examples into separate downloads. Also, we should move the examples into a separate github project (keycloak/keycloak-examples). This will make it easier for those that wants to fork the examples separately. > > Also, we should consider a download based on the web-lite profile. For non-JavaEE apps, containers (Docker) and those that want to run a standalone KC server it would be nice to have a small as possible distro. Depending on how the feature pack turns out, we might be able to offer many flavors of the appliance distro without any additional effort. We could have: EAP6 + Keycloak AS7 + Keycloak WF8 (web) + Keycloak WF8 (full) + Keycloak WF 9 beta (web) + Keycloak WF 9 beta (full) + Keycloak etc.

----- Original Message ----- > From: "Bill Burke" <bburke(a)redhat.com&gt; > To: keycloak-dev(a)lists.jboss.org > Sent: Tuesday, 2 December, 2014 2:38:32 PM > Subject: Re: [keycloak-dev] release? Stan? > > > > On 12/2/2014 7:55 AM, Stan Silvert wrote: >> On 12/2/2014 4:52 AM, Stian Thorgersen wrote: >>> Should we upgrade to WF 8.2 and also do some changes to the distro before >>> release? >> I don't see a reason not to go to WF 8.2. If we do that, let me know so >> I can run a quick smoke test on the subsystem before we release. >>> >>> With regards to distro we should move the adapters and examples into >>> separate downloads. Also, we should move the examples into a separate >>> github project (keycloak/keycloak-examples). This will make it easier for >>> those that wants to fork the examples separately. >>> >>> Also, we should consider a download based on the web-lite profile. For >>> non-JavaEE apps, containers (Docker) and those that want to run a >>> standalone KC server it would be nice to have a small as possible distro. >> Depending on how the feature pack turns out, we might be able to offer >> many flavors of the appliance distro without any additional effort. We >> could have: >> EAP6 + Keycloak >> AS7 + Keycloak >> WF8 (web) + Keycloak >> WF8 (full) + Keycloak >> WF 9 beta (web) + Keycloak >> WF 9 beta (full) + Keycloak >> etc. >> > > IMO, we just need: > * war-dist > * appliance-dist > > Appliance distribution would have the most stable platform available. > Since we can't distribute EAP, then it would be the most stable and > maintained version of Wildfly that allows us to cluster and deploy Keycloak. Our download at the moment is 160MB and is really aimed at the first-time JavaEE user (bundled with examples and documentation). Why should we require someone that just wants to upgrade their server to download all of that? There'll also be loads of people that don't need the JavaEE parts, a NodeJS developer or deploying to cloud for example. I think we could easily have a standalone Keycloak server download that'd be around 30MB. IMO we should have: * Minimal server (based on WildFly web/core) * Full server (based on WildFly full) * Feature pack - to easily install onto other version of WF, EAP, etc. Neither of those downloads should include docs or examples. As we don't really support installing onto Tomcat or Jetty, why have a war-dist?

From: "Bill Burke" <bburke(a)redhat.com&gt; To: "Stian Thorgersen" <stian(a)redhat.com&gt; Cc: keycloak-dev(a)lists.jboss.org Sent: Tuesday, 2 December, 2014 4:11:19 PM Subject: Re: [keycloak-dev] release? Stan? On 12/2/2014 9:02 AM, Stian Thorgersen wrote: > > > ----- Original Message ----- >> From: "Bill Burke" <bburke(a)redhat.com&gt; >> To: keycloak-dev(a)lists.jboss.org >> Sent: Tuesday, 2 December, 2014 2:38:32 PM >> Subject: Re: [keycloak-dev] release? Stan? >> >> >> >> On 12/2/2014 7:55 AM, Stan Silvert wrote: >>> On 12/2/2014 4:52 AM, Stian Thorgersen wrote: >>>> Should we upgrade to WF 8.2 and also do some changes to the distro >>>> before >>>> release? >>> I don't see a reason not to go to WF 8.2. If we do that, let me know so >>> I can run a quick smoke test on the subsystem before we release. >>>> >>>> With regards to distro we should move the adapters and examples into >>>> separate downloads. Also, we should move the examples into a separate >>>> github project (keycloak/keycloak-examples). This will make it easier >>>> for >>>> those that wants to fork the examples separately. >>>> >>>> Also, we should consider a download based on the web-lite profile. For >>>> non-JavaEE apps, containers (Docker) and those that want to run a >>>> standalone KC server it would be nice to have a small as possible >>>> distro. >>> Depending on how the feature pack turns out, we might be able to offer >>> many flavors of the appliance distro without any additional effort. We >>> could have: >>> EAP6 + Keycloak >>> AS7 + Keycloak >>> WF8 (web) + Keycloak >>> WF8 (full) + Keycloak >>> WF 9 beta (web) + Keycloak >>> WF 9 beta (full) + Keycloak >>> etc. >>> >> >> IMO, we just need: >> * war-dist >> * appliance-dist >> >> Appliance distribution would have the most stable platform available. >> Since we can't distribute EAP, then it would be the most stable and >> maintained version of Wildfly that allows us to cluster and deploy >> Keycloak. > > Our download at the moment is 160MB and is really aimed at the first-time > JavaEE user (bundled with examples and documentation). Why should we > require someone that just wants to upgrade their server to download all of > that? There'll also be loads of people that don't need the JavaEE parts, a > NodeJS developer or deploying to cloud for example. I think we could > easily have a standalone Keycloak server download that'd be around 30MB. > > IMO we should have: > > * Minimal server (based on WildFly web/core) > * Full server (based on WildFly full) > * Feature pack - to easily install onto other version of WF, EAP, etc. > > Neither of those downloads should include docs or examples. As we don't > really support installing onto Tomcat or Jetty, why have a war-dist? > I disagree. At least one download should have everything: docs, examples, and a distro that can run the examples. Reducing even simple steps for 1st time users is crucial to adoption. How fast a first time user can get "hello world" running is crucial. BTW, That's a major reason why your suggestion earlier of having examples on Github is not a great idea.

Why have a war-dist? So we can deploy to EAP 6. AFAIK, EAP 6 doesn't support feature packs. war-dist could change to subsystem-dist I guess since, as you said, we don't really support installing into tomcat or jetty. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com

----- Original Message ----- > From: "Bill Burke" <bburke(a)redhat.com&gt; > To: "Stian Thorgersen" <stian(a)redhat.com&gt; > Cc: keycloak-dev(a)lists.jboss.org > Sent: Tuesday, 2 December, 2014 4:11:19 PM > Subject: Re: [keycloak-dev] release? Stan? > > > > On 12/2/2014 9:02 AM, Stian Thorgersen wrote: >> >> >> ----- Original Message ----- >>> From: "Bill Burke" <bburke(a)redhat.com&gt; >>> To: keycloak-dev(a)lists.jboss.org >>> Sent: Tuesday, 2 December, 2014 2:38:32 PM >>> Subject: Re: [keycloak-dev] release? Stan? >>> >>> >>> >>> On 12/2/2014 7:55 AM, Stan Silvert wrote: >>>> On 12/2/2014 4:52 AM, Stian Thorgersen wrote: >>>>> Should we upgrade to WF 8.2 and also do some changes to the distro >>>>> before >>>>> release? >>>> I don't see a reason not to go to WF 8.2. If we do that, let me know so >>>> I can run a quick smoke test on the subsystem before we release. >>>>> >>>>> With regards to distro we should move the adapters and examples into >>>>> separate downloads. Also, we should move the examples into a separate >>>>> github project (keycloak/keycloak-examples). This will make it easier >>>>> for >>>>> those that wants to fork the examples separately. >>>>> >>>>> Also, we should consider a download based on the web-lite profile. For >>>>> non-JavaEE apps, containers (Docker) and those that want to run a >>>>> standalone KC server it would be nice to have a small as possible >>>>> distro. >>>> Depending on how the feature pack turns out, we might be able to offer >>>> many flavors of the appliance distro without any additional effort. We >>>> could have: >>>> EAP6 + Keycloak >>>> AS7 + Keycloak >>>> WF8 (web) + Keycloak >>>> WF8 (full) + Keycloak >>>> WF 9 beta (web) + Keycloak >>>> WF 9 beta (full) + Keycloak >>>> etc. >>>> >>> >>> IMO, we just need: >>> * war-dist >>> * appliance-dist >>> >>> Appliance distribution would have the most stable platform available. >>> Since we can't distribute EAP, then it would be the most stable and >>> maintained version of Wildfly that allows us to cluster and deploy >>> Keycloak. >> >> Our download at the moment is 160MB and is really aimed at the first-time >> JavaEE user (bundled with examples and documentation). Why should we >> require someone that just wants to upgrade their server to download all of >> that? There'll also be loads of people that don't need the JavaEE parts, a >> NodeJS developer or deploying to cloud for example. I think we could >> easily have a standalone Keycloak server download that'd be around 30MB. >> >> IMO we should have: >> >> * Minimal server (based on WildFly web/core) >> * Full server (based on WildFly full) >> * Feature pack - to easily install onto other version of WF, EAP, etc. >> >> Neither of those downloads should include docs or examples. As we don't >> really support installing onto Tomcat or Jetty, why have a war-dist? >> > > I disagree. At least one download should have everything: docs, > examples, and a distro that can run the examples. Reducing even simple > steps for 1st time users is crucial to adoption. How fast a first time > user can get "hello world" running is crucial. BTW, That's a major > reason why your suggestion earlier of having examples on Github is not a > great idea. WildFly, PicketLink, Infinispan, etc. all use the same approach for quickstarts. They're in GitHub in a separate project, which can easily be forked/cloned by users. This is IMO a much better way to get started than downloading a zip. Problem is that currently we don't cater for those that want to fork/clone the examples as they have to do everything, which would at least stop me from doing it. If we put it in a separate project that doesn't stop us from releasing a bundle with everything in it. It just adds an extra step to the releasing, which could be automated with a script.

Personally, I download servers then read docs online and clone/fork examples/quickstarts. Second time around I don't need examples/quickstarts and it annoys me that I have to get a bundle with everything, when all I want is the server.

----- Original Message ----- > From: "Bill Burke" <bburke(a)redhat.com&gt; > To: "Stian Thorgersen" <stian(a)redhat.com&gt; > Cc: keycloak-dev(a)lists.jboss.org > Sent: Tuesday, 2 December, 2014 5:31:12 PM > Subject: Re: [keycloak-dev] release? Stan? > > > > On 12/2/2014 10:53 AM, Stian Thorgersen wrote: >> >> >> ----- Original Message ----- >>> From: "Bill Burke" <bburke(a)redhat.com&gt; >>> To: "Stian Thorgersen" <stian(a)redhat.com&gt; >>> Cc: keycloak-dev(a)lists.jboss.org >>> Sent: Tuesday, 2 December, 2014 4:11:19 PM >>> Subject: Re: [keycloak-dev] release? Stan? >>> >>> >>> >>> On 12/2/2014 9:02 AM, Stian Thorgersen wrote: >>>> >>>> >>>> ----- Original Message ----- >>>>> From: "Bill Burke" <bburke(a)redhat.com&gt; >>>>> To: keycloak-dev(a)lists.jboss.org >>>>> Sent: Tuesday, 2 December, 2014 2:38:32 PM >>>>> Subject: Re: [keycloak-dev] release? Stan? >>>>> >>>>> >>>>> >>>>> On 12/2/2014 7:55 AM, Stan Silvert wrote: >>>>>> On 12/2/2014 4:52 AM, Stian Thorgersen wrote: >>>>>>> Should we upgrade to WF 8.2 and also do some changes to the distro >>>>>>> before >>>>>>> release? >>>>>> I don't see a reason not to go to WF 8.2. If we do that, let me know >>>>>> so >>>>>> I can run a quick smoke test on the subsystem before we release. >>>>>>> >>>>>>> With regards to distro we should move the adapters and examples into >>>>>>> separate downloads. Also, we should move the examples into a separate >>>>>>> github project (keycloak/keycloak-examples). This will make it easier >>>>>>> for >>>>>>> those that wants to fork the examples separately. >>>>>>> >>>>>>> Also, we should consider a download based on the web-lite profile. For >>>>>>> non-JavaEE apps, containers (Docker) and those that want to run a >>>>>>> standalone KC server it would be nice to have a small as possible >>>>>>> distro. >>>>>> Depending on how the feature pack turns out, we might be able to offer >>>>>> many flavors of the appliance distro without any additional effort. We >>>>>> could have: >>>>>> EAP6 + Keycloak >>>>>> AS7 + Keycloak >>>>>> WF8 (web) + Keycloak >>>>>> WF8 (full) + Keycloak >>>>>> WF 9 beta (web) + Keycloak >>>>>> WF 9 beta (full) + Keycloak >>>>>> etc. >>>>>> >>>>> >>>>> IMO, we just need: >>>>> * war-dist >>>>> * appliance-dist >>>>> >>>>> Appliance distribution would have the most stable platform available. >>>>> Since we can't distribute EAP, then it would be the most stable and >>>>> maintained version of Wildfly that allows us to cluster and deploy >>>>> Keycloak. >>>> >>>> Our download at the moment is 160MB and is really aimed at the first-time >>>> JavaEE user (bundled with examples and documentation). Why should we >>>> require someone that just wants to upgrade their server to download all >>>> of >>>> that? There'll also be loads of people that don't need the JavaEE parts, >>>> a >>>> NodeJS developer or deploying to cloud for example. I think we could >>>> easily have a standalone Keycloak server download that'd be around 30MB. >>>> >>>> IMO we should have: >>>> >>>> * Minimal server (based on WildFly web/core) >>>> * Full server (based on WildFly full) >>>> * Feature pack - to easily install onto other version of WF, EAP, etc. >>>> >>>> Neither of those downloads should include docs or examples. As we don't >>>> really support installing onto Tomcat or Jetty, why have a war-dist? >>>> >>> >>> I disagree. At least one download should have everything: docs, >>> examples, and a distro that can run the examples. Reducing even simple >>> steps for 1st time users is crucial to adoption. How fast a first time >>> user can get "hello world" running is crucial. BTW, That's a major >>> reason why your suggestion earlier of having examples on Github is not a >>> great idea. >> >> WildFly, PicketLink, Infinispan, etc. all use the same approach for >> quickstarts. They're in GitHub in a separate project, which can easily be >> forked/cloned by users. This is IMO a much better way to get started than >> downloading a zip. Problem is that currently we don't cater for those that >> want to fork/clone the examples as they have to do everything, which would >> at least stop me from doing it. If we put it in a separate project that >> doesn't stop us from releasing a bundle with everything in it. It just >> adds an extra step to the releasing, which could be automated with a >> script. >> > > Just because everybody does it doesn't mean it is a good idea. I really > hate that they do that and have run into problems. Let me give more > reasons why it is a bad idea: > > * A user may never have used github Sure, so let's have a download from them as well. In fact you can download a github repo with a single click. > * There may be an incompatibility with the version developer is using > vs. the master example branch. > * Requires user to either edit example pom to point to desired project > version or to checkout correct tag. I agree with versions being a bit of an issue, but that's easily fixed with tags. Also, I'm fine with having a bundle with everything in it as well for those that want that. I just want to cater for those that don't as well. > * Keycloak examples are currently active modules in our main git repo. > They load up as a module in our IDE. Examples are targeted for refactor > events just like any other project. You can import multiple mvn projects into the same IDE project.

> * Keycloak examples are built with build. Thus catching any compiler > bugs that often happen when refactoring Keycloak SPIs, APIs, or whatever. See above + we should have continuous integration running tests on examples against head of KC

----- Original Message ----- > From: "Bill Burke" <bburke(a)redhat.com&gt; > To: "Stian Thorgersen" <stian(a)redhat.com&gt; > Cc: keycloak-dev(a)lists.jboss.org > Sent: Wednesday, 3 December, 2014 3:03:51 PM > Subject: Re: [keycloak-dev] release? Stan? > > > > On 12/3/2014 2:38 AM, Stian Thorgersen wrote: > > > > > > ----- Original Message ----- > >> From: "Bill Burke" <bburke(a)redhat.com&gt; > >> To: "Stian Thorgersen" <stian(a)redhat.com&gt; > >> Cc: keycloak-dev(a)lists.jboss.org > >> Sent: Tuesday, 2 December, 2014 5:31:12 PM > >> Subject: Re: [keycloak-dev] release? Stan? > >> > >> > >> > >> On 12/2/2014 10:53 AM, Stian Thorgersen wrote: > >>> > >>> > >>> ----- Original Message ----- > >>>> From: "Bill Burke" <bburke(a)redhat.com&gt; > >>>> To: "Stian Thorgersen" <stian(a)redhat.com&gt; > >>>> Cc: keycloak-dev(a)lists.jboss.org > >>>> Sent: Tuesday, 2 December, 2014 4:11:19 PM > >>>> Subject: Re: [keycloak-dev] release? Stan? > >>>> > >>>> > >>>> > >>>> On 12/2/2014 9:02 AM, Stian Thorgersen wrote: > >>>>> > >>>>> > >>>>> ----- Original Message ----- > >>>>>> From: "Bill Burke" <bburke(a)redhat.com&gt; > >>>>>> To: keycloak-dev(a)lists.jboss.org > >>>>>> Sent: Tuesday, 2 December, 2014 2:38:32 PM > >>>>>> Subject: Re: [keycloak-dev] release? Stan? > >>>>>> > >>>>>> > >>>>>> > >>>>>> On 12/2/2014 7:55 AM, Stan Silvert wrote: > >>>>>>> On 12/2/2014 4:52 AM, Stian Thorgersen wrote: > >>>>>>>> Should we upgrade to WF 8.2 and also do some changes to the distro > >>>>>>>> before > >>>>>>>> release? > >>>>>>> I don't see a reason not to go to WF 8.2. If we do that, let me know > >>>>>>> so > >>>>>>> I can run a quick smoke test on the subsystem before we release. > >>>>>>>> > >>>>>>>> With regards to distro we should move the adapters and examples into > >>>>>>>> separate downloads. Also, we should move the examples into a > >>>>>>>> separate > >>>>>>>> github project (keycloak/keycloak-examples). This will make it > >>>>>>>> easier > >>>>>>>> for > >>>>>>>> those that wants to fork the examples separately. > >>>>>>>> > >>>>>>>> Also, we should consider a download based on the web-lite profile. > >>>>>>>> For > >>>>>>>> non-JavaEE apps, containers (Docker) and those that want to run a > >>>>>>>> standalone KC server it would be nice to have a small as possible > >>>>>>>> distro. > >>>>>>> Depending on how the feature pack turns out, we might be able to > >>>>>>> offer > >>>>>>> many flavors of the appliance distro without any additional effort. > >>>>>>> We > >>>>>>> could have: > >>>>>>> EAP6 + Keycloak > >>>>>>> AS7 + Keycloak > >>>>>>> WF8 (web) + Keycloak > >>>>>>> WF8 (full) + Keycloak > >>>>>>> WF 9 beta (web) + Keycloak > >>>>>>> WF 9 beta (full) + Keycloak > >>>>>>> etc. > >>>>>>> > >>>>>> > >>>>>> IMO, we just need: > >>>>>> * war-dist > >>>>>> * appliance-dist > >>>>>> > >>>>>> Appliance distribution would have the most stable platform available. > >>>>>> Since we can't distribute EAP, then it would be the most stable and > >>>>>> maintained version of Wildfly that allows us to cluster and deploy > >>>>>> Keycloak. > >>>>> > >>>>> Our download at the moment is 160MB and is really aimed at the > >>>>> first-time > >>>>> JavaEE user (bundled with examples and documentation). Why should we > >>>>> require someone that just wants to upgrade their server to download all > >>>>> of > >>>>> that? There'll also be loads of people that don't need the JavaEE > >>>>> parts, > >>>>> a > >>>>> NodeJS developer or deploying to cloud for example. I think we could > >>>>> easily have a standalone Keycloak server download that'd be around > >>>>> 30MB. > >>>>> > >>>>> IMO we should have: > >>>>> > >>>>> * Minimal server (based on WildFly web/core) > >>>>> * Full server (based on WildFly full) > >>>>> * Feature pack - to easily install onto other version of WF, EAP, etc. > >>>>> > >>>>> Neither of those downloads should include docs or examples. As we don't > >>>>> really support installing onto Tomcat or Jetty, why have a war-dist? > >>>>> > >>>> > >>>> I disagree. At least one download should have everything: docs, > >>>> examples, and a distro that can run the examples. Reducing even simple > >>>> steps for 1st time users is crucial to adoption. How fast a first time > >>>> user can get "hello world" running is crucial. BTW, That's a major > >>>> reason why your suggestion earlier of having examples on Github is not a > >>>> great idea. > >>> > >>> WildFly, PicketLink, Infinispan, etc. all use the same approach for > >>> quickstarts. They're in GitHub in a separate project, which can easily be > >>> forked/cloned by users. This is IMO a much better way to get started than > >>> downloading a zip. Problem is that currently we don't cater for those > >>> that > >>> want to fork/clone the examples as they have to do everything, which > >>> would > >>> at least stop me from doing it. If we put it in a separate project that > >>> doesn't stop us from releasing a bundle with everything in it. It just > >>> adds an extra step to the releasing, which could be automated with a > >>> script. > >>> > >> > >> Just because everybody does it doesn't mean it is a good idea. I really > >> hate that they do that and have run into problems. Let me give more > >> reasons why it is a bad idea: > >> > >> * A user may never have used github > > > > Sure, so let's have a download from them as well. In fact you can download > > a github repo with a single click. > > > >> * There may be an incompatibility with the version developer is using > >> vs. the master example branch. > >> * Requires user to either edit example pom to point to desired project > >> version or to checkout correct tag. > > > > I agree with versions being a bit of an issue, but that's easily fixed with > > tags. Also, I'm fine with having a bundle with everything in it as well > > for those that want that. I just want to cater for those that don't as > > well. > > > >> * Keycloak examples are currently active modules in our main git repo. > >> They load up as a module in our IDE. Examples are targeted for refactor > >> events just like any other project. > > > > You can import multiple mvn projects into the same IDE project. > > > > We can barely get contributors to perform a build before submitting a PR. And you expect external contributors to do large changes to API's or refactor code? With proper CI integration we can build automatically on PRs so contributors don't have to run tests at all. Which we should do in either case as we can't just merge an external PR without at least checking it builds and tests pass first. > > >> * Keycloak examples are built with build. Thus catching any compiler > >> bugs that often happen when refactoring Keycloak SPIs, APIs, or whatever. > > > > See above + we should have continuous integration running tests on examples > > against head of KC > > > > So, more infrastructure to support something that is already done? There's nothing extra - we don't test examples currently, and testing examples whether or not they're part of the core code or a separate project makes no difference IMO. > > I just don't see how a git repo for examples gives you any advantages > over the current situation. It just complicates things all around both > for users and keycloak contributors. Seriously what are the advantages > other than saving a few meg in a distro? More and more people are used to GitHub these days, especially in Open Source. I certainly wouldn't want to clone a large code-base to get just the examples. With a GitHub fork of examples users can fork the examples and play with them, instead of having to extract the zip then commit it to a separate GitHub. It also lets you add examples or fix examples after a release. For automation/scripting things there's a lot more steps involved, as well as a longer spin-up time of images. The more docs (and images) and examples we add the bigger the distro. As a user of Keycloak I would actually have ended up with repackaging KC server for distribution internally as ours isn't suitable for it. This may be a Linux thing, but I have loads of scripts that automate things for me. With the distro I'm looking for I can script installation of KC to just: curl <KEYCLOAK DOWNLOAD URL> | tar zx While with our current distro I need to do: curl -O <KEYCLOAK DOWNLOAD URL> unzip keycloak-appliance-dist-all-<KEYCLOAK_VERSION>.zip mv keycloak-appliance-dist-all-<KEYCLOAK_VERSION>/keycloak keycloak-<KEYCLOAK_VERSION> rm -rf keycloak-appliance-dist-all-<KEYCLOAK_VERSION> It would also be nice to have a similar developer experience to other JBoss projects. > > > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev

One slightly related issue. I just did some testing and figured that eap6.3 and as7 distribution were broken as they excluded keycloak-subsystem . I've fixed that and EAP 6.3 works fine now. But on AS 7.1.1 the keycloak-subsystem doesn't work and I have: Caused by: java.lang.ClassNotFoundException: org.jboss.as.controller.OperationDefinition from [Module "org.keycloak.keycloak-subsystem:main" I am seeing options like: 1) Drop AS7 support 2) Revert AS7 specific subsystem 3) Do some hack in keycloak-subsystem to have it working on AS 7.1.1 (is it doable?) Anything else I am missing? Marek On 2.12.2014 14:38, Bill Burke wrote: > > On 12/2/2014 7:55 AM, Stan Silvert wrote: >> On 12/2/2014 4:52 AM, Stian Thorgersen wrote: >>> Should we upgrade to WF 8.2 and also do some changes to the distro >>> before release? >> I don't see a reason not to go to WF 8.2. If we do that, let me know so >> I can run a quick smoke test on the subsystem before we release. >>> With regards to distro we should move the adapters and examples into >>> separate downloads. Also, we should move the examples into a >>> separate github project (keycloak/keycloak-examples). This will make >>> it easier for those that wants to fork the examples separately. >>> >>> Also, we should consider a download based on the web-lite profile. >>> For non-JavaEE apps, containers (Docker) and those that want to run >>> a standalone KC server it would be nice to have a small as possible >>> distro. >> Depending on how the feature pack turns out, we might be able to offer >> many flavors of the appliance distro without any additional effort. We >> could have: >> EAP6 + Keycloak >> AS7 + Keycloak >> WF8 (web) + Keycloak >> WF8 (full) + Keycloak >> WF 9 beta (web) + Keycloak >> WF 9 beta (full) + Keycloak >> etc. >> > IMO, we just need: > * war-dist > * appliance-dist > > Appliance distribution would have the most stable platform available. > Since we can't distribute EAP, then it would be the most stable and > maintained version of Wildfly that allows us to cluster and deploy > Keycloak. > >

Maybe an option is to keep just adapter support on AS7, but drop support for the auth-server itself on AS7? Of course, if we are able to somehow fix everything, it might be best option:-) Marek On 2.12.2014 20:49, Bill Burke wrote: > We should keep as7 adapter support at least. We support older > versions of Jetty and tomcat too, it would be strange not to support > AS7. Hopefully stan has a fix. > > Looking at it, it looks like OperationDefinition is only within > auth-server subsystem. That could be the "hack' you're talkin about. > > Shouldn't the auth-server and adapter should be separate subsystems > anyways? > > On 12/2/2014 2:37 PM, Marek Posolda wrote: >> One slightly related issue. I just did some testing and figured that >> eap6.3 and as7 distribution were broken as they excluded >> keycloak-subsystem . I've fixed that and EAP 6.3 works fine now. But on >> AS 7.1.1 the keycloak-subsystem doesn't work and I have: >> >> Caused by: java.lang.ClassNotFoundException: >> org.jboss.as.controller.OperationDefinition from [Module >> "org.keycloak.keycloak-subsystem:main" >> >> I am seeing options like: >> 1) Drop AS7 support >> 2) Revert AS7 specific subsystem >> 3) Do some hack in keycloak-subsystem to have it working on AS 7.1.1 (is >> it doable?) >> >> Anything else I am missing? >> >> Marek >> >> On 2.12.2014 14:38, Bill Burke wrote: >>> On 12/2/2014 7:55 AM, Stan Silvert wrote: >>>> On 12/2/2014 4:52 AM, Stian Thorgersen wrote: >>>>> Should we upgrade to WF 8.2 and also do some changes to the distro >>>>> before release? >>>> I don't see a reason not to go to WF 8.2. If we do that, let me >>>> know so >>>> I can run a quick smoke test on the subsystem before we release. >>>>> With regards to distro we should move the adapters and examples into >>>>> separate downloads. Also, we should move the examples into a >>>>> separate github project (keycloak/keycloak-examples). This will make >>>>> it easier for those that wants to fork the examples separately. >>>>> >>>>> Also, we should consider a download based on the web-lite profile. >>>>> For non-JavaEE apps, containers (Docker) and those that want to run >>>>> a standalone KC server it would be nice to have a small as possible >>>>> distro. >>>> Depending on how the feature pack turns out, we might be able to offer >>>> many flavors of the appliance distro without any additional >>>> effort. We >>>> could have: >>>> EAP6 + Keycloak >>>> AS7 + Keycloak >>>> WF8 (web) + Keycloak >>>> WF8 (full) + Keycloak >>>> WF 9 beta (web) + Keycloak >>>> WF 9 beta (full) + Keycloak >>>> etc. >>>> >>> IMO, we just need: >>> * war-dist >>> * appliance-dist >>> >>> Appliance distribution would have the most stable platform available. >>> Since we can't distribute EAP, then it would be the most stable and >>> maintained version of Wildfly that allows us to cluster and deploy >>> Keycloak. >>> >>> _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev

oops, thanks to you for reporting issue to me this time:-) It should be fixed now. Let me know if it helps.

Marek On 2.12.2014 21:12, Stan Silvert wrote: > We may have other problems. I just updated to the latest and OSGI > core adapter fails to build. I can continue what I'm doing because > the AS7 adapter built successfully. > > See WARNING below. Possibly a Windows problem? > > [INFO] Building Keycloak OSGI Core Adapter Integration > 1.1.0.Beta2-SNAPSHOT > [INFO] > ------------------------------------------------------------------------ > [INFO] > [INFO] --- buildnumber-maven-plugin:1.3:create-timestamp > (get-build-timestamp) @ keycloak-osgi-core-adapter --- > [INFO] > [INFO] --- buildnumber-maven-plugin:1.3:create (get-scm-revision) @ > keycloak-osgi-core-adapter --- > [INFO] > [INFO] --- maven-resources-plugin:2.6:resources (default-resources) @ > keycloak-osgi-core-adapter --- > [WARNING] Using platform encoding (Cp1252 actually) to copy filtered > resources, i.e. build is platform dependent! > [INFO] skip non existing resourceDirectory > C:\GitHub\keycloak\distribution\osgi\core-adapter\src\main\resources > [INFO] > [INFO] --- maven-compiler-plugin:2.3.1:compile (default-compile) @ > keycloak-osgi-core-adapter --- > [INFO] No sources to compile > [INFO] > [INFO] --- maven-bundle-plugin:2.3.7:manifest (bundle-manifest) @ > keycloak-osgi-core-adapter --- > [INFO] > ------------------------------------------------------------------------ > [INFO] Reactor Summary: > [INFO] > [INFO] Keycloak JBoss Modules ............................. SUCCESS > [ 7.552 s] > [INFO] Keycloak AS7 Adapter Distro ........................ SUCCESS > [ 0.798 s] > [INFO] Keycloak Tomcat 6 Adapter Distro ................... SUCCESS > [ 0.438 s] > [INFO] Keycloak Tomcat 7 Adapter Distro ................... SUCCESS > [ 0.185 s] > [INFO] Keycloak Tomcat 8 Adapter Distro ................... SUCCESS > [ 0.168 s] > [INFO] Keycloak EAP6 Adapter Distro ....................... SUCCESS > [ 0.738 s] > [INFO] Keycloak Wildfly Adapter Distro .................... SUCCESS > [ 0.838 s] > [INFO] Keycloak Jetty 8.1.x Adapter Distro ................ SUCCESS > [ 0.261 s] > [INFO] Keycloak Jetty 9.1.x Adapter Distro ................ SUCCESS > [ 0.257 s] > [INFO] Keycloak Jetty 9.2.x Adapter Distro ................ SUCCESS > [ 0.294 s] > [INFO] Keycloak Examples and Doc Distribution ............. SUCCESS > [ 5.459 s] > [INFO] Keycloak Example Themes ............................ SUCCESS > [ 1.361 s] > [INFO] Keycloak WAR Deployment For Wildfly/AS7/EAP ........ SUCCESS > [ 1.657 s] > [INFO] Keycloak WAR Distribution .......................... SUCCESS > [ 5.911 s] > [INFO] Keycloak OSGI Features ............................. SUCCESS > [ 0.433 s] > [INFO] Keycloak OSGI Core Adapter Integration ............. FAILURE > [ 0.328 s] > [INFO] Keycloak OSGI JAAS ................................. SKIPPED > [INFO] Keycloak OSGI Integration .......................... SKIPPED > [INFO] Proxy Distro ....................................... SKIPPED > [INFO] Keycloak Appliance Distribution .................... SKIPPED > [INFO] Keycloak Source Distribution ....................... SKIPPED > [INFO] Distribution ....................................... SKIPPED > [INFO] > ------------------------------------------------------------------------ > [INFO] BUILD FAILURE > [INFO] > ------------------------------------------------------------------------ > [INFO] Total time: 27.514 s > [INFO] Finished at: 2014-12-02T15:06:24-05:00 > [INFO] Final Memory: 54M/470M > [INFO] > ------------------------------------------------------------------------ > [ERROR] Failed to execute goal > org.apache.felix:maven-bundle-plugin:2.3.7:manifest (bundle-manifest) > on project keycloak-osgi-core-adapter: Cannot find C:\GitHub\keycloak > \distribution\osgi\core-adapter\target\classes (manifest goal must be > run after compile phase) -> [Help 1] > [ERROR] > [ERROR] To see the full stack trace of the errors, re-run Maven with > the -e switch. > [ERROR] Re-run Maven using the -X switch to enable full debug logging. > [ERROR] > [ERROR] For more information about the errors and possible solutions, > please read the following articles: > [ERROR] [Help 1] > http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException > [ERROR] > [ERROR] After correcting the problems, you can resume the build with > the command > [ERROR] mvn <goals> -rf :keycloak-osgi-core-adapter > > On 12/2/2014 3:01 PM, Marek Posolda wrote: >> Maybe an option is to keep just adapter support on AS7, but drop >> support >> for the auth-server itself on AS7? Of course, if we are able to somehow >> fix everything, it might be best option:-) >> >> Marek >> >> On 2.12.2014 20:49, Bill Burke wrote: >>> We should keep as7 adapter support at least. We support older >>> versions of Jetty and tomcat too, it would be strange not to support >>> AS7. Hopefully stan has a fix. >>> >>> Looking at it, it looks like OperationDefinition is only within >>> auth-server subsystem. That could be the "hack' you're talkin about. >>> >>> Shouldn't the auth-server and adapter should be separate subsystems >>> anyways? >>> >>> On 12/2/2014 2:37 PM, Marek Posolda wrote: >>>> One slightly related issue. I just did some testing and figured that >>>> eap6.3 and as7 distribution were broken as they excluded >>>> keycloak-subsystem . I've fixed that and EAP 6.3 works fine now. >>>> But on >>>> AS 7.1.1 the keycloak-subsystem doesn't work and I have: >>>> >>>> Caused by: java.lang.ClassNotFoundException: >>>> org.jboss.as.controller.OperationDefinition from [Module >>>> "org.keycloak.keycloak-subsystem:main" >>>> >>>> I am seeing options like: >>>> 1) Drop AS7 support >>>> 2) Revert AS7 specific subsystem >>>> 3) Do some hack in keycloak-subsystem to have it working on AS >>>> 7.1.1 (is >>>> it doable?) >>>> >>>> Anything else I am missing? >>>> >>>> Marek >>>> >>>> On 2.12.2014 14:38, Bill Burke wrote: >>>>> On 12/2/2014 7:55 AM, Stan Silvert wrote: >>>>>> On 12/2/2014 4:52 AM, Stian Thorgersen wrote: >>>>>>> Should we upgrade to WF 8.2 and also do some changes to the distro >>>>>>> before release? >>>>>> I don't see a reason not to go to WF 8.2. If we do that, let me >>>>>> know so >>>>>> I can run a quick smoke test on the subsystem before we release. >>>>>>> With regards to distro we should move the adapters and examples >>>>>>> into >>>>>>> separate downloads. Also, we should move the examples into a >>>>>>> separate github project (keycloak/keycloak-examples). This will >>>>>>> make >>>>>>> it easier for those that wants to fork the examples separately. >>>>>>> >>>>>>> Also, we should consider a download based on the web-lite profile. >>>>>>> For non-JavaEE apps, containers (Docker) and those that want to >>>>>>> run >>>>>>> a standalone KC server it would be nice to have a small as >>>>>>> possible >>>>>>> distro. >>>>>> Depending on how the feature pack turns out, we might be able to >>>>>> offer >>>>>> many flavors of the appliance distro without any additional >>>>>> effort. We >>>>>> could have: >>>>>> EAP6 + Keycloak >>>>>> AS7 + Keycloak >>>>>> WF8 (web) + Keycloak >>>>>> WF8 (full) + Keycloak >>>>>> WF 9 beta (web) + Keycloak >>>>>> WF 9 beta (full) + Keycloak >>>>>> etc. >>>>>> >>>>> IMO, we just need: >>>>> * war-dist >>>>> * appliance-dist >>>>> >>>>> Appliance distribution would have the most stable platform >>>>> available. >>>>> Since we can't distribute EAP, then it would be the most stable and >>>>> maintained version of Wildfly that allows us to cluster and deploy >>>>> Keycloak. >>>>> >>>>> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >

On 12/2/2014 3:36 PM, Marek Posolda wrote: > oops, thanks to you for reporting issue to me this time:-) > > It should be fixed now. Let me know if it helps. That fixed it. Wish mine was that easy. So much for EAP6 being based on AS7. The API I'm using doesn't exist on AS7. It does exist on EAP6, WF8, and WF9. I think our best course right now is to not use the subsystem on AS7. You can still deploy the auth-server WAR into the /deployments directory if you are dead set on using AS7 that way. This doesn't affect the AS7 adapter at all. We just need to remove the subsystem module from the dist.

On 12/2/2014 4:38 PM, Bill Burke wrote: > > On 12/2/2014 3:55 PM, Stan Silvert wrote: >> On 12/2/2014 3:36 PM, Marek Posolda wrote: >>> oops, thanks to you for reporting issue to me this time:-) >>> >>> It should be fixed now. Let me know if it helps. >> That fixed it. Wish mine was that easy. >> >> So much for EAP6 being based on AS7. The API I'm using doesn't exist on >> AS7. It does exist on EAP6, WF8, and WF9. >> >> I think our best course right now is to not use the subsystem on AS7. >> You can still deploy the auth-server WAR into the /deployments directory >> if you are dead set on using AS7 that way. >> >> This doesn't affect the AS7 adapter at all. We just need to remove the >> subsystem module from the dist. >> > Isn't the adapter subsystem and auth-server subsystem in the same > jar/module? > > http://docs.jboss.org/keycloak/docs/1.0.4.Final/userguide/html/ch07.html#... > What I'm saying is...didn't you just totally break the as7 adapter?

From: "Stan Silvert" <ssilvert(a)redhat.com&gt; To: keycloak-dev(a)lists.jboss.org Sent: Wednesday, 3 December, 2014 3:56:27 AM Subject: Re: [keycloak-dev] AS7 subsystem problems Re: release? Stan? On 12/2/2014 6:18 PM, Stan Silvert wrote: > On 12/2/2014 4:41 PM, Bill Burke wrote: >> On 12/2/2014 4:38 PM, Bill Burke wrote: >>> On 12/2/2014 3:55 PM, Stan Silvert wrote: >>>> On 12/2/2014 3:36 PM, Marek Posolda wrote: >>>>> oops, thanks to you for reporting issue to me this time:-) >>>>> >>>>> It should be fixed now. Let me know if it helps. >>>> That fixed it. Wish mine was that easy. >>>> >>>> So much for EAP6 being based on AS7. The API I'm using doesn't exist on >>>> AS7. It does exist on EAP6, WF8, and WF9. >>>> >>>> I think our best course right now is to not use the subsystem on AS7. >>>> You can still deploy the auth-server WAR into the /deployments directory >>>> if you are dead set on using AS7 that way. >>>> >>>> This doesn't affect the AS7 adapter at all. We just need to remove the >>>> subsystem module from the dist. >>>> >>> Isn't the adapter subsystem and auth-server subsystem in the same >>> jar/module? >>> >>> http://docs.jboss.org/keycloak/docs/1.0.4.Final/userguide/html/ch07.html#... >>> >> What I'm saying is...didn't you just totally break the as7 adapter? >> >> > No, they are not in the same module. But now I do see what you are > saying. The subsystem is adding the adapter module, so yes, it's broken > unless you add the module in jboss-structure.xml. > > Need to think on this some more. So the simplest solution actually is to do what I say above when using AS7. That is, you either package the adapter in your WAR or you reference it in jboss-structure.xml. That would require no further changes. Just merge the PR I sent earlier and I'll change the docs. Is that acceptable? There are some other solutions, but I don't like them as much. Anything else we do will require treating the AS7 subsystem as a special case and I just don't see the ROI. AS7 is (or should be) a dead platform. So what I'm proposing is that we just treat AS7 like Tomcat or Jetty. We still have the AS7 adapter but you don't use the subsystem.

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

From: "Marek Posolda" <mposolda(a)redhat.com&gt; To: "Stian Thorgersen" <stian(a)redhat.com&gt;, "Stan Silvert" <ssilvert(a)redhat.com&gt; Cc: keycloak-dev(a)lists.jboss.org Sent: Wednesday, 3 December, 2014 9:42:36 AM Subject: Re: [keycloak-dev] AS7 subsystem problems Re: release? Stan? On 3.12.2014 08:43, Stian Thorgersen wrote: > > ----- Original Message ----- >> From: "Stan Silvert" <ssilvert(a)redhat.com&gt; >> To: keycloak-dev(a)lists.jboss.org >> Sent: Wednesday, 3 December, 2014 3:56:27 AM >> Subject: Re: [keycloak-dev] AS7 subsystem problems Re: release? Stan? >> >> On 12/2/2014 6:18 PM, Stan Silvert wrote: >>> On 12/2/2014 4:41 PM, Bill Burke wrote: >>>> On 12/2/2014 4:38 PM, Bill Burke wrote: >>>>> On 12/2/2014 3:55 PM, Stan Silvert wrote: >>>>>> On 12/2/2014 3:36 PM, Marek Posolda wrote: >>>>>>> oops, thanks to you for reporting issue to me this time:-) >>>>>>> >>>>>>> It should be fixed now. Let me know if it helps. >>>>>> That fixed it. Wish mine was that easy. >>>>>> >>>>>> So much for EAP6 being based on AS7. The API I'm using doesn't exist >>>>>> on >>>>>> AS7. It does exist on EAP6, WF8, and WF9. >>>>>> >>>>>> I think our best course right now is to not use the subsystem on AS7. >>>>>> You can still deploy the auth-server WAR into the /deployments >>>>>> directory >>>>>> if you are dead set on using AS7 that way. >>>>>> >>>>>> This doesn't affect the AS7 adapter at all. We just need to remove >>>>>> the >>>>>> subsystem module from the dist. >>>>>> >>>>> Isn't the adapter subsystem and auth-server subsystem in the same >>>>> jar/module? >>>>> >>>>> http://docs.jboss.org/keycloak/docs/1.0.4.Final/userguide/html/ch07.html#... >>>>> >>>> What I'm saying is...didn't you just totally break the as7 adapter? >>>> >>>> >>> No, they are not in the same module. But now I do see what you are >>> saying. The subsystem is adding the adapter module, so yes, it's broken >>> unless you add the module in jboss-structure.xml. >>> >>> Need to think on this some more. >> So the simplest solution actually is to do what I say above when using >> AS7. That is, you either package the adapter in your WAR or you >> reference it in jboss-structure.xml. That would require no further >> changes. Just merge the PR I sent earlier and I'll change the docs. >> >> Is that acceptable? There are some other solutions, but I don't like >> them as much. Anything else we do will require treating the AS7 >> subsystem as a special case and I just don't see the ROI. AS7 is (or >> should be) a dead platform. >> >> So what I'm proposing is that we just treat AS7 like Tomcat or Jetty. >> We still have the AS7 adapter but you don't use the subsystem. > IMO that's a decent solution and better than having a separate subsystem > for AS7 (assuming that'd be the only option). How about auth-server support on AS7? From what I understand, if we still want to support it, we would need to add auth-server.war into standalone/deployments like it was before. That would mean that instructions for adding new providers will be different for other platforms than for AS7. Also we already have some additional steps required if people want to have auth-server on AS7: http://docs.jboss.org/keycloak/docs/1.1.0.Beta1/userguide/html/server-ins... . So are we instead going to drop auth-server support on AS7 and keep just adapters support?

Marek > >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > _______________________________________________ > keycloak-dev mailing list > keycloak-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev

On 12/3/2014 2:43 AM, Stian Thorgersen wrote: > > ----- Original Message ----- >> From: "Stan Silvert" <ssilvert(a)redhat.com&gt; >> To: keycloak-dev(a)lists.jboss.org >> Sent: Wednesday, 3 December, 2014 3:56:27 AM >> Subject: Re: [keycloak-dev] AS7 subsystem problems Re: release? Stan? >> >> On 12/2/2014 6:18 PM, Stan Silvert wrote: >>> On 12/2/2014 4:41 PM, Bill Burke wrote: >>>> On 12/2/2014 4:38 PM, Bill Burke wrote: >>>>> On 12/2/2014 3:55 PM, Stan Silvert wrote: >>>>>> On 12/2/2014 3:36 PM, Marek Posolda wrote: >>>>>>> oops, thanks to you for reporting issue to me this time:-) >>>>>>> >>>>>>> It should be fixed now. Let me know if it helps. >>>>>> That fixed it. Wish mine was that easy. >>>>>> >>>>>> So much for EAP6 being based on AS7. The API I'm using doesn't exist on >>>>>> AS7. It does exist on EAP6, WF8, and WF9. >>>>>> >>>>>> I think our best course right now is to not use the subsystem on AS7. >>>>>> You can still deploy the auth-server WAR into the /deployments directory >>>>>> if you are dead set on using AS7 that way. >>>>>> >>>>>> This doesn't affect the AS7 adapter at all. We just need to remove the >>>>>> subsystem module from the dist. >>>>>> >>>>> Isn't the adapter subsystem and auth-server subsystem in the same >>>>> jar/module? >>>>> >>>>> http://docs.jboss.org/keycloak/docs/1.0.4.Final/userguide/html/ch07.html#... >>>>> >>>> What I'm saying is...didn't you just totally break the as7 adapter? >>>> >>>> >>> No, they are not in the same module. But now I do see what you are >>> saying. The subsystem is adding the adapter module, so yes, it's broken >>> unless you add the module in jboss-structure.xml. >>> >>> Need to think on this some more. >> So the simplest solution actually is to do what I say above when using >> AS7. That is, you either package the adapter in your WAR or you >> reference it in jboss-structure.xml. That would require no further >> changes. Just merge the PR I sent earlier and I'll change the docs. >> >> Is that acceptable? There are some other solutions, but I don't like >> them as much. Anything else we do will require treating the AS7 >> subsystem as a special case and I just don't see the ROI. AS7 is (or >> should be) a dead platform. >> >> So what I'm proposing is that we just treat AS7 like Tomcat or Jetty. >> We still have the AS7 adapter but you don't use the subsystem. > IMO that's a decent solution and better than having a separate subsystem for AS7 (assuming that'd be the only option). > -20...The subsystem allows you to have specify KEYCLOAK as the <auth-method>, as well as to override a WAR's security settings in standalone.xml. Without a subsystem you have to specify a jboss-web.xml and a valve. We need to be as consistent as possible. If you're not going to fix it, let me know and I'll do it.

On 12/3/2014 2:43 AM, Stian Thorgersen wrote: > > ----- Original Message ----- >> From: "Stan Silvert" <ssilvert(a)redhat.com&gt; >> To: keycloak-dev(a)lists.jboss.org >> Sent: Wednesday, 3 December, 2014 3:56:27 AM >> Subject: Re: [keycloak-dev] AS7 subsystem problems Re: release? Stan? >> >> On 12/2/2014 6:18 PM, Stan Silvert wrote: >>> On 12/2/2014 4:41 PM, Bill Burke wrote: >>>> On 12/2/2014 4:38 PM, Bill Burke wrote: >>>>> On 12/2/2014 3:55 PM, Stan Silvert wrote: >>>>>> On 12/2/2014 3:36 PM, Marek Posolda wrote: >>>>>>> oops, thanks to you for reporting issue to me this time:-) >>>>>>> >>>>>>> It should be fixed now. Let me know if it helps. >>>>>> That fixed it. Wish mine was that easy. >>>>>> >>>>>> So much for EAP6 being based on AS7. The API I'm using doesn't exist on >>>>>> AS7. It does exist on EAP6, WF8, and WF9. >>>>>> >>>>>> I think our best course right now is to not use the subsystem on AS7. >>>>>> You can still deploy the auth-server WAR into the /deployments directory >>>>>> if you are dead set on using AS7 that way. >>>>>> >>>>>> This doesn't affect the AS7 adapter at all. We just need to remove the >>>>>> subsystem module from the dist. >>>>>> >>>>> Isn't the adapter subsystem and auth-server subsystem in the same >>>>> jar/module? >>>>> >>>>> http://docs.jboss.org/keycloak/docs/1.0.4.Final/userguide/html/ch07.html#... >>>>> >>>> What I'm saying is...didn't you just totally break the as7 adapter? >>>> >>>> >>> No, they are not in the same module. But now I do see what you are >>> saying. The subsystem is adding the adapter module, so yes, it's broken >>> unless you add the module in jboss-structure.xml. >>> >>> Need to think on this some more. >> So the simplest solution actually is to do what I say above when using >> AS7. That is, you either package the adapter in your WAR or you >> reference it in jboss-structure.xml. That would require no further >> changes. Just merge the PR I sent earlier and I'll change the docs. >> >> Is that acceptable? There are some other solutions, but I don't like >> them as much. Anything else we do will require treating the AS7 >> subsystem as a special case and I just don't see the ROI. AS7 is (or >> should be) a dead platform. >> >> So what I'm proposing is that we just treat AS7 like Tomcat or Jetty. >> We still have the AS7 adapter but you don't use the subsystem. > IMO that's a decent solution and better than having a separate subsystem for AS7 (assuming that'd be the only option). > -20...The subsystem allows you to have specify KEYCLOAK as the <auth-method>, as well as to override a WAR's security settings in standalone.xml. Without a subsystem you have to specify a jboss-web.xml and a valve. We need to be as consistent as possible. If you're not going to fix it, let me know and I'll do it.

On 12/3/2014 12:30 PM, Stan Silvert wrote: > 1) Bring back the old code for the AS7 subsystem. Bring it back. If you don't, let me know and I'll do it.

----- Original Message ----- > From: "Bill Burke" <bburke(a)redhat.com&gt; > To: keycloak-dev(a)lists.jboss.org > Sent: Wednesday, 3 December, 2014 8:23:55 PM > Subject: Re: [keycloak-dev] AS7 subsystem problems Re: release? Stan? > > > > On 12/3/2014 12:30 PM, Stan Silvert wrote: >> 1) Bring back the old code for the AS7 subsystem. > Bring it back. If you don't, let me know and I'll do it. Why? I don't get why we keep trying to get AS7 to work. We've already wasted a fair bit of time on this.

> > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > _______________________________________________ > keycloak-dev mailing list > keycloak-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev

----- Original Message ----- > From: "Stan Silvert" <ssilvert(a)redhat.com&gt; > To: keycloak-dev(a)lists.jboss.org > Sent: Thursday, 4 December, 2014 1:27:11 PM > Subject: Re: [keycloak-dev] AS7 subsystem problems Re: release? Stan? > > On 12/4/2014 2:54 AM, Stian Thorgersen wrote: >> ----- Original Message ----- >>> From: "Bill Burke" <bburke(a)redhat.com&gt; >>> To: keycloak-dev(a)lists.jboss.org >>> Sent: Wednesday, 3 December, 2014 8:23:55 PM >>> Subject: Re: [keycloak-dev] AS7 subsystem problems Re: release? Stan? >>> >>> >>> >>> On 12/3/2014 12:30 PM, Stan Silvert wrote: >>>> 1) Bring back the old code for the AS7 subsystem. >>> Bring it back. If you don't, let me know and I'll do it. >> Why? I don't get why we keep trying to get AS7 to work. We've already >> wasted a fair bit of time on this. > To me, it's not really a matter of getting it to work. I've restored > the old code and I just need to test everything out today. There is no > reason to think it won't work as before. > > The only question in my mind is whether or not anyone will want to use > it. I guess there is not that much incremental cost in maintaining the > old code. As I understand it, Bill's overriding strategy is to support > every platform possible. > > I've already changed course on this a couple of times, so I'd like to > just finish and move on. Sure, I just want a reason to continue supporting AS7 though as it does come back to haunt us every once in a while. JPA issues, web-services issues, sub-system issues, etc.. By now we've probably spent a few days at least this year on an outdated platform.

>>> -- >>> Bill Burke >>> JBoss, a division of Red Hat >>> http://bill.burkecentral.com >>> _______________________________________________ >>> keycloak-dev mailing list >>> keycloak-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > _______________________________________________ > keycloak-dev mailing list > keycloak-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev >

----- Original Message ----- > From: "Stan Silvert" <ssilvert(a)redhat.com&gt; > To: "Stian Thorgersen" <stian(a)redhat.com&gt; > Cc: keycloak-dev(a)lists.jboss.org > Sent: Thursday, 4 December, 2014 1:39:09 PM > Subject: Re: [keycloak-dev] AS7 subsystem problems Re: release? Stan? > > On 12/4/2014 7:32 AM, Stian Thorgersen wrote: >> ----- Original Message ----- >>> From: "Stan Silvert" <ssilvert(a)redhat.com&gt; >>> To: keycloak-dev(a)lists.jboss.org >>> Sent: Thursday, 4 December, 2014 1:27:11 PM >>> Subject: Re: [keycloak-dev] AS7 subsystem problems Re: release? Stan? >>> >>> On 12/4/2014 2:54 AM, Stian Thorgersen wrote: >>>> ----- Original Message ----- >>>>> From: "Bill Burke" <bburke(a)redhat.com&gt; >>>>> To: keycloak-dev(a)lists.jboss.org >>>>> Sent: Wednesday, 3 December, 2014 8:23:55 PM >>>>> Subject: Re: [keycloak-dev] AS7 subsystem problems Re: release? Stan? >>>>> >>>>> >>>>> >>>>> On 12/3/2014 12:30 PM, Stan Silvert wrote: >>>>>> 1) Bring back the old code for the AS7 subsystem. >>>>> Bring it back. If you don't, let me know and I'll do it. >>>> Why? I don't get why we keep trying to get AS7 to work. We've already >>>> wasted a fair bit of time on this. >>> To me, it's not really a matter of getting it to work. I've restored >>> the old code and I just need to test everything out today. There is no >>> reason to think it won't work as before. >>> >>> The only question in my mind is whether or not anyone will want to use >>> it. I guess there is not that much incremental cost in maintaining the >>> old code. As I understand it, Bill's overriding strategy is to support >>> every platform possible. >>> >>> I've already changed course on this a couple of times, so I'd like to >>> just finish and move on. >> Sure, I just want a reason to continue supporting AS7 though as it does >> come back to haunt us every once in a while. >> >> JPA issues, web-services issues, sub-system issues, etc.. By now we've >> probably spent a few days at least this year on an outdated platform. > Perhaps dropping auth server support will help with that? What I'm > doing now only affects AS7 client apps. Yes, IMO we should definitively drop auth server support on AS7. With regards to client support, IMO we should drop support for AS7 completely, but at very least the subsystem and just require including the adapter in the WAR like we do for Tomcat, Jetty, etc...

>>>>> -- >>>>> Bill Burke >>>>> JBoss, a division of Red Hat >>>>> http://bill.burkecentral.com >>>>> _______________________________________________ >>>>> keycloak-dev mailing list >>>>> keycloak-dev(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>>> >>>> _______________________________________________ >>>> keycloak-dev mailing list >>>> keycloak-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> _______________________________________________ >>> keycloak-dev mailing list >>> keycloak-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> > _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev

----- Original Message ----- > From: "Stan Silvert" <ssilvert(a)redhat.com&gt; > To: keycloak-dev(a)lists.jboss.org > Sent: Thursday, 4 December, 2014 1:27:11 PM > Subject: Re: [keycloak-dev] AS7 subsystem problems Re: release? Stan? > > On 12/4/2014 2:54 AM, Stian Thorgersen wrote: >> >> ----- Original Message ----- >>> From: "Bill Burke" <bburke(a)redhat.com&gt; >>> To: keycloak-dev(a)lists.jboss.org >>> Sent: Wednesday, 3 December, 2014 8:23:55 PM >>> Subject: Re: [keycloak-dev] AS7 subsystem problems Re: release? Stan? >>> >>> >>> >>> On 12/3/2014 12:30 PM, Stan Silvert wrote: >>>> 1) Bring back the old code for the AS7 subsystem. >>> Bring it back. If you don't, let me know and I'll do it. >> Why? I don't get why we keep trying to get AS7 to work. We've already >> wasted a fair bit of time on this. > To me, it's not really a matter of getting it to work. I've restored > the old code and I just need to test everything out today. There is no > reason to think it won't work as before. > > The only question in my mind is whether or not anyone will want to use > it. I guess there is not that much incremental cost in maintaining the > old code. As I understand it, Bill's overriding strategy is to support > every platform possible. > > I've already changed course on this a couple of times, so I'd like to > just finish and move on. Sure, I just want a reason to continue supporting AS7 though as it does come back to haunt us every once in a while. JPA issues, web-services issues, sub-system issues, etc.. By now we've probably spent a few days at least this year on an outdated platform.

We should keep as7 adapter support at least. We support older versions of Jetty and tomcat too, it would be strange not to support AS7. Hopefully stan has a fix. Looking at it, it looks like OperationDefinition is only within auth-server subsystem. That could be the "hack' you're talkin about. Shouldn't the auth-server and adapter should be separate subsystems anyways?

On 12/2/2014 2:37 PM, Marek Posolda wrote: > One slightly related issue. I just did some testing and figured that > eap6.3 and as7 distribution were broken as they excluded > keycloak-subsystem . I've fixed that and EAP 6.3 works fine now. But on > AS 7.1.1 the keycloak-subsystem doesn't work and I have: > > Caused by: java.lang.ClassNotFoundException: > org.jboss.as.controller.OperationDefinition from [Module > "org.keycloak.keycloak-subsystem:main" > > I am seeing options like: > 1) Drop AS7 support > 2) Revert AS7 specific subsystem > 3) Do some hack in keycloak-subsystem to have it working on AS 7.1.1 (is > it doable?) > > Anything else I am missing? > > Marek > > On 2.12.2014 14:38, Bill Burke wrote: >> On 12/2/2014 7:55 AM, Stan Silvert wrote: >>> On 12/2/2014 4:52 AM, Stian Thorgersen wrote: >>>> Should we upgrade to WF 8.2 and also do some changes to the distro >>>> before release? >>> I don't see a reason not to go to WF 8.2. If we do that, let me know so >>> I can run a quick smoke test on the subsystem before we release. >>>> With regards to distro we should move the adapters and examples into >>>> separate downloads. Also, we should move the examples into a >>>> separate github project (keycloak/keycloak-examples). This will make >>>> it easier for those that wants to fork the examples separately. >>>> >>>> Also, we should consider a download based on the web-lite profile. >>>> For non-JavaEE apps, containers (Docker) and those that want to run >>>> a standalone KC server it would be nice to have a small as possible >>>> distro. >>> Depending on how the feature pack turns out, we might be able to offer >>> many flavors of the appliance distro without any additional effort. We >>> could have: >>> EAP6 + Keycloak >>> AS7 + Keycloak >>> WF8 (web) + Keycloak >>> WF8 (full) + Keycloak >>> WF 9 beta (web) + Keycloak >>> WF 9 beta (full) + Keycloak >>> etc. >>> >> IMO, we just need: >> * war-dist >> * appliance-dist >> >> Appliance distribution would have the most stable platform available. >> Since we can't distribute EAP, then it would be the most stable and >> maintained version of Wildfly that allows us to cluster and deploy >> Keycloak. >> >>