From mazz at redhat.com Sun Aug 2 21:01:31 2015 From: mazz at redhat.com (John Mazzitelli) Date: Sun, 2 Aug 2015 21:01:31 -0400 (EDT) Subject: [Hawkular-dev] hawkular-accounts integration with websocket stuff in kettle In-Reply-To: <1744200071.2495080.1438563151160.JavaMail.zimbra@redhat.com> Message-ID: <279801412.2495350.1438563691349.JavaMail.zimbra@redhat.com> Juca, I think the time is coming close when I need to wrap authentication around the websockets stuff we have in the server. Right now, any client can connect to our websocket server running in kettle. I know you mentioned that KeyCloak doesn't have an official integration with websockets today, but can we make calls to your accounts API directly to do things like logging in? In our websockets code, I believe we can get access to the headers that were passed in by the UI client when connecting to websockets (javax.websocket.Session.getRequestParameterMap() is what I assume we can use). So a UI or feed could pass in username/password (just like a normal HTTP client would to connect to our metrics or inventory REST API). We would just need to manually take those username/password credentials and ask accounts to verify the credentials and perhaps give us back a UserPrincipal or whatever it is you can give us. We will eventually need to use this user principal or whatever to logically link that UI client (and the requests it makes to the server) to the responses of those requests (so those responses can be sent back to the proper client) Ideas? --John Mazz From theute at redhat.com Mon Aug 3 06:45:19 2015 From: theute at redhat.com (Thomas Heute) Date: Mon, 3 Aug 2015 12:45:19 +0200 Subject: [Hawkular-dev] Hawkular ruby client In-Reply-To: References: Message-ID: <55BF463F.3050105@redhat.com> That's great ! Blog entry with an example is coming I assume ? ;) ;) ;) Thomas On 07/30/2015 02:11 PM, Libor Zoubek wrote: > Hello, > > I'd like to announce hawkular client written in ruby. It can only talk to Hakwular Metrics at this point, but covers almost whole API (almost = I might have missed something). Feel free to try it out. > > github: https://github.com/hawkular/hawkular-client-ruby > documentation: http://www.hawkular.org/hawkular-client-ruby/ > > Cheers, > From ppalaga at redhat.com Mon Aug 3 08:56:40 2015 From: ppalaga at redhat.com (Peter Palaga) Date: Mon, 3 Aug 2015 14:56:40 +0200 Subject: [Hawkular-dev] Import order In-Reply-To: <55811D89.8080507@redhat.com> References: <557FF158.2000708@redhat.com> <557FF716.3080100@redhat.com> <55811D89.8080507@redhat.com> Message-ID: <55BF6508.9050209@redhat.com> Status update: There is a PR [1] open in build tools to introduce the Import order Checkstyle rule with the next version of HK Parent. Please protest loudly if you disagree. I have sent PRs fixing the import order to some components repos: Hawkular: https://github.com/hawkular/hawkular/pull/384 Alerts: https://github.com/hawkular/hawkular-alerts/pull/79 Metrics: https://github.com/hawkular/hawkular-metrics/pull/296 Inventory: https://github.com/hawkular/hawkular-inventory/pull/135 While ordering the imports using Eclipse in the above projects, I have found only one subtle mismatch between Eclipse and checkstyle: Here https://github.com/hawkular/hawkular-metrics/blob/2062a0a63e3d4a9eb22f77a79e082324d3b166a1/core/metrics-core-api/src/test/java/org/hawkular/metrics/core/api/IntervalTest.java#L19-L22 Eclipse wants import static org.hawkular.metrics.core.api.Interval.parse; import static org.hawkular.metrics.core.api.Interval.Units.DAYS; import static org.hawkular.metrics.core.api.Interval.Units.HOURS; import static org.hawkular.metrics.core.api.Interval.Units.MINUTES; While Checkstyle wants import static org.hawkular.metrics.core.api.Interval.Units.DAYS; import static org.hawkular.metrics.core.api.Interval.Units.HOURS; import static org.hawkular.metrics.core.api.Interval.Units.MINUTES; import static org.hawkular.metrics.core.api.Interval.parse; There was just one occurrence of this problem and I hope that we can neglect it. Thanks, Peter [1] https://github.com/hawkular/hawkular-build-tools/pull/21 On 2015-06-17 09:11, Peter Palaga wrote: > OK, I'll add the import order check to checkstyle. > https://issues.jboss.org/browse/HAWKULAR-358 -- P > > On 16/06/15 12:14, Thomas Segismont wrote: >> Le 16/06/2015 11:50, Peter Palaga a ?crit : >>> Hi Mazz, >>> >>> While I can remember some basic discussion about the order Java imports, >>> I do not remember at all what was the result. >>> >>> I saw that you added Eclipse prefs for import order to dev tools which >>> is definitely good >>> https://github.com/hawkular/hawkular-build-tools/blob/master/ide-configs/eclipse/hawkular-eclipse-preferences-java-codestyle-organizeimports.importorder >>> >>> Do Idea prefs contain the same settings? >> >> Yes, they were built by Lucas and reviewed by me. >> >>> >>> Are there projects using these settings consequently? >> >> All projects _should_ be using the same. >> >>> >>> But did we say we would enforce the imports order by checkstyle? >> >> We didn't talk about that. >> >> I have recently commented on GitHub that import order was the only thing >> not checked yet, and we keep on seeing PR with many lines of import >> order differences. >> >> To me, it shows that formatting rules, if not enforced, are not >> naturally observed. >> >>> They have a rule for that: >>> http://checkstyle.sourceforge.net/config_imports.html#ImportOrder >> >> +1 for adding >> >>> >>> Its a pity that we have not done it earlier. >>> >>> Thanks, >>> >>> Peter >>> _______________________________________________ >>> hawkular-dev mailing list >>> hawkular-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/hawkular-dev >>> >> >> _______________________________________________ >> hawkular-dev mailing list >> hawkular-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hawkular-dev >> > > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > From jsanda at redhat.com Mon Aug 3 10:15:08 2015 From: jsanda at redhat.com (John Sanda) Date: Mon, 3 Aug 2015 10:15:08 -0400 Subject: [Hawkular-dev] JAX-RS endpoint for testing only Message-ID: I want to implement an endpoint that is deployed only for tests. If I could programmatically create JAX-RS resources, this this would be easy; however, I do not think it is supported. Does anyone have any recommendations on how to do this? - John From jpkroehling at redhat.com Mon Aug 3 10:34:04 2015 From: jpkroehling at redhat.com (=?UTF-8?Q?Juraci_Paix=c3=a3o_Kr=c3=b6hling?=) Date: Mon, 3 Aug 2015 16:34:04 +0200 Subject: [Hawkular-dev] hawkular-accounts integration with websocket stuff in kettle In-Reply-To: <279801412.2495350.1438563691349.JavaMail.zimbra@redhat.com> References: <279801412.2495350.1438563691349.JavaMail.zimbra@redhat.com> Message-ID: <55BF7BDC.4020409@redhat.com> Mazz, On 08/03/2015 03:01 AM, John Mazzitelli wrote: > I think the time is coming close when I need to wrap authentication around the websockets stuff we have in the server. Right now, any client can connect to our websocket server running in kettle. I know you mentioned that KeyCloak doesn't have an official integration with websockets today, but can we make calls to your accounts API directly to do things like logging in? I'm afraid my knowledge of WebSockets might be outdated with regards to authentication. I'm quite sure there's no specific WebSocket support on Keycloak, but we might be able to leverage JAAS integration on that. In any case, I'll run some tests and come up with some options, so that we can start a discussion. - Juca. From jsanda at redhat.com Mon Aug 3 16:21:05 2015 From: jsanda at redhat.com (John Sanda) Date: Mon, 3 Aug 2015 16:21:05 -0400 Subject: [Hawkular-dev] JAX-RS endpoint for testing only In-Reply-To: References: Message-ID: <019E7CDF-D967-4B94-A175-2EC085199FDE@redhat.com> Overriding javax.ws.rs .core.Application.getClasses() will do what I want. It would be nice/easier though if there was a way to instead specify those resources/providers I want to exclude. > On Aug 3, 2015, at 10:15 AM, John Sanda wrote: > > I want to implement an endpoint that is deployed only for tests. If I could programmatically create JAX-RS resources, this this would be easy; however, I do not think it is supported. Does anyone have any recommendations on how to do this? > > - John > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20150803/98e4e9f1/attachment.html From ppalaga at redhat.com Tue Aug 4 02:53:24 2015 From: ppalaga at redhat.com (Peter Palaga) Date: Tue, 4 Aug 2015 08:53:24 +0200 Subject: [Hawkular-dev] Import order In-Reply-To: <55BF6508.9050209@redhat.com> References: <557FF158.2000708@redhat.com> <557FF716.3080100@redhat.com> <55811D89.8080507@redhat.com> <55BF6508.9050209@redhat.com> Message-ID: <55C06164.4070207@redhat.com> Ordering of imports seems to be broken in some way in Idea: https://youtrack.jetbrains.com/issue/IDEA-142468 Idea users, could you please come up with a proposal, what to do in this situation? Not introducing the Checkstyle rule will probably lead to gradual eroding of imports in all classes, also in those which are sorted properly ATM. That would be a pity. Idea users, you are not ready to sort imports manually, I guess? What else can be done? - Downgrade? Upvote the Idea bug? Thanks, Peter On 2015-08-03 14:56, Peter Palaga wrote: > Status update: There is a PR [1] open in build tools to introduce the > Import order Checkstyle rule with the next version of HK Parent. > > Please protest loudly if you disagree. > > I have sent PRs fixing the import order to some components repos: > Hawkular: https://github.com/hawkular/hawkular/pull/384 > Alerts: https://github.com/hawkular/hawkular-alerts/pull/79 > Metrics: https://github.com/hawkular/hawkular-metrics/pull/296 > Inventory: https://github.com/hawkular/hawkular-inventory/pull/135 > > While ordering the imports using Eclipse in the above projects, I have > found only one subtle mismatch between Eclipse and checkstyle: Here > https://github.com/hawkular/hawkular-metrics/blob/2062a0a63e3d4a9eb22f77a79e082324d3b166a1/core/metrics-core-api/src/test/java/org/hawkular/metrics/core/api/IntervalTest.java#L19-L22 > > Eclipse wants > > import static org.hawkular.metrics.core.api.Interval.parse; > import static org.hawkular.metrics.core.api.Interval.Units.DAYS; > import static org.hawkular.metrics.core.api.Interval.Units.HOURS; > import static org.hawkular.metrics.core.api.Interval.Units.MINUTES; > > While Checkstyle wants > > import static org.hawkular.metrics.core.api.Interval.Units.DAYS; > import static org.hawkular.metrics.core.api.Interval.Units.HOURS; > import static org.hawkular.metrics.core.api.Interval.Units.MINUTES; > import static org.hawkular.metrics.core.api.Interval.parse; > > There was just one occurrence of this problem and I hope that we can > neglect it. > > Thanks, > > Peter > > [1] https://github.com/hawkular/hawkular-build-tools/pull/21 > > On 2015-06-17 09:11, Peter Palaga wrote: >> OK, I'll add the import order check to checkstyle. >> https://issues.jboss.org/browse/HAWKULAR-358 -- P >> >> On 16/06/15 12:14, Thomas Segismont wrote: >>> Le 16/06/2015 11:50, Peter Palaga a ?crit : >>>> Hi Mazz, >>>> >>>> While I can remember some basic discussion about the order Java imports, >>>> I do not remember at all what was the result. >>>> >>>> I saw that you added Eclipse prefs for import order to dev tools which >>>> is definitely good >>>> https://github.com/hawkular/hawkular-build-tools/blob/master/ide-configs/eclipse/hawkular-eclipse-preferences-java-codestyle-organizeimports.importorder >>>> >>>> Do Idea prefs contain the same settings? >>> >>> Yes, they were built by Lucas and reviewed by me. >>> >>>> >>>> Are there projects using these settings consequently? >>> >>> All projects _should_ be using the same. >>> >>>> >>>> But did we say we would enforce the imports order by checkstyle? >>> >>> We didn't talk about that. >>> >>> I have recently commented on GitHub that import order was the only thing >>> not checked yet, and we keep on seeing PR with many lines of import >>> order differences. >>> >>> To me, it shows that formatting rules, if not enforced, are not >>> naturally observed. >>> >>>> They have a rule for that: >>>> http://checkstyle.sourceforge.net/config_imports.html#ImportOrder >>> >>> +1 for adding >>> >>>> >>>> Its a pity that we have not done it earlier. >>>> >>>> Thanks, >>>> >>>> Peter >>>> _______________________________________________ >>>> hawkular-dev mailing list >>>> hawkular-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/hawkular-dev >>>> >>> >>> _______________________________________________ >>> hawkular-dev mailing list >>> hawkular-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/hawkular-dev >>> >> >> _______________________________________________ >> hawkular-dev mailing list >> hawkular-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hawkular-dev >> > > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > From hrupp at redhat.com Tue Aug 4 09:53:15 2015 From: hrupp at redhat.com (Heiko W.Rupp) Date: Tue, 04 Aug 2015 15:53:15 +0200 Subject: [Hawkular-dev] Draft of a Hawkular mission statement - please comment Message-ID: Hey, I have written a draft of a Hawkular mission statement that outlines what we want to achieve with Hawkular and where we want to go and be in the future. When the document is finalized, it can serve as a 1st stop for people that want to learn about Hawkular and also as a reminder to ourselves. See https://github.com/hawkular/hawkular.github.io/pull/73/files or https://github.com/pilhuhn/hawkular.github.io/blob/mission/src/main/jbake/content/docs/what.adoc for a rendered version. The first link, the pull-request, allows you to comment on this, which I want you to do. Heiko From jkremser at redhat.com Tue Aug 4 10:38:46 2015 From: jkremser at redhat.com (Jiri Kremser) Date: Tue, 4 Aug 2015 10:38:46 -0400 (EDT) Subject: [Hawkular-dev] Import order In-Reply-To: <55C06164.4070207@redhat.com> References: <557FF158.2000708@redhat.com> <557FF716.3080100@redhat.com> <55811D89.8080507@redhat.com> <55BF6508.9050209@redhat.com> <55C06164.4070207@redhat.com> Message-ID: <1967232073.2320793.1438699126887.JavaMail.zimbra@redhat.com> Hi, I believe, I've fixed it for the idea here [1] [1]: https://github.com/hawkular/hawkular-build-tools/pull/22 The PR contains also a change that expands the settings.jar into normal files so that we can keep track of the changes in git (and build them back into settings.jar). The little drawback is that you can't simply go and download the jar.. it could be done by some travis magic (which can push the jar into other branch after every build via github api). I'll leave this part on somebody else :] cheers, jk ----- Original Message ----- | From: "Peter Palaga" | To: hawkular-dev at lists.jboss.org | Sent: Tuesday, 4 August, 2015 8:53:24 AM | Subject: Re: [Hawkular-dev] Import order | | Ordering of imports seems to be broken in some way in Idea: | https://youtrack.jetbrains.com/issue/IDEA-142468 | | Idea users, could you please come up with a proposal, what to do in this | situation? | | Not introducing the Checkstyle rule will probably lead to gradual | eroding of imports in all classes, also in those which are sorted | properly ATM. That would be a pity. | | Idea users, you are not ready to sort imports manually, I guess? | | What else can be done? - Downgrade? Upvote the Idea bug? | | Thanks, | | Peter | | On 2015-08-03 14:56, Peter Palaga wrote: | > Status update: There is a PR [1] open in build tools to introduce the | > Import order Checkstyle rule with the next version of HK Parent. | > | > Please protest loudly if you disagree. | > | > I have sent PRs fixing the import order to some components repos: | > Hawkular: https://github.com/hawkular/hawkular/pull/384 | > Alerts: https://github.com/hawkular/hawkular-alerts/pull/79 | > Metrics: https://github.com/hawkular/hawkular-metrics/pull/296 | > Inventory: https://github.com/hawkular/hawkular-inventory/pull/135 | > | > While ordering the imports using Eclipse in the above projects, I have | > found only one subtle mismatch between Eclipse and checkstyle: Here | > https://github.com/hawkular/hawkular-metrics/blob/2062a0a63e3d4a9eb22f77a79e082324d3b166a1/core/metrics-core-api/src/test/java/org/hawkular/metrics/core/api/IntervalTest.java#L19-L22 | > | > Eclipse wants | > | > import static org.hawkular.metrics.core.api.Interval.parse; | > import static org.hawkular.metrics.core.api.Interval.Units.DAYS; | > import static org.hawkular.metrics.core.api.Interval.Units.HOURS; | > import static org.hawkular.metrics.core.api.Interval.Units.MINUTES; | > | > While Checkstyle wants | > | > import static org.hawkular.metrics.core.api.Interval.Units.DAYS; | > import static org.hawkular.metrics.core.api.Interval.Units.HOURS; | > import static org.hawkular.metrics.core.api.Interval.Units.MINUTES; | > import static org.hawkular.metrics.core.api.Interval.parse; | > | > There was just one occurrence of this problem and I hope that we can | > neglect it. | > | > Thanks, | > | > Peter | > | > [1] https://github.com/hawkular/hawkular-build-tools/pull/21 | > | > On 2015-06-17 09:11, Peter Palaga wrote: | >> OK, I'll add the import order check to checkstyle. | >> https://issues.jboss.org/browse/HAWKULAR-358 -- P | >> | >> On 16/06/15 12:14, Thomas Segismont wrote: | >>> Le 16/06/2015 11:50, Peter Palaga a ?crit : | >>>> Hi Mazz, | >>>> | >>>> While I can remember some basic discussion about the order Java imports, | >>>> I do not remember at all what was the result. | >>>> | >>>> I saw that you added Eclipse prefs for import order to dev tools which | >>>> is definitely good | >>>> https://github.com/hawkular/hawkular-build-tools/blob/master/ide-configs/eclipse/hawkular-eclipse-preferences-java-codestyle-organizeimports.importorder | >>>> | >>>> Do Idea prefs contain the same settings? | >>> | >>> Yes, they were built by Lucas and reviewed by me. | >>> | >>>> | >>>> Are there projects using these settings consequently? | >>> | >>> All projects _should_ be using the same. | >>> | >>>> | >>>> But did we say we would enforce the imports order by checkstyle? | >>> | >>> We didn't talk about that. | >>> | >>> I have recently commented on GitHub that import order was the only thing | >>> not checked yet, and we keep on seeing PR with many lines of import | >>> order differences. | >>> | >>> To me, it shows that formatting rules, if not enforced, are not | >>> naturally observed. | >>> | >>>> They have a rule for that: | >>>> http://checkstyle.sourceforge.net/config_imports.html#ImportOrder | >>> | >>> +1 for adding | >>> | >>>> | >>>> Its a pity that we have not done it earlier. | >>>> | >>>> Thanks, | >>>> | >>>> Peter | >>>> _______________________________________________ | >>>> hawkular-dev mailing list | >>>> hawkular-dev at lists.jboss.org | >>>> https://lists.jboss.org/mailman/listinfo/hawkular-dev | >>>> | >>> | >>> _______________________________________________ | >>> hawkular-dev mailing list | >>> hawkular-dev at lists.jboss.org | >>> https://lists.jboss.org/mailman/listinfo/hawkular-dev | >>> | >> | >> _______________________________________________ | >> hawkular-dev mailing list | >> hawkular-dev at lists.jboss.org | >> https://lists.jboss.org/mailman/listinfo/hawkular-dev | >> | > | > _______________________________________________ | > hawkular-dev mailing list | > hawkular-dev at lists.jboss.org | > https://lists.jboss.org/mailman/listinfo/hawkular-dev | > | | _______________________________________________ | hawkular-dev mailing list | hawkular-dev at lists.jboss.org | https://lists.jboss.org/mailman/listinfo/hawkular-dev | From gcardoso at redhat.com Tue Aug 4 11:55:46 2015 From: gcardoso at redhat.com (Gabriel Cardoso) Date: Tue, 4 Aug 2015 12:55:46 -0300 Subject: [Hawkular-dev] Draft of a Hawkular mission statement - please comment In-Reply-To: References: Message-ID: Nice draft Heiko! One thing that caught my attention was the word ?enjoyable?. That seems more an attribute for a social services than a management console. Maybe ?effective? would fit better for our project. Or do you see it differently? Thanks, Gabriel > On Aug 4, 2015, at 10:53 AM, Heiko W.Rupp wrote: > > Hey, > > I have written a draft of a Hawkular mission statement that outlines > what we > want to achieve with Hawkular and where we want to go and be in the > future. > When the document is finalized, it can serve as a 1st stop for people > that want > to learn about Hawkular and also as a reminder to ourselves. > > See https://github.com/hawkular/hawkular.github.io/pull/73/files > or > https://github.com/pilhuhn/hawkular.github.io/blob/mission/src/main/jbake/content/docs/what.adoc > for a rendered version. > > The first link, the pull-request, allows you to comment on this, which I > want > you to do. > > > Heiko > > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev Gabriel Cardoso UX designer @ Red Hat From jkremser at redhat.com Wed Aug 5 06:44:48 2015 From: jkremser at redhat.com (Jiri Kremser) Date: Wed, 5 Aug 2015 06:44:48 -0400 (EDT) Subject: [Hawkular-dev] travis secure entries in the travis.yml In-Reply-To: <1394608704.2722751.1438771212660.JavaMail.zimbra@redhat.com> Message-ID: <1306446522.2723979.1438771488212.JavaMail.zimbra@redhat.com> Hello, as you probably know travis allows to encrypt a secret in the travis.yml. I am not going to question how super secret it is, but could we please add a comment on those lines to know what env property it encodes? Now, it's almost impossible to find out which line is safe to delete in here: http://git.io/vO6Lz I believe there are some unused lines. jk From jpkroehling at redhat.com Wed Aug 5 11:10:57 2015 From: jpkroehling at redhat.com (=?UTF-8?Q?Juraci_Paix=c3=a3o_Kr=c3=b6hling?=) Date: Wed, 5 Aug 2015 17:10:57 +0200 Subject: [Hawkular-dev] Import order In-Reply-To: <1967232073.2320793.1438699126887.JavaMail.zimbra@redhat.com> References: <557FF158.2000708@redhat.com> <557FF716.3080100@redhat.com> <55811D89.8080507@redhat.com> <55BF6508.9050209@redhat.com> <55C06164.4070207@redhat.com> <1967232073.2320793.1438699126887.JavaMail.zimbra@redhat.com> Message-ID: <55C22781.9040708@redhat.com> For IntelliJ users out there: while testing this PR, I got into an interesting problem, in that IntelliJ seems to "forget" the settings.jar that was imported. If you get checkstyle errors even after using IntelliJ to "Organize Imports", you might want to check if you still have the settings.jar imported. The easiest way is to create a new class and see if the license headers are there. If they are not there, then: - Import the settings.jar - IntelliJ asks you to restart, which you comply - Once IntelliJ starts again, close it and start it again (manually) - Import the settings.jar again - It should be fixed (test by creating a new file/class). - Juca. On 08/04/2015 04:38 PM, Jiri Kremser wrote: > Hi, > I believe, I've fixed it for the idea here [1] > > [1]: https://github.com/hawkular/hawkular-build-tools/pull/22 > > The PR contains also a change that expands the settings.jar into normal files so that we can keep track of the changes in git (and build them back into settings.jar). > > The little drawback is that you can't simply go and download the jar.. it could be done by some travis magic (which can push the jar into other branch after every build via github api). I'll leave this part on somebody else :] > > cheers, > jk > > > ----- Original Message ----- > | From: "Peter Palaga" > | To: hawkular-dev at lists.jboss.org > | Sent: Tuesday, 4 August, 2015 8:53:24 AM > | Subject: Re: [Hawkular-dev] Import order > | > | Ordering of imports seems to be broken in some way in Idea: > | https://youtrack.jetbrains.com/issue/IDEA-142468 > | > | Idea users, could you please come up with a proposal, what to do in this > | situation? > | > | Not introducing the Checkstyle rule will probably lead to gradual > | eroding of imports in all classes, also in those which are sorted > | properly ATM. That would be a pity. > | > | Idea users, you are not ready to sort imports manually, I guess? > | > | What else can be done? - Downgrade? Upvote the Idea bug? > | > | Thanks, > | > | Peter > | > | On 2015-08-03 14:56, Peter Palaga wrote: > | > Status update: There is a PR [1] open in build tools to introduce the > | > Import order Checkstyle rule with the next version of HK Parent. > | > > | > Please protest loudly if you disagree. > | > > | > I have sent PRs fixing the import order to some components repos: > | > Hawkular: https://github.com/hawkular/hawkular/pull/384 > | > Alerts: https://github.com/hawkular/hawkular-alerts/pull/79 > | > Metrics: https://github.com/hawkular/hawkular-metrics/pull/296 > | > Inventory: https://github.com/hawkular/hawkular-inventory/pull/135 > | > > | > While ordering the imports using Eclipse in the above projects, I have > | > found only one subtle mismatch between Eclipse and checkstyle: Here > | > https://github.com/hawkular/hawkular-metrics/blob/2062a0a63e3d4a9eb22f77a79e082324d3b166a1/core/metrics-core-api/src/test/java/org/hawkular/metrics/core/api/IntervalTest.java#L19-L22 > | > > | > Eclipse wants > | > > | > import static org.hawkular.metrics.core.api.Interval.parse; > | > import static org.hawkular.metrics.core.api.Interval.Units.DAYS; > | > import static org.hawkular.metrics.core.api.Interval.Units.HOURS; > | > import static org.hawkular.metrics.core.api.Interval.Units.MINUTES; > | > > | > While Checkstyle wants > | > > | > import static org.hawkular.metrics.core.api.Interval.Units.DAYS; > | > import static org.hawkular.metrics.core.api.Interval.Units.HOURS; > | > import static org.hawkular.metrics.core.api.Interval.Units.MINUTES; > | > import static org.hawkular.metrics.core.api.Interval.parse; > | > > | > There was just one occurrence of this problem and I hope that we can > | > neglect it. > | > > | > Thanks, > | > > | > Peter > | > > | > [1] https://github.com/hawkular/hawkular-build-tools/pull/21 > | > > | > On 2015-06-17 09:11, Peter Palaga wrote: > | >> OK, I'll add the import order check to checkstyle. > | >> https://issues.jboss.org/browse/HAWKULAR-358 -- P > | >> > | >> On 16/06/15 12:14, Thomas Segismont wrote: > | >>> Le 16/06/2015 11:50, Peter Palaga a ?crit : > | >>>> Hi Mazz, > | >>>> > | >>>> While I can remember some basic discussion about the order Java imports, > | >>>> I do not remember at all what was the result. > | >>>> > | >>>> I saw that you added Eclipse prefs for import order to dev tools which > | >>>> is definitely good > | >>>> https://github.com/hawkular/hawkular-build-tools/blob/master/ide-configs/eclipse/hawkular-eclipse-preferences-java-codestyle-organizeimports.importorder > | >>>> > | >>>> Do Idea prefs contain the same settings? > | >>> > | >>> Yes, they were built by Lucas and reviewed by me. > | >>> > | >>>> > | >>>> Are there projects using these settings consequently? > | >>> > | >>> All projects _should_ be using the same. > | >>> > | >>>> > | >>>> But did we say we would enforce the imports order by checkstyle? > | >>> > | >>> We didn't talk about that. > | >>> > | >>> I have recently commented on GitHub that import order was the only thing > | >>> not checked yet, and we keep on seeing PR with many lines of import > | >>> order differences. > | >>> > | >>> To me, it shows that formatting rules, if not enforced, are not > | >>> naturally observed. > | >>> > | >>>> They have a rule for that: > | >>>> http://checkstyle.sourceforge.net/config_imports.html#ImportOrder > | >>> > | >>> +1 for adding > | >>> > | >>>> > | >>>> Its a pity that we have not done it earlier. > | >>>> > | >>>> Thanks, > | >>>> > | >>>> Peter > | >>>> _______________________________________________ > | >>>> hawkular-dev mailing list > | >>>> hawkular-dev at lists.jboss.org > | >>>> https://lists.jboss.org/mailman/listinfo/hawkular-dev > | >>>> > | >>> > | >>> _______________________________________________ > | >>> hawkular-dev mailing list > | >>> hawkular-dev at lists.jboss.org > | >>> https://lists.jboss.org/mailman/listinfo/hawkular-dev > | >>> > | >> > | >> _______________________________________________ > | >> hawkular-dev mailing list > | >> hawkular-dev at lists.jboss.org > | >> https://lists.jboss.org/mailman/listinfo/hawkular-dev > | >> > | > > | > _______________________________________________ > | > hawkular-dev mailing list > | > hawkular-dev at lists.jboss.org > | > https://lists.jboss.org/mailman/listinfo/hawkular-dev > | > > | > | _______________________________________________ > | hawkular-dev mailing list > | hawkular-dev at lists.jboss.org > | https://lists.jboss.org/mailman/listinfo/hawkular-dev > | > > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > From ppalaga at redhat.com Wed Aug 5 13:03:46 2015 From: ppalaga at redhat.com (Peter Palaga) Date: Wed, 5 Aug 2015 19:03:46 +0200 Subject: [Hawkular-dev] New or noteworthy in hawkular-parent 19 Message-ID: <55C241F2.3060007@redhat.com> Hi *, New or noteworthy in hawkular-parent 19 [1]: * WildFly BoM import removed, the projects will have to import it themselves where appropriate using org.wildfly.bom jboss-javaee-7.0-wildfly ${version.org.wildfly} pom import * Debug port for tests changed to 8789 to not clash with the server * License checks: * Use slashstar style /* rather than JavaDoc style /** in Groovy files license header * *.adoc files excluded from license checks * Checkstyle rule for imports order * Both Eclipse and IJ settings were tested for compliance with the rule * IJ settings were updated today * Please make sure that your settings are up to date: https://github.com/hawkular/hawkular-build-tools/tree/master/ide-configs * IJ users, beware of the issue described by Juca: > For IntelliJ users out there: while testing this PR, I got into an > interesting problem, in that IntelliJ seems to "forget" the settings.jar > that was imported. > > If you get checkstyle errors even after using IntelliJ to "Organize > Imports", you might want to check if you still have the settings.jar > imported. The easiest way is to create a new class and see if the > license headers are there. If they are not there, then: > > - Import the settings.jar > - IntelliJ asks you to restart, which you comply > - Once IntelliJ starts again, close it and start it again (manually) > - Import the settings.jar again > - It should be fixed (test by creating a new file/class). I have sent PRs with an upgrade to parent 18 to Hawkular and Inventory and I will continue tomorrow. Best, Peter [1] https://github.com/hawkular/hawkular-parent-pom/commits/19 _______________________________________________ hawkular-dev mailing list hawkular-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/hawkular-dev From jpkroehling at redhat.com Thu Aug 6 06:12:59 2015 From: jpkroehling at redhat.com (=?UTF-8?Q?Juraci_Paix=c3=a3o_Kr=c3=b6hling?=) Date: Thu, 6 Aug 2015 12:12:59 +0200 Subject: [Hawkular-dev] hawkular-accounts integration with websocket stuff in kettle In-Reply-To: <55BF7BDC.4020409@redhat.com> References: <279801412.2495350.1438563691349.JavaMail.zimbra@redhat.com> <55BF7BDC.4020409@redhat.com> Message-ID: <55C3332B.80206@redhat.com> As an status, since it's been a couple of days already: TL;DR: - I have a branch in Accounts with a PoC for WebSockets. It's nowhere near, but it's "started" at least: http://git.io/vOSBT - There's a discussion on Keycloak about this, but I don't think we should expect much from it. Mostly because it's understood that this is an application's concern (from the WebSocket's point of view). So, we are likely going to follow the route of implementing a "check" on each onMessage. Not clean, certainly invasive, but works. I'll try to alleviate the pain as much as I can by providing simple APIs. Long version: It seems that my knowledge of WebSockets isn't that outdated, as not much has happened lately. The thing is, WebSockets doesn't define any standard for authentication and/or authorization. On the spec, it says that it should rely on HTTP authentication, done on the upgrade request. That provides only a small part of the whole authentication scheme, though: given that a WebSocket can potentially live for a very long time (hours, or even days), it's likely that a session might expire during the lifetime of the socket connection. So, this connection has to be "somehow" refreshed or killed. Keycloak won't be able to help that much once a connection is established, though: the only way of checking if a connection is still valid is by asking the client to send their latest token, and checking this token against KC server. And this would have to be part of the message's payload, which is very invasive from the PoV of the application. So, I don't expect any "transparent" support for WebSockets, the same way we have for regular HTTP requests. The current ideas are: - Check what's undertow's support for WebSockets. If it provides something like a "filter" for messages, Accounts could intercept the messages and do the checks it needs, removing the auth part from the message (so that the server endpoint wouldn't have to worry about it at all). The client, however, would still need to know how to "talk auth", as the server might ask it for renewed tokens. - If undertow has no support for filters or similar, then the actual server endpoints would have to call Accounts with the payload (and the session). Accounts would then either let the processing continue, ask the client for a renewed token (to be sent on subsequent payloads), or kill the connection (if no new token was received to replace the token that just expired). - In any case, Accounts would provide a Persona object. On the first case, it could be via CDI (hopefully), on the second case it would be via an API where Accounts receives the token and returns a Persona. Is there something you'd require that I might be missing? - Juca. On 08/03/2015 04:34 PM, Juraci Paix?o Kr?hling wrote: > Mazz, > > On 08/03/2015 03:01 AM, John Mazzitelli wrote: >> I think the time is coming close when I need to wrap authentication >> around the websockets stuff we have in the server. Right now, any >> client can connect to our websocket server running in kettle. I know >> you mentioned that KeyCloak doesn't have an official integration with >> websockets today, but can we make calls to your accounts API directly >> to do things like logging in? > > I'm afraid my knowledge of WebSockets might be outdated with regards to > authentication. I'm quite sure there's no specific WebSocket support on > Keycloak, but we might be able to leverage JAAS integration on that. > > In any case, I'll run some tests and come up with some options, so that > we can start a discussion. > > - Juca. From hrupp at redhat.com Thu Aug 6 06:38:04 2015 From: hrupp at redhat.com (Heiko W.Rupp) Date: Thu, 06 Aug 2015 12:38:04 +0200 Subject: [Hawkular-dev] hawkular-accounts integration with websocket stuff in kettle In-Reply-To: <55C3332B.80206@redhat.com> References: <279801412.2495350.1438563691349.JavaMail.zimbra@redhat.com> <55BF7BDC.4020409@redhat.com> <55C3332B.80206@redhat.com> Message-ID: <3858E48C-16FE-41D5-B841-D79DD3A74FAD@redhat.com> > That provides only a small part of the whole authentication scheme, > though: given that a WebSocket can potentially live for a very long time > (hours, or even days), it's likely that a session might expire during > the lifetime of the socket connection. So, this connection has to be > "somehow" refreshed or killed. What do you mean by session expiring (which session)? If the WS-client goes away, the server will see an event for it. What may possibly more a cause for concern is that a Hawkular user may have a WS-connection open and the user is removed from the user database. In this case we may want to invalidate all tokens/grants and also forcefully disconnect the WS. From jpkroehling at redhat.com Thu Aug 6 06:40:26 2015 From: jpkroehling at redhat.com (=?UTF-8?Q?Juraci_Paix=c3=a3o_Kr=c3=b6hling?=) Date: Thu, 6 Aug 2015 12:40:26 +0200 Subject: [Hawkular-dev] hawkular-accounts integration with websocket stuff in kettle In-Reply-To: <3858E48C-16FE-41D5-B841-D79DD3A74FAD@redhat.com> References: <279801412.2495350.1438563691349.JavaMail.zimbra@redhat.com> <55BF7BDC.4020409@redhat.com> <55C3332B.80206@redhat.com> <3858E48C-16FE-41D5-B841-D79DD3A74FAD@redhat.com> Message-ID: <55C3399A.9090609@redhat.com> On 08/06/2015 12:38 PM, Heiko W.Rupp wrote: >> That provides only a small part of the whole authentication scheme, >> though: given that a WebSocket can potentially live for a very long time >> (hours, or even days), it's likely that a session might expire during >> the lifetime of the socket connection. So, this connection has to be >> "somehow" refreshed or killed. > > What do you mean by session expiring (which session)? The HTTP session. For instance, if the user has performed a "single sign out". Then, the user should be logged out of all applications. > What may possibly more a cause for concern is that a Hawkular user may > have a WS-connection open and the user is removed from the user > database. In this case we may want to invalidate all tokens/grants and > also forcefully disconnect the WS. That's a good variant for the above scenario. - Juca. From mazz at redhat.com Thu Aug 6 09:05:52 2015 From: mazz at redhat.com (John Mazzitelli) Date: Thu, 6 Aug 2015 09:05:52 -0400 (EDT) Subject: [Hawkular-dev] hawkular-accounts integration with websocket stuff in kettle In-Reply-To: <55C3332B.80206@redhat.com> References: <279801412.2495350.1438563691349.JavaMail.zimbra@redhat.com> <55BF7BDC.4020409@redhat.com> <55C3332B.80206@redhat.com> Message-ID: <1827068245.5018262.1438866352981.JavaMail.zimbra@redhat.com> > Is there something you'd require that I might be missing? If we have something like this: > So, we are likely going to follow the route of implementing a "check" on each > onMessage. Not clean, certainly invasive, but works. I'll try to > alleviate the pain as much as I can by providing simple APIs. then that would be very helpful and possibly most of what we need (I say "most" because this wouldn't cover the use-case Heiko just mentioned - what if a user has been removed from the system - we would need to know that and forcibly disconnect the WebSocket connection - but that's an edge case. For now, just care about the general use-case of a user making a connection - how do we authenticate that user?) From jpkroehling at redhat.com Thu Aug 6 09:21:06 2015 From: jpkroehling at redhat.com (=?UTF-8?Q?Juraci_Paix=c3=a3o_Kr=c3=b6hling?=) Date: Thu, 6 Aug 2015 15:21:06 +0200 Subject: [Hawkular-dev] hawkular-accounts integration with websocket stuff in kettle In-Reply-To: <1827068245.5018262.1438866352981.JavaMail.zimbra@redhat.com> References: <279801412.2495350.1438563691349.JavaMail.zimbra@redhat.com> <55BF7BDC.4020409@redhat.com> <55C3332B.80206@redhat.com> <1827068245.5018262.1438866352981.JavaMail.zimbra@redhat.com> Message-ID: <55C35F42.2020709@redhat.com> On 08/06/2015 03:05 PM, John Mazzitelli wrote: >> Is there something you'd require that I might be missing? > > If we have something like this: > >> So, we are likely going to follow the route of implementing a "check" on each >> onMessage. Not clean, certainly invasive, but works. I'll try to >> alleviate the pain as much as I can by providing simple APIs. > > then that would be very helpful and possibly most of what we need (I say "most" because this wouldn't cover the use-case Heiko just mentioned - what if a user has been removed from the system - we would need to know that and forcibly disconnect the WebSocket connection - but that's an edge case. For now, just care about the general use-case of a user making a connection - how do we authenticate that user?) I'd say that it even fulfills this case, as the check would be done on Accounts, having access to the session. Accounts would then close the session if needed. - Juca. From mithomps at redhat.com Thu Aug 6 22:02:44 2015 From: mithomps at redhat.com (mike thompson) Date: Thu, 6 Aug 2015 19:02:44 -0700 Subject: [Hawkular-dev] UI Dev upgrade to Typescript 1.5 Message-ID: <779CD038-E361-49E2-8C9D-B96E62192734@redhat.com> Hawkular UI Devs, If you have not upgraded your dev environments to Typescript 1.5 please do so as we will be incorporating Typescript 1.5 language features into our codebase. ** If you just compile Hawkular in the Hawkular build, you can disregard this message, only if you are doing dev work does this apply (meaning you have the Typescript compiler already installed) ** Doing a compile in your dev environment might not compile if you have not updated your typescript compiler. To verify what version your ts compiler is type: ? hawkular: tsc --version message TS6029: Version 1.5.3 It should read >= 1.5 If it does not you should upgrade your local environment via: sudo npm update -g typescript If you are not doing typescript development, then all of this unnecessary as the maven plugin handles downloading the proper tools for an automated build. ? Mike From ppalaga at redhat.com Fri Aug 7 04:21:35 2015 From: ppalaga at redhat.com (Peter Palaga) Date: Fri, 7 Aug 2015 10:21:35 +0200 Subject: [Hawkular-dev] Manage cassandra-all in hawkular-parent Message-ID: <55C46A8F.8000602@redhat.com> Hi *, ATM, cassandra-all is managed on three places independently, which is hard to keep in sync: org.apache.cassandra:cassandra-all occurences: org.hawkular.metrics:cassandra-seed-provider:2.1.6 org.hawkular.commons:hawkular-commons-embedded-cassandra-service:2.1.6 org.hawkular.alerts:hawkular-alerts-engine:2.1.1 I'd put cassandra-all newest 2.1.* version (2.1.8) to dependencyManagement in hawkular-parent unless somebody protests loudly. Note, that we already manage com.datastax.cassandra:cassandra-driver-core in parent. The driver's release cycle is independendent from cassandra-all. The newest 2.1.* version of the driver is 2.1.7.1 and I am going to upgrade to that one in Parent. Thanks, Peter From ppalaga at redhat.com Fri Aug 7 04:31:16 2015 From: ppalaga at redhat.com (Peter Palaga) Date: Fri, 7 Aug 2015 10:31:16 +0200 Subject: [Hawkular-dev] Who is the maintainer of embedded Cassandra? Message-ID: <55C46CD4.7080109@redhat.com> Hi *, I had hard time to figure out who was the best to ask for a review of a PR that I have sent to embedded Cassandra yesterday. Is there anybody here who feels to be the maintainer of that code? And if not, would please somebody with enough expertise with Cassandra overtook that position? Thanks, Peter From jsanda at redhat.com Fri Aug 7 09:33:21 2015 From: jsanda at redhat.com (John Sanda) Date: Fri, 7 Aug 2015 09:33:21 -0400 Subject: [Hawkular-dev] Who is the maintainer of embedded Cassandra? In-Reply-To: <55C46CD4.7080109@redhat.com> References: <55C46CD4.7080109@redhat.com> Message-ID: <38653FC7-4D1E-471E-9223-50DFC8AC9312@redhat.com> Stefan wrote it, so he is a good one to ask for review. I could as well. > On Aug 7, 2015, at 4:31 AM, Peter Palaga wrote: > > Hi *, > > I had hard time to figure out who was the best to ask for a review of a > PR that I have sent to embedded Cassandra yesterday. > > Is there anybody here who feels to be the maintainer of that code? And > if not, would please somebody with enough expertise with Cassandra > overtook that position? > > Thanks, > > Peter > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev From jsanda at redhat.com Fri Aug 7 09:35:10 2015 From: jsanda at redhat.com (John Sanda) Date: Fri, 7 Aug 2015 09:35:10 -0400 Subject: [Hawkular-dev] [metrics] schema changes Message-ID: <96DF6CD7-D238-4F1D-9F4C-5E8726E0AED3@redhat.com> The work for HWKMETRICS-168 was merged into the master branch of the hawkular-metrics repo earlier today. If you work out of master, you will need to recreate your schema(s). Some changes were made to the task_queue and leases tables. - John From jsanda at redhat.com Fri Aug 7 09:38:36 2015 From: jsanda at redhat.com (John Sanda) Date: Fri, 7 Aug 2015 09:38:36 -0400 Subject: [Hawkular-dev] Manage cassandra-all in hawkular-parent In-Reply-To: <55C46A8F.8000602@redhat.com> References: <55C46A8F.8000602@redhat.com> Message-ID: Definitely a good idea. And to be honest, I don?t see any reason not to move to Cassandra 2.2. H-Metrics might need to stay on 2.1.x for the OpenShift integration, but was can (easily) manage that separately. > On Aug 7, 2015, at 4:21 AM, Peter Palaga wrote: > > Hi *, > > ATM, cassandra-all is managed on three places independently, which is > hard to keep in sync: > > org.apache.cassandra:cassandra-all occurences: > org.hawkular.metrics:cassandra-seed-provider:2.1.6 > org.hawkular.commons:hawkular-commons-embedded-cassandra-service:2.1.6 > org.hawkular.alerts:hawkular-alerts-engine:2.1.1 > > I'd put cassandra-all newest 2.1.* version (2.1.8) to > dependencyManagement in hawkular-parent unless somebody protests loudly. > > Note, that we already manage > com.datastax.cassandra:cassandra-driver-core in parent. The driver's > release cycle is independendent from cassandra-all. The newest 2.1.* > version of the driver is 2.1.7.1 and I am going to upgrade to that one > in Parent. > > Thanks, > > Peter > > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev From ppalaga at redhat.com Fri Aug 7 13:27:08 2015 From: ppalaga at redhat.com (Peter Palaga) Date: Fri, 7 Aug 2015 19:27:08 +0200 Subject: [Hawkular-dev] Manage cassandra-all in hawkular-parent In-Reply-To: References: <55C46A8F.8000602@redhat.com> Message-ID: <55C4EA6C.2060606@redhat.com> > I don?t see any reason not to move to Cassandra 2.2 Thanks for the notice, John. That should be a good news for Jay and other Windows users. So I'll take the newest 2.2.* Cassandra and the newest 2.2.* driver. -- P On 2015-08-07 15:38, John Sanda wrote: > Definitely a good idea. And to be honest, I don?t see any reason not to move to Cassandra 2.2. H-Metrics might need to stay on 2.1.x for the OpenShift integration, but was can (easily) manage that separately. > >> On Aug 7, 2015, at 4:21 AM, Peter Palaga wrote: >> >> Hi *, >> >> ATM, cassandra-all is managed on three places independently, which is >> hard to keep in sync: >> >> org.apache.cassandra:cassandra-all occurences: >> org.hawkular.metrics:cassandra-seed-provider:2.1.6 >> org.hawkular.commons:hawkular-commons-embedded-cassandra-service:2.1.6 >> org.hawkular.alerts:hawkular-alerts-engine:2.1.1 >> >> I'd put cassandra-all newest 2.1.* version (2.1.8) to >> dependencyManagement in hawkular-parent unless somebody protests loudly. >> >> Note, that we already manage >> com.datastax.cassandra:cassandra-driver-core in parent. The driver's >> release cycle is independendent from cassandra-all. The newest 2.1.* >> version of the driver is 2.1.7.1 and I am going to upgrade to that one >> in Parent. >> >> Thanks, >> >> Peter >> >> _______________________________________________ >> hawkular-dev mailing list >> hawkular-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hawkular-dev > > > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > From mazz at redhat.com Mon Aug 10 00:09:32 2015 From: mazz at redhat.com (John Mazzitelli) Date: Mon, 10 Aug 2015 00:09:32 -0400 (EDT) Subject: [Hawkular-dev] basic "deploy an app" should be working in kettle now In-Reply-To: <1599343949.6561105.1439179144168.JavaMail.zimbra@redhat.com> Message-ID: <778774363.6562982.1439179772507.JavaMail.zimbra@redhat.com> I got the basic use-case "deploy an application" working tonight so I released a new bus and agent with the feature so building hawkular/dist master branch should pull it in. I'll talk to the UI folks Monday morning on what they need to do next. But, in short, look at the DeployApplicationRequest JSON [1] - that's the JSON request. You must stream the application file content (the war or ear or whatever) immediately following the JSON text over the websocket as a single message. My example .html [2] shows how I was able to stream data over the websocket to submit the request, but I did it by having the client browser load the file in memory first - not something I think we want to do in the product, but, this is how I got it to work: ===== ... ... ...