From hrupp at redhat.com  Fri Jan 16 04:42:08 2015
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Fri, 16 Jan 2015 10:42:08 +0100
Subject: [Hawkular-dev] Welcome to Hawkular-dev
Message-ID: <63CCB041-A472-4BFB-B7CD-D731B8E576A0@redhat.com>

Hello and welcome to Hawkular.

This list is intended to discuss the development of Hawkular and all of its sub-projects.

  Heiko



From tsegismo at redhat.com  Fri Jan 16 04:47:40 2015
From: tsegismo at redhat.com (Thomas Segismont)
Date: Fri, 16 Jan 2015 10:47:40 +0100
Subject: [Hawkular-dev] [metrics] Looking for advice on ListenableFuture
	usage
Message-ID: <54B8DE3C.4000400@redhat.com>

Hi everyone,

I'm looking for advice on how to use Futures#transform[1] and friends 
(#addCallback, #withFallback)

These methods all have an overloaded version which takes a JDK Executor 
instance as additional argument.

When the base method is called, Guava will use the so-called 
"sameThreadExecutor". Consequently, the code will be executed:
* by the caller thread, if the underlying Future has completed already
* otherwise, by the thread completing the underlying Future

When the overloaded method is called, Guava will submit tasks to the 
provided executor.

In the metrics code right now, the base method is used almost 
everywhere. Considering that in most cases it will take more time to get 
the response from C* than to complete the REST Handler code, it's the 
Datastax driver threads which will execute the chain of callbacks, down 
to the call to javax.ws.rs.container.AsyncResponse#resume

Could that be a problem? I guess it's safe when callbacks only 
transforms the data loaded. I'm not sure about the call to 
AsyncResponse#resume.

Thoughts?

Thanks,
Thomas


[1] 
http://docs.guava-libraries.googlecode.com/git-history/v16.0.1/javadoc/com/google/common/util/concurrent/Futures.html 


From jsanda at redhat.com  Fri Jan 16 08:23:33 2015
From: jsanda at redhat.com (John Sanda)
Date: Fri, 16 Jan 2015 08:23:33 -0500
Subject: [Hawkular-dev] [metrics] Looking for advice on ListenableFuture
	usage
In-Reply-To: <54B8DE3C.4000400@redhat.com>
References: <54B8DE3C.4000400@redhat.com>
Message-ID: <9047D361-5FEB-40A8-A29F-0C85BCB6393B@redhat.com>

In the metrics code, at least where a response from the C* driver is involved, the versions that take an executor is used almost everywhere. We do not want to block I/O threads doing work so in general it is best to use the overloaded versions of the methods.

> On Jan 16, 2015, at 4:47 AM, Thomas Segismont <tsegismo at redhat.com> wrote:
> 
> Hi everyone,
> 
> I'm looking for advice on how to use Futures#transform[1] and friends 
> (#addCallback, #withFallback)
> 
> These methods all have an overloaded version which takes a JDK Executor 
> instance as additional argument.
> 
> When the base method is called, Guava will use the so-called 
> "sameThreadExecutor". Consequently, the code will be executed:
> * by the caller thread, if the underlying Future has completed already
> * otherwise, by the thread completing the underlying Future
> 
> When the overloaded method is called, Guava will submit tasks to the 
> provided executor.
> 
> In the metrics code right now, the base method is used almost 
> everywhere. Considering that in most cases it will take more time to get 
> the response from C* than to complete the REST Handler code, it's the 
> Datastax driver threads which will execute the chain of callbacks, down 
> to the call to javax.ws.rs.container.AsyncResponse#resume
> 
> Could that be a problem? I guess it's safe when callbacks only 
> transforms the data loaded. I'm not sure about the call to 
> AsyncResponse#resume.
> 
> Thoughts?
> 
> Thanks,
> Thomas
> 
> 
> [1] 
> http://docs.guava-libraries.googlecode.com/git-history/v16.0.1/javadoc/com/google/common/util/concurrent/Futures.html 
> 
> _______________________________________________
> Hawkular-dev mailing list
> Hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev



From mazz at redhat.com  Fri Jan 16 09:41:30 2015
From: mazz at redhat.com (John Mazzitelli)
Date: Fri, 16 Jan 2015 09:41:30 -0500 (EST)
Subject: [Hawkular-dev] hawkular blog post
In-Reply-To: <833249429.8496906.1421343347830.JavaMail.zimbra@redhat.com>
References: <833249429.8496906.1421343347830.JavaMail.zimbra@redhat.com>
Message-ID: <9430605.9143424.1421419290413.JavaMail.zimbra@redhat.com>

FYI: I just posted the following blogwrt bus/nest work. Use this as a kind of status of what I've been up to :)

Read it here:

http://management-platform.blogspot.com/2015/01/hawkular-bus.html

From tsegismo at redhat.com  Fri Jan 16 10:48:23 2015
From: tsegismo at redhat.com (Thomas Segismont)
Date: Fri, 16 Jan 2015 16:48:23 +0100
Subject: [Hawkular-dev] [metrics] Looking for advice on ListenableFuture
 usage
In-Reply-To: <9047D361-5FEB-40A8-A29F-0C85BCB6393B@redhat.com>
References: <54B8DE3C.4000400@redhat.com>
	<9047D361-5FEB-40A8-A29F-0C85BCB6393B@redhat.com>
Message-ID: <54B932C7.4090101@redhat.com>

Sorry I overlooked the metrics-core code.

Indeed, almost every call where a ListenableFuture returned by the C* 
driver is involved uses the overloaded version (with the metricsTasks 
ListenableExecutor instance).
Should I open a JIRA for the few places where it's missing?

My understanding from you reply is that:
* all transformations on ListenableFuture returned by the C* driver 
should happen in a thread of the metricsTasks pool
==> use the overloaded version
* subsequent transformations may happen on the metricsTasks thread or on 
the thread executing the rest handler code
==> use the base version
Is that correct?

Thanks

Le 16/01/2015 14:23, John Sanda a ?crit :
> In the metrics code, at least where a response from the C* driver is involved, the versions that take an executor is used almost everywhere. We do not want to block I/O threads doing work so in general it is best to use the overloaded versions of the methods.
B>
>> On Jan 16, 2015, at 4:47 AM, Thomas Segismont <tsegismo at redhat.com> wrote:
>>
>> Hi everyone,
>>
>> I'm looking for advice on how to use Futures#transform[1] and friends
>> (#addCallback, #withFallback)
>>
>> These methods all have an overloaded version which takes a JDK Executor
>> instance as additional argument.
>>
>> When the base method is called, Guava will use the so-called
>> "sameThreadExecutor". Consequently, the code will be executed:
>> * by the caller thread, if the underlying Future has completed already
>> * otherwise, by the thread completing the underlying Future
>>
>> When the overloaded method is called, Guava will submit tasks to the
>> provided executor.
>>
>> In the metrics code right now, the base method is used almost
>> everywhere. Considering that in most cases it will take more time to get
>> the response from C* than to complete the REST Handler code, it's the
>> Datastax driver threads which will execute the chain of callbacks, down
>> to the call to javax.ws.rs.container.AsyncResponse#resume
>>
>> Could that be a problem? I guess it's safe when callbacks only
>> transforms the data loaded. I'm not sure about the call to
>> AsyncResponse#resume.
>>
>> Thoughts?
>>
>> Thanks,
>> Thomas
>>
>>
>> [1]
>> http://docs.guava-libraries.googlecode.com/git-history/v16.0.1/javadoc/com/google/common/util/concurrent/Futures.html
>>
>> _______________________________________________
>> Hawkular-dev mailing list
>> Hawkular-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>


From jsanda at redhat.com  Fri Jan 16 11:21:06 2015
From: jsanda at redhat.com (John Sanda)
Date: Fri, 16 Jan 2015 11:21:06 -0500
Subject: [Hawkular-dev] [metrics] Looking for advice on ListenableFuture
	usage
In-Reply-To: <54B932C7.4090101@redhat.com>
References: <54B8DE3C.4000400@redhat.com>
	<9047D361-5FEB-40A8-A29F-0C85BCB6393B@redhat.com>
	<54B932C7.4090101@redhat.com>
Message-ID: <C9BA333D-A4E8-46A6-BE71-44C3A7059875@redhat.com>

I don?t think it necessary to add a ticket for such a small change. I am glad you mentioned the REST handler code. To be honest, I am not sure. With the driver, I do know from experience that if you start blocking I/O threads with work that takes a non-trivial amount of time, you are going to start seeing client side timeouts. An I/O thread services multiple requests concurrently. For the REST handler code, we ought to investigate whether or not it would be better to perform the transformations on a separate thread.

> On Jan 16, 2015, at 10:48 AM, Thomas Segismont <tsegismo at redhat.com> wrote:
> 
> Sorry I overlooked the metrics-core code.
> 
> Indeed, almost every call where a ListenableFuture returned by the C* driver is involved uses the overloaded version (with the metricsTasks ListenableExecutor instance).
> Should I open a JIRA for the few places where it's missing?
> 
> My understanding from you reply is that:
> * all transformations on ListenableFuture returned by the C* driver should happen in a thread of the metricsTasks pool
> ==> use the overloaded version
> * subsequent transformations may happen on the metricsTasks thread or on the thread executing the rest handler code
> ==> use the base version
> Is that correct?
> 
> Thanks
> 
> Le 16/01/2015 14:23, John Sanda a ?crit :
>> In the metrics code, at least where a response from the C* driver is involved, the versions that take an executor is used almost everywhere. We do not want to block I/O threads doing work so in general it is best to use the overloaded versions of the methods.
> B>
>>> On Jan 16, 2015, at 4:47 AM, Thomas Segismont <tsegismo at redhat.com> wrote:
>>> 
>>> Hi everyone,
>>> 
>>> I'm looking for advice on how to use Futures#transform[1] and friends
>>> (#addCallback, #withFallback)
>>> 
>>> These methods all have an overloaded version which takes a JDK Executor
>>> instance as additional argument.
>>> 
>>> When the base method is called, Guava will use the so-called
>>> "sameThreadExecutor". Consequently, the code will be executed:
>>> * by the caller thread, if the underlying Future has completed already
>>> * otherwise, by the thread completing the underlying Future
>>> 
>>> When the overloaded method is called, Guava will submit tasks to the
>>> provided executor.
>>> 
>>> In the metrics code right now, the base method is used almost
>>> everywhere. Considering that in most cases it will take more time to get
>>> the response from C* than to complete the REST Handler code, it's the
>>> Datastax driver threads which will execute the chain of callbacks, down
>>> to the call to javax.ws.rs.container.AsyncResponse#resume
>>> 
>>> Could that be a problem? I guess it's safe when callbacks only
>>> transforms the data loaded. I'm not sure about the call to
>>> AsyncResponse#resume.
>>> 
>>> Thoughts?
>>> 
>>> Thanks,
>>> Thomas
>>> 
>>> 
>>> [1]
>>> http://docs.guava-libraries.googlecode.com/git-history/v16.0.1/javadoc/com/google/common/util/concurrent/Futures.html
>>> 
>>> _______________________________________________
>>> Hawkular-dev mailing list
>>> Hawkular-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>> 
> 



From mazz at redhat.com  Fri Jan 16 11:58:39 2015
From: mazz at redhat.com (John Mazzitelli)
Date: Fri, 16 Jan 2015 11:58:39 -0500 (EST)
Subject: [Hawkular-dev] [metrics] Looking for advice on
	ListenableFuture	usage
In-Reply-To: <C9BA333D-A4E8-46A6-BE71-44C3A7059875@redhat.com>
References: <54B8DE3C.4000400@redhat.com>
	<9047D361-5FEB-40A8-A29F-0C85BCB6393B@redhat.com>
	<54B932C7.4090101@redhat.com>
	<C9BA333D-A4E8-46A6-BE71-44C3A7059875@redhat.com>
Message-ID: <1303322911.9374259.1421427519090.JavaMail.zimbra@redhat.com>

I have no idea if this is relevant, but in the hawkular-bus API, we now have ListenerFuture being used to support async-RPC messaging.

https://github.com/hawkular/hawkular-bus/blob/master/hawkular-bus-common/src/main/java/org/hawkular/bus/common/MessageProcessor.java#L224

Send a given message to the bus via sendRPC(), tell it what type of message to expect in return, and you'll get a ListenableFuture back which you can use to obtain the response asyncyronously from the bus.

----- Original Message -----
> I don?t think it necessary to add a ticket for such a small change. I am glad
> you mentioned the REST handler code. To be honest, I am not sure. With the
> driver, I do know from experience that if you start blocking I/O threads
> with work that takes a non-trivial amount of time, you are going to start
> seeing client side timeouts. An I/O thread services multiple requests
> concurrently. For the REST handler code, we ought to investigate whether or
> not it would be better to perform the transformations on a separate thread.
> 
> > On Jan 16, 2015, at 10:48 AM, Thomas Segismont <tsegismo at redhat.com> wrote:
> > 
> > Sorry I overlooked the metrics-core code.
> > 
> > Indeed, almost every call where a ListenableFuture returned by the C*
> > driver is involved uses the overloaded version (with the metricsTasks
> > ListenableExecutor instance).
> > Should I open a JIRA for the few places where it's missing?
> > 
> > My understanding from you reply is that:
> > * all transformations on ListenableFuture returned by the C* driver should
> > happen in a thread of the metricsTasks pool
> > ==> use the overloaded version
> > * subsequent transformations may happen on the metricsTasks thread or on
> > the thread executing the rest handler code
> > ==> use the base version
> > Is that correct?
> > 
> > Thanks
> > 
> > Le 16/01/2015 14:23, John Sanda a ?crit :
> >> In the metrics code, at least where a response from the C* driver is
> >> involved, the versions that take an executor is used almost everywhere.
> >> We do not want to block I/O threads doing work so in general it is best
> >> to use the overloaded versions of the methods.
> > B>
> >>> On Jan 16, 2015, at 4:47 AM, Thomas Segismont <tsegismo at redhat.com>
> >>> wrote:
> >>> 
> >>> Hi everyone,
> >>> 
> >>> I'm looking for advice on how to use Futures#transform[1] and friends
> >>> (#addCallback, #withFallback)
> >>> 
> >>> These methods all have an overloaded version which takes a JDK Executor
> >>> instance as additional argument.
> >>> 
> >>> When the base method is called, Guava will use the so-called
> >>> "sameThreadExecutor". Consequently, the code will be executed:
> >>> * by the caller thread, if the underlying Future has completed already
> >>> * otherwise, by the thread completing the underlying Future
> >>> 
> >>> When the overloaded method is called, Guava will submit tasks to the
> >>> provided executor.
> >>> 
> >>> In the metrics code right now, the base method is used almost
> >>> everywhere. Considering that in most cases it will take more time to get
> >>> the response from C* than to complete the REST Handler code, it's the
> >>> Datastax driver threads which will execute the chain of callbacks, down
> >>> to the call to javax.ws.rs.container.AsyncResponse#resume
> >>> 
> >>> Could that be a problem? I guess it's safe when callbacks only
> >>> transforms the data loaded. I'm not sure about the call to
> >>> AsyncResponse#resume.
> >>> 
> >>> Thoughts?
> >>> 
> >>> Thanks,
> >>> Thomas
> >>> 
> >>> 
> >>> [1]
> >>> http://docs.guava-libraries.googlecode.com/git-history/v16.0.1/javadoc/com/google/common/util/concurrent/Futures.html
> >>> 
> >>> _______________________________________________
> >>> 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  Fri Jan 16 12:08:35 2015
From: jsanda at redhat.com (John Sanda)
Date: Fri, 16 Jan 2015 12:08:35 -0500
Subject: [Hawkular-dev] [metrics] Looking for advice on
	ListenableFuture	usage
In-Reply-To: <1303322911.9374259.1421427519090.JavaMail.zimbra@redhat.com>
References: <54B8DE3C.4000400@redhat.com>
	<9047D361-5FEB-40A8-A29F-0C85BCB6393B@redhat.com>
	<54B932C7.4090101@redhat.com>
	<C9BA333D-A4E8-46A6-BE71-44C3A7059875@redhat.com>
	<1303322911.9374259.1421427519090.JavaMail.zimbra@redhat.com>
Message-ID: <9D9E49A0-EC50-487F-96F6-7DFA0D2163F3@redhat.com>

I haven?t looked at the code too closely yet, but why the need for ListenableFuture to get the response from the bus? JMS/messaging is already asynchronous.

> On Jan 16, 2015, at 11:58 AM, John Mazzitelli <mazz at redhat.com> wrote:
> 
> I have no idea if this is relevant, but in the hawkular-bus API, we now have ListenerFuture being used to support async-RPC messaging.
> 
> https://github.com/hawkular/hawkular-bus/blob/master/hawkular-bus-common/src/main/java/org/hawkular/bus/common/MessageProcessor.java#L224
> 
> Send a given message to the bus via sendRPC(), tell it what type of message to expect in return, and you'll get a ListenableFuture back which you can use to obtain the response asyncyronously from the bus.
> 
> ----- Original Message -----
>> I don?t think it necessary to add a ticket for such a small change. I am glad
>> you mentioned the REST handler code. To be honest, I am not sure. With the
>> driver, I do know from experience that if you start blocking I/O threads
>> with work that takes a non-trivial amount of time, you are going to start
>> seeing client side timeouts. An I/O thread services multiple requests
>> concurrently. For the REST handler code, we ought to investigate whether or
>> not it would be better to perform the transformations on a separate thread.
>> 
>>> On Jan 16, 2015, at 10:48 AM, Thomas Segismont <tsegismo at redhat.com> wrote:
>>> 
>>> Sorry I overlooked the metrics-core code.
>>> 
>>> Indeed, almost every call where a ListenableFuture returned by the C*
>>> driver is involved uses the overloaded version (with the metricsTasks
>>> ListenableExecutor instance).
>>> Should I open a JIRA for the few places where it's missing?
>>> 
>>> My understanding from you reply is that:
>>> * all transformations on ListenableFuture returned by the C* driver should
>>> happen in a thread of the metricsTasks pool
>>> ==> use the overloaded version
>>> * subsequent transformations may happen on the metricsTasks thread or on
>>> the thread executing the rest handler code
>>> ==> use the base version
>>> Is that correct?
>>> 
>>> Thanks
>>> 
>>> Le 16/01/2015 14:23, John Sanda a ?crit :
>>>> In the metrics code, at least where a response from the C* driver is
>>>> involved, the versions that take an executor is used almost everywhere.
>>>> We do not want to block I/O threads doing work so in general it is best
>>>> to use the overloaded versions of the methods.
>>> B>
>>>>> On Jan 16, 2015, at 4:47 AM, Thomas Segismont <tsegismo at redhat.com>
>>>>> wrote:
>>>>> 
>>>>> Hi everyone,
>>>>> 
>>>>> I'm looking for advice on how to use Futures#transform[1] and friends
>>>>> (#addCallback, #withFallback)
>>>>> 
>>>>> These methods all have an overloaded version which takes a JDK Executor
>>>>> instance as additional argument.
>>>>> 
>>>>> When the base method is called, Guava will use the so-called
>>>>> "sameThreadExecutor". Consequently, the code will be executed:
>>>>> * by the caller thread, if the underlying Future has completed already
>>>>> * otherwise, by the thread completing the underlying Future
>>>>> 
>>>>> When the overloaded method is called, Guava will submit tasks to the
>>>>> provided executor.
>>>>> 
>>>>> In the metrics code right now, the base method is used almost
>>>>> everywhere. Considering that in most cases it will take more time to get
>>>>> the response from C* than to complete the REST Handler code, it's the
>>>>> Datastax driver threads which will execute the chain of callbacks, down
>>>>> to the call to javax.ws.rs.container.AsyncResponse#resume
>>>>> 
>>>>> Could that be a problem? I guess it's safe when callbacks only
>>>>> transforms the data loaded. I'm not sure about the call to
>>>>> AsyncResponse#resume.
>>>>> 
>>>>> Thoughts?
>>>>> 
>>>>> Thanks,
>>>>> Thomas
>>>>> 
>>>>> 
>>>>> [1]
>>>>> http://docs.guava-libraries.googlecode.com/git-history/v16.0.1/javadoc/com/google/common/util/concurrent/Futures.html
>>>>> 
>>>>> _______________________________________________
>>>>> 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 mazz at redhat.com  Fri Jan 16 12:20:43 2015
From: mazz at redhat.com (John Mazzitelli)
Date: Fri, 16 Jan 2015 12:20:43 -0500 (EST)
Subject: [Hawkular-dev] [metrics] Looking for advice on
	ListenableFuture	usage
In-Reply-To: <9D9E49A0-EC50-487F-96F6-7DFA0D2163F3@redhat.com>
References: <54B8DE3C.4000400@redhat.com>
	<9047D361-5FEB-40A8-A29F-0C85BCB6393B@redhat.com>
	<54B932C7.4090101@redhat.com>
	<C9BA333D-A4E8-46A6-BE71-44C3A7059875@redhat.com>
	<1303322911.9374259.1421427519090.JavaMail.zimbra@redhat.com>
	<9D9E49A0-EC50-487F-96F6-7DFA0D2163F3@redhat.com>
Message-ID: <921045651.9391052.1421428843446.JavaMail.zimbra@redhat.com>

> I haven?t looked at the code too closely yet, but why the need for
> ListenableFuture to get the response from the bus? JMS/messaging is already
> asynchronous.

In the RPC-like use-case, I send a message on the bus, and I expect to get a response back from that message. This API helps hide the annoying JMS boiler-plate code you'd have to write to do that RPC-like functionality.

----- Original Message -----
> I haven?t looked at the code too closely yet, but why the need for
> ListenableFuture to get the response from the bus? JMS/messaging is already
> asynchronous.
> 
> > On Jan 16, 2015, at 11:58 AM, John Mazzitelli <mazz at redhat.com> wrote:
> > 
> > I have no idea if this is relevant, but in the hawkular-bus API, we now
> > have ListenerFuture being used to support async-RPC messaging.
> > 
> > https://github.com/hawkular/hawkular-bus/blob/master/hawkular-bus-common/src/main/java/org/hawkular/bus/common/MessageProcessor.java#L224
> > 
> > Send a given message to the bus via sendRPC(), tell it what type of message
> > to expect in return, and you'll get a ListenableFuture back which you can
> > use to obtain the response asyncyronously from the bus.
> > 
> > ----- Original Message -----
> >> I don?t think it necessary to add a ticket for such a small change. I am
> >> glad
> >> you mentioned the REST handler code. To be honest, I am not sure. With the
> >> driver, I do know from experience that if you start blocking I/O threads
> >> with work that takes a non-trivial amount of time, you are going to start
> >> seeing client side timeouts. An I/O thread services multiple requests
> >> concurrently. For the REST handler code, we ought to investigate whether
> >> or
> >> not it would be better to perform the transformations on a separate
> >> thread.
> >> 
> >>> On Jan 16, 2015, at 10:48 AM, Thomas Segismont <tsegismo at redhat.com>
> >>> wrote:
> >>> 
> >>> Sorry I overlooked the metrics-core code.
> >>> 
> >>> Indeed, almost every call where a ListenableFuture returned by the C*
> >>> driver is involved uses the overloaded version (with the metricsTasks
> >>> ListenableExecutor instance).
> >>> Should I open a JIRA for the few places where it's missing?
> >>> 
> >>> My understanding from you reply is that:
> >>> * all transformations on ListenableFuture returned by the C* driver
> >>> should
> >>> happen in a thread of the metricsTasks pool
> >>> ==> use the overloaded version
> >>> * subsequent transformations may happen on the metricsTasks thread or on
> >>> the thread executing the rest handler code
> >>> ==> use the base version
> >>> Is that correct?
> >>> 
> >>> Thanks
> >>> 
> >>> Le 16/01/2015 14:23, John Sanda a ?crit :
> >>>> In the metrics code, at least where a response from the C* driver is
> >>>> involved, the versions that take an executor is used almost everywhere.
> >>>> We do not want to block I/O threads doing work so in general it is best
> >>>> to use the overloaded versions of the methods.
> >>> B>
> >>>>> On Jan 16, 2015, at 4:47 AM, Thomas Segismont <tsegismo at redhat.com>
> >>>>> wrote:
> >>>>> 
> >>>>> Hi everyone,
> >>>>> 
> >>>>> I'm looking for advice on how to use Futures#transform[1] and friends
> >>>>> (#addCallback, #withFallback)
> >>>>> 
> >>>>> These methods all have an overloaded version which takes a JDK Executor
> >>>>> instance as additional argument.
> >>>>> 
> >>>>> When the base method is called, Guava will use the so-called
> >>>>> "sameThreadExecutor". Consequently, the code will be executed:
> >>>>> * by the caller thread, if the underlying Future has completed already
> >>>>> * otherwise, by the thread completing the underlying Future
> >>>>> 
> >>>>> When the overloaded method is called, Guava will submit tasks to the
> >>>>> provided executor.
> >>>>> 
> >>>>> In the metrics code right now, the base method is used almost
> >>>>> everywhere. Considering that in most cases it will take more time to
> >>>>> get
> >>>>> the response from C* than to complete the REST Handler code, it's the
> >>>>> Datastax driver threads which will execute the chain of callbacks, down
> >>>>> to the call to javax.ws.rs.container.AsyncResponse#resume
> >>>>> 
> >>>>> Could that be a problem? I guess it's safe when callbacks only
> >>>>> transforms the data loaded. I'm not sure about the call to
> >>>>> AsyncResponse#resume.
> >>>>> 
> >>>>> Thoughts?
> >>>>> 
> >>>>> Thanks,
> >>>>> Thomas
> >>>>> 
> >>>>> 
> >>>>> [1]
> >>>>> http://docs.guava-libraries.googlecode.com/git-history/v16.0.1/javadoc/com/google/common/util/concurrent/Futures.html
> >>>>> 
> >>>>> _______________________________________________
> >>>>> 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  Fri Jan 16 12:32:49 2015
From: jsanda at redhat.com (John Sanda)
Date: Fri, 16 Jan 2015 12:32:49 -0500
Subject: [Hawkular-dev] [metrics] Looking for advice on
	ListenableFuture	usage
In-Reply-To: <921045651.9391052.1421428843446.JavaMail.zimbra@redhat.com>
References: <54B8DE3C.4000400@redhat.com>
	<9047D361-5FEB-40A8-A29F-0C85BCB6393B@redhat.com>
	<54B932C7.4090101@redhat.com>
	<C9BA333D-A4E8-46A6-BE71-44C3A7059875@redhat.com>
	<1303322911.9374259.1421427519090.JavaMail.zimbra@redhat.com>
	<9D9E49A0-EC50-487F-96F6-7DFA0D2163F3@redhat.com>
	<921045651.9391052.1421428843446.JavaMail.zimbra@redhat.com>
Message-ID: <F3BF7423-51C7-430C-A723-8528534DE7E6@redhat.com>


> On Jan 16, 2015, at 12:20 PM, John Mazzitelli <mazz at redhat.com> wrote:
> 
>> I haven?t looked at the code too closely yet, but why the need for
>> ListenableFuture to get the response from the bus? JMS/messaging is already
>> asynchronous.
> 
> In the RPC-like use-case, I send a message on the bus, and I expect to get a response back from that message. This API helps hide the annoying JMS boiler-plate code you'd have to write to do that RPC-like functionality.

But aren?t you just putting in place more boiler plate with ListenableFuture? The problem with Java futures is that obtaining the result is blocking. ListenableFuture allows you to get the results asynchronously. We already get the results asynchronously with JMS right? I understand the desire for abstracting the JMS code, but I don?t what ListenableFuture buys you.

From mazz at redhat.com  Fri Jan 16 12:38:16 2015
From: mazz at redhat.com (John Mazzitelli)
Date: Fri, 16 Jan 2015 12:38:16 -0500 (EST)
Subject: [Hawkular-dev] eclipse config files available
In-Reply-To: <682662673.9401278.1421429842812.JavaMail.zimbra@redhat.com>
Message-ID: <1344712759.9401591.1421429896981.JavaMail.zimbra@redhat.com>

I committed some Eclipse config files in hawkular-build-tools (under ide-configs/eclipse) - see https://github.com/hawkular/hawkular-build-tools/tree/master/ide-configs/eclipse

You import these into Eclipse to get formatting rules. These should be closely aligned to the checkstyle rules, but if they aren't 100%, feel free to commit fixes to them.

From mazz at redhat.com  Fri Jan 16 12:52:47 2015
From: mazz at redhat.com (John Mazzitelli)
Date: Fri, 16 Jan 2015 12:52:47 -0500 (EST)
Subject: [Hawkular-dev] [metrics] Looking for advice on
	ListenableFuture	usage
In-Reply-To: <F3BF7423-51C7-430C-A723-8528534DE7E6@redhat.com>
References: <54B8DE3C.4000400@redhat.com>
	<9047D361-5FEB-40A8-A29F-0C85BCB6393B@redhat.com>
	<54B932C7.4090101@redhat.com>
	<C9BA333D-A4E8-46A6-BE71-44C3A7059875@redhat.com>
	<1303322911.9374259.1421427519090.JavaMail.zimbra@redhat.com>
	<9D9E49A0-EC50-487F-96F6-7DFA0D2163F3@redhat.com>
	<921045651.9391052.1421428843446.JavaMail.zimbra@redhat.com>
	<F3BF7423-51C7-430C-A723-8528534DE7E6@redhat.com>
Message-ID: <842767701.9411402.1421430767311.JavaMail.zimbra@redhat.com>

I find trying to write the same functionality in straight JMS will show the usefulness of MessageProcessor.sendRPC.

Again, this is to support RPC-like functionality - which isn't trival in JMS (as opposed to fire-and-forget, 1-way messaging). You wouldn't use this sendRPC if you are just shooting a message on the bus and not expecting a direct response to that message.

----- Original Message -----
> 
> > On Jan 16, 2015, at 12:20 PM, John Mazzitelli <mazz at redhat.com> wrote:
> > 
> >> I haven?t looked at the code too closely yet, but why the need for
> >> ListenableFuture to get the response from the bus? JMS/messaging is
> >> already
> >> asynchronous.
> > 
> > In the RPC-like use-case, I send a message on the bus, and I expect to get
> > a response back from that message. This API helps hide the annoying JMS
> > boiler-plate code you'd have to write to do that RPC-like functionality.
> 
> But aren?t you just putting in place more boiler plate with ListenableFuture?
> The problem with Java futures is that obtaining the result is blocking.
> ListenableFuture allows you to get the results asynchronously. We already
> get the results asynchronously with JMS right? I understand the desire for
> abstracting the JMS code, but I don?t what ListenableFuture buys you.


From ppalaga at redhat.com  Fri Jan 16 13:39:05 2015
From: ppalaga at redhat.com (Peter Palaga)
Date: Fri, 16 Jan 2015 19:39:05 +0100
Subject: [Hawkular-dev] eclipse config files available
In-Reply-To: <1344712759.9401591.1421429896981.JavaMail.zimbra@redhat.com>
References: <1344712759.9401591.1421429896981.JavaMail.zimbra@redhat.com>
Message-ID: <54B95AC9.3090106@redhat.com>

Hi John,

thanks for the prefs.

I pushed a small fix to the template containing the license header 
https://github.com/hawkular/hawkular-build-tools/commit/861c38e5a2c284a763ae41ec7130984062f0d144


Besides that, I suppose @author ${user} [1] is not the prefered option 
for the most of us because ${user} resolves to the user name on the 
current machine.
I found this [2] handy plugin that makes the values from Git config 
available in code template variables. So, I propose that we make this 
plugin recommended and that we change the template to something like

* @author ${git_user_name:git_config(user.name)} 
${git_user_email:git_config(user.email)}

WDYT?

Thanks,

Peter

[1] 
https://github.com/hawkular/hawkular-build-tools/blob/master/ide-configs/eclipse/hawkular-eclipse-preferences-java-codestyle-codetemplates.xml#L9
[2] https://github.com/harmsk/eclipse-git-template-variables

On 01/16/2015 06:38 PM, John Mazzitelli wrote:
 > I committed some Eclipse config files in hawkular-build-tools (under 
ide-configs/eclipse) - see 
https://github.com/hawkular/hawkular-build-tools/tree/master/ide-configs/eclipse
 >
 > You import these into Eclipse to get formatting rules. These should 
be closely aligned to the checkstyle rules, but if they aren't 100%, 
feel free to commit fixes to them.
 > _______________________________________________
 > hawkular-dev mailing list
 > hawkular-dev at lists.jboss.org
 > https://lists.jboss.org/mailman/listinfo/hawkular-dev
 >

From jsanda at redhat.com  Fri Jan 16 16:09:25 2015
From: jsanda at redhat.com (John Sanda)
Date: Fri, 16 Jan 2015 16:09:25 -0500
Subject: [Hawkular-dev] [metrics] Looking for advice on
	ListenableFuture	usage
In-Reply-To: <842767701.9411402.1421430767311.JavaMail.zimbra@redhat.com>
References: <54B8DE3C.4000400@redhat.com>
	<9047D361-5FEB-40A8-A29F-0C85BCB6393B@redhat.com>
	<54B932C7.4090101@redhat.com>
	<C9BA333D-A4E8-46A6-BE71-44C3A7059875@redhat.com>
	<1303322911.9374259.1421427519090.JavaMail.zimbra@redhat.com>
	<9D9E49A0-EC50-487F-96F6-7DFA0D2163F3@redhat.com>
	<921045651.9391052.1421428843446.JavaMail.zimbra@redhat.com>
	<F3BF7423-51C7-430C-A723-8528534DE7E6@redhat.com>
	<842767701.9411402.1421430767311.JavaMail.zimbra@redhat.com>
Message-ID: <CEAF0FAB-D2C2-477C-BC20-BE17A2BE07F0@redhat.com>

I am not questioning the usefulness of MessageProcessor.sendRPC. I am wondering why you need/want ListenableFuture. If you want want to obtain responses asynchronously, use a message listener. I see that there is already code like BasicMessageListener that abstracts a lot of stuff for example. Can you point me to an example where the ListenableFuture is used? Maybe that will help me understand.


> On Jan 16, 2015, at 12:52 PM, John Mazzitelli <mazz at redhat.com> wrote:
> 
> I find trying to write the same functionality in straight JMS will show the usefulness of MessageProcessor.sendRPC.
> 
> Again, this is to support RPC-like functionality - which isn't trival in JMS (as opposed to fire-and-forget, 1-way messaging). You wouldn't use this sendRPC if you are just shooting a message on the bus and not expecting a direct response to that message.
> 
> ----- Original Message -----
>> 
>>> On Jan 16, 2015, at 12:20 PM, John Mazzitelli <mazz at redhat.com> wrote:
>>> 
>>>> I haven?t looked at the code too closely yet, but why the need for
>>>> ListenableFuture to get the response from the bus? JMS/messaging is
>>>> already
>>>> asynchronous.
>>> 
>>> In the RPC-like use-case, I send a message on the bus, and I expect to get
>>> a response back from that message. This API helps hide the annoying JMS
>>> boiler-plate code you'd have to write to do that RPC-like functionality.
>> 
>> But aren?t you just putting in place more boiler plate with ListenableFuture?
>> The problem with Java futures is that obtaining the result is blocking.
>> ListenableFuture allows you to get the results asynchronously. We already
>> get the results asynchronously with JMS right? I understand the desire for
>> abstracting the JMS code, but I don?t what ListenableFuture buys you.
> 
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev



From mazz at redhat.com  Fri Jan 16 16:37:04 2015
From: mazz at redhat.com (John Mazzitelli)
Date: Fri, 16 Jan 2015 16:37:04 -0500 (EST)
Subject: [Hawkular-dev] [metrics] Looking for advice on
	ListenableFuture	usage
In-Reply-To: <CEAF0FAB-D2C2-477C-BC20-BE17A2BE07F0@redhat.com>
References: <54B8DE3C.4000400@redhat.com>
	<C9BA333D-A4E8-46A6-BE71-44C3A7059875@redhat.com>
	<1303322911.9374259.1421427519090.JavaMail.zimbra@redhat.com>
	<9D9E49A0-EC50-487F-96F6-7DFA0D2163F3@redhat.com>
	<921045651.9391052.1421428843446.JavaMail.zimbra@redhat.com>
	<F3BF7423-51C7-430C-A723-8528534DE7E6@redhat.com>
	<842767701.9411402.1421430767311.JavaMail.zimbra@redhat.com>
	<CEAF0FAB-D2C2-477C-BC20-BE17A2BE07F0@redhat.com>
Message-ID: <1725717046.9512392.1421444224141.JavaMail.zimbra@redhat.com>

I originally was using Future, and you told me I should use google's ListenableFuture instead :)

I don't think Jay is using it in his alerts stuff, so I can only point you to the unit tests that test it:

see testSendRPC and testSendRPCAndUseListenableFuture in:

https://github.com/hawkular/hawkular-bus/blob/master/hawkular-bus-test-common/src/test/java/org/hawkular/bus/common/test/RPCTest.java

They send a "SpecificMessage" and expect a response back (where the message that comes back in the response merely echoes back to the caller the message that was originally sent in that "SpecificMessage" prefixed with the string "RESPONSE:").

----- Original Message -----
> I am not questioning the usefulness of MessageProcessor.sendRPC. I am
> wondering why you need/want ListenableFuture. If you want want to obtain
> responses asynchronously, use a message listener. I see that there is
> already code like BasicMessageListener that abstracts a lot of stuff for
> example. Can you point me to an example where the ListenableFuture is used?
> Maybe that will help me understand.
> 
> 
> > On Jan 16, 2015, at 12:52 PM, John Mazzitelli <mazz at redhat.com> wrote:
> > 
> > I find trying to write the same functionality in straight JMS will show the
> > usefulness of MessageProcessor.sendRPC.
> > 
> > Again, this is to support RPC-like functionality - which isn't trival in
> > JMS (as opposed to fire-and-forget, 1-way messaging). You wouldn't use
> > this sendRPC if you are just shooting a message on the bus and not
> > expecting a direct response to that message.
> > 
> > ----- Original Message -----
> >> 
> >>> On Jan 16, 2015, at 12:20 PM, John Mazzitelli <mazz at redhat.com> wrote:
> >>> 
> >>>> I haven?t looked at the code too closely yet, but why the need for
> >>>> ListenableFuture to get the response from the bus? JMS/messaging is
> >>>> already
> >>>> asynchronous.
> >>> 
> >>> In the RPC-like use-case, I send a message on the bus, and I expect to
> >>> get
> >>> a response back from that message. This API helps hide the annoying JMS
> >>> boiler-plate code you'd have to write to do that RPC-like functionality.
> >> 
> >> But aren?t you just putting in place more boiler plate with
> >> ListenableFuture?
> >> The problem with Java futures is that obtaining the result is blocking.
> >> ListenableFuture allows you to get the results asynchronously. We already
> >> get the results asynchronously with JMS right? I understand the desire for
> >> abstracting the JMS code, but I don?t what ListenableFuture buys you.
> > 
> > _______________________________________________
> > hawkular-dev mailing list
> > hawkular-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hawkular-dev
> 
>


From lponce at redhat.com  Mon Jan 19 03:59:33 2015
From: lponce at redhat.com (Lucas Ponce)
Date: Mon, 19 Jan 2015 03:59:33 -0500 (EST)
Subject: [Hawkular-dev] eclipse config files available
In-Reply-To: <54B95AC9.3090106@redhat.com>
References: <1344712759.9401591.1421429896981.JavaMail.zimbra@redhat.com>
	<54B95AC9.3090106@redhat.com>
Message-ID: <1565965440.9788940.1421657973955.JavaMail.zimbra@redhat.com>

Hi,

Is there a summary of all changes needed for formatting rules ?

I want to create a native template for IntelliJ IDEA users (to avoid to install a eclipse plugin importer).

In my mind there are:

- Indentation of java files.
- Indentation of xml files.
- Other files.
- Trim lines.
- Licenses.

Any missing item ?

- Templates ?

Thx,
Lucas



----- Original Message -----
> From: "Peter Palaga" <ppalaga at redhat.com>
> To: "John Mazzitelli" <mazz at redhat.com>, hawkular-dev at lists.jboss.org
> Sent: Friday, January 16, 2015 7:39:05 PM
> Subject: Re: [Hawkular-dev] eclipse config files available
> 
> Hi John,
> 
> thanks for the prefs.
> 
> I pushed a small fix to the template containing the license header
> https://github.com/hawkular/hawkular-build-tools/commit/861c38e5a2c284a763ae41ec7130984062f0d144
> 
> 
> Besides that, I suppose @author ${user} [1] is not the prefered option
> for the most of us because ${user} resolves to the user name on the
> current machine.
> I found this [2] handy plugin that makes the values from Git config
> available in code template variables. So, I propose that we make this
> plugin recommended and that we change the template to something like
> 
> * @author ${git_user_name:git_config(user.name)}
> ${git_user_email:git_config(user.email)}
> 
> WDYT?
> 
> Thanks,
> 
> Peter
> 
> [1]
> https://github.com/hawkular/hawkular-build-tools/blob/master/ide-configs/eclipse/hawkular-eclipse-preferences-java-codestyle-codetemplates.xml#L9
> [2] https://github.com/harmsk/eclipse-git-template-variables
> 
> On 01/16/2015 06:38 PM, John Mazzitelli wrote:
>  > I committed some Eclipse config files in hawkular-build-tools (under
> ide-configs/eclipse) - see
> https://github.com/hawkular/hawkular-build-tools/tree/master/ide-configs/eclipse
>  >
>  > You import these into Eclipse to get formatting rules. These should
> be closely aligned to the checkstyle rules, but if they aren't 100%,
> feel free to commit fixes to them.
>  > _______________________________________________
>  > 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  Mon Jan 19 04:22:13 2015
From: ppalaga at redhat.com (Peter Palaga)
Date: Mon, 19 Jan 2015 10:22:13 +0100
Subject: [Hawkular-dev] eclipse config files available
In-Reply-To: <54B95AC9.3090106@redhat.com>
References: <1344712759.9401591.1421429896981.JavaMail.zimbra@redhat.com>
	<54B95AC9.3090106@redhat.com>
Message-ID: <54BCCCC5.10708@redhat.com>

Hi John,

hm... as it stands now, the @author tag is a part of the file comment. 
And when creating a new Java class/interface, it appears between the 
licese header and package declaration. Is this what you wanted?

I mean having @author in the type level JavaDoc comment is much more 
usual.  The type level JavaDoc is the one between imports and type 
declaration. WDYT?

= Example:

== Actual:

/*
  * Copyright 2014 - 2015 Red Hat, Inc. [...]
  */
/**
  *
  * @author ppalaga
  */
package org.hawkular.build.license;

/**
  *
  */
public class C {

}


== Expected:

/*
  * Copyright 2014 - 2015 Red Hat, Inc. [...]
  */
package org.hawkular.build.license;

/**
  *
  * @author ppalaga
  */
public class C {

}


-- Peter

On 01/16/2015 07:39 PM, Peter Palaga wrote:
> Hi John,
>
> thanks for the prefs.
>
> I pushed a small fix to the template containing the license header
> https://github.com/hawkular/hawkular-build-tools/commit/861c38e5a2c284a763ae41ec7130984062f0d144
>
>
> Besides that, I suppose @author ${user} [1] is not the prefered option
> for the most of us because ${user} resolves to the user name on the
> current machine.
> I found this [2] handy plugin that makes the values from Git config
> available in code template variables. So, I propose that we make this
> plugin recommended and that we change the template to something like
>
> * @author ${git_user_name:git_config(user.name)}
> ${git_user_email:git_config(user.email)}
>
> WDYT?
>
> Thanks,
>
> Peter
>
> [1]
> https://github.com/hawkular/hawkular-build-tools/blob/master/ide-configs/eclipse/hawkular-eclipse-preferences-java-codestyle-codetemplates.xml#L9
> [2] https://github.com/harmsk/eclipse-git-template-variables
>
> On 01/16/2015 06:38 PM, John Mazzitelli wrote:
>   > I committed some Eclipse config files in hawkular-build-tools (under
> ide-configs/eclipse) - see
> https://github.com/hawkular/hawkular-build-tools/tree/master/ide-configs/eclipse
>   >
>   > You import these into Eclipse to get formatting rules. These should
> be closely aligned to the checkstyle rules, but if they aren't 100%,
> feel free to commit fixes to them.
>   > _______________________________________________
>   > 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 Jan 19 09:25:16 2015
From: mazz at redhat.com (John Mazzitelli)
Date: Mon, 19 Jan 2015 09:25:16 -0500 (EST)
Subject: [Hawkular-dev] eclipse config files available
In-Reply-To: <54BCCCC5.10708@redhat.com>
References: <1344712759.9401591.1421429896981.JavaMail.zimbra@redhat.com>
	<54B95AC9.3090106@redhat.com> <54BCCCC5.10708@redhat.com>
Message-ID: <1306097038.10089848.1421677516864.JavaMail.zimbra@redhat.com>

opps, that's NOT what I meant. @author is typically in the top-level class javadoc. 

----- Original Message -----
> Hi John,
> 
> hm... as it stands now, the @author tag is a part of the file comment.
> And when creating a new Java class/interface, it appears between the
> licese header and package declaration. Is this what you wanted?
> 
> I mean having @author in the type level JavaDoc comment is much more
> usual.  The type level JavaDoc is the one between imports and type
> declaration. WDYT?
> 
> = Example:
> 
> == Actual:
> 
> /*
>   * Copyright 2014 - 2015 Red Hat, Inc. [...]
>   */
> /**
>   *
>   * @author ppalaga
>   */
> package org.hawkular.build.license;
> 
> /**
>   *
>   */
> public class C {
> 
> }
> 
> 
> == Expected:
> 
> /*
>   * Copyright 2014 - 2015 Red Hat, Inc. [...]
>   */
> package org.hawkular.build.license;
> 
> /**
>   *
>   * @author ppalaga
>   */
> public class C {
> 
> }
> 
> 
> -- Peter
> 
> On 01/16/2015 07:39 PM, Peter Palaga wrote:
> > Hi John,
> >
> > thanks for the prefs.
> >
> > I pushed a small fix to the template containing the license header
> > https://github.com/hawkular/hawkular-build-tools/commit/861c38e5a2c284a763ae41ec7130984062f0d144
> >
> >
> > Besides that, I suppose @author ${user} [1] is not the prefered option
> > for the most of us because ${user} resolves to the user name on the
> > current machine.
> > I found this [2] handy plugin that makes the values from Git config
> > available in code template variables. So, I propose that we make this
> > plugin recommended and that we change the template to something like
> >
> > * @author ${git_user_name:git_config(user.name)}
> > ${git_user_email:git_config(user.email)}
> >
> > WDYT?
> >
> > Thanks,
> >
> > Peter
> >
> > [1]
> > https://github.com/hawkular/hawkular-build-tools/blob/master/ide-configs/eclipse/hawkular-eclipse-preferences-java-codestyle-codetemplates.xml#L9
> > [2] https://github.com/harmsk/eclipse-git-template-variables
> >
> > On 01/16/2015 06:38 PM, John Mazzitelli wrote:
> >   > I committed some Eclipse config files in hawkular-build-tools (under
> > ide-configs/eclipse) - see
> > https://github.com/hawkular/hawkular-build-tools/tree/master/ide-configs/eclipse
> >   >
> >   > You import these into Eclipse to get formatting rules. These should
> > be closely aligned to the checkstyle rules, but if they aren't 100%,
> > feel free to commit fixes to them.
> >   > _______________________________________________
> >   > 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 Jan 19 09:26:33 2015
From: mazz at redhat.com (John Mazzitelli)
Date: Mon, 19 Jan 2015 09:26:33 -0500 (EST)
Subject: [Hawkular-dev] eclipse config files available
In-Reply-To: <54B95AC9.3090106@redhat.com>
References: <1344712759.9401591.1421429896981.JavaMail.zimbra@redhat.com>
	<54B95AC9.3090106@redhat.com>
Message-ID: <1794776815.10092361.1421677593336.JavaMail.zimbra@redhat.com>

> Besides that, I suppose @author ${user} [1] is not the prefered option
> for the most of us because ${user} resolves to the user name on the
> current machine.
> I found this [2] handy plugin that makes the values from Git config
> available in code template variables. So, I propose that we make this
> plugin recommended and that we change the template to something like
> 
> * @author ${git_user_name:git_config(user.name)}
> ${git_user_email:git_config(user.email)}
> 
> WDYT?

I wouldn't want to ask devs to install another plugin just to get this to work. Its gonna be hard enough to ask them to import these into their Eclipse and use it! :)

From ppalaga at redhat.com  Mon Jan 19 13:45:10 2015
From: ppalaga at redhat.com (Peter Palaga)
Date: Mon, 19 Jan 2015 19:45:10 +0100
Subject: [Hawkular-dev] Checking and fixing license headers
Message-ID: <54BD50B6.9030601@redhat.com>

Hi *,

This [1] is is the second version of the PR. It solves the problem 
raised by tsegismont (whose validity was confimed by RH Legal) that in 
the license headers it is necessary to

 > modify the year only in the event of changes and, in that event carry
 > forward the initial year.  For example, if there's a change in 2016,
 > or 2015 and 2016, I'd modify the entry to say Copyright 2014-2016.

The present solution uses a place holder ${license.copyrightYears} in 
the template [2] that is evaluated by the license plugin separately for 
every source file, based on its git history.

My 150116-license [3] branch in metrics shows how to use it.

There are two use cases:

(1) Fix or add the license headers in all project's files through
     issuing

     mvn license:format

     Note that the commit [4] is a result of running mvn license:format
     in the root directory of metrics

(2) Check the presence of the headers and their correctness through

     mvn license:check

     Note that license:check is bound to the validation phase [5]

Is [1] OK to be merged to hawkular-build-tools?

Thanks,

Peter


[1] https://github.com/hawkular/hawkular-build-tools/pull/1
[2] 
https://github.com/ppalaga/hawkular-build-tools/blob/150114-license/src/main/resources/hawkular-license/jboss-apache-2-template.txt#L1
[3] https://github.com/ppalaga/rhq-metrics/tree/150116-license
[4] 
https://github.com/ppalaga/rhq-metrics/commit/4fe8a6faed2bf70deb6e9cf82930d438e2532cd5
[5] https://github.com/ppalaga/rhq-metrics/blob/150116-license/pom.xml#L491

From tsegismo at redhat.com  Tue Jan 20 04:24:03 2015
From: tsegismo at redhat.com (Thomas Segismont)
Date: Tue, 20 Jan 2015 10:24:03 +0100
Subject: [Hawkular-dev] Checking and fixing license headers
In-Reply-To: <54BD50B6.9030601@redhat.com>
References: <54BD50B6.9030601@redhat.com>
Message-ID: <54BE1EB3.5010605@redhat.com>

Hi,

See my comment on GitHub:
https://github.com/hawkular/hawkular-build-tools/pull/1#issuecomment-70625367

Let's continue the conversation there.

Thomas

Le 19/01/2015 19:45, Peter Palaga a ?crit :
> Hi *,
>
> This [1] is is the second version of the PR. It solves the problem
> raised by tsegismont (whose validity was confimed by RH Legal) that in
> the license headers it is necessary to
>
>   > modify the year only in the event of changes and, in that event carry
>   > forward the initial year.  For example, if there's a change in 2016,
>   > or 2015 and 2016, I'd modify the entry to say Copyright 2014-2016.
>
> The present solution uses a place holder ${license.copyrightYears} in
> the template [2] that is evaluated by the license plugin separately for
> every source file, based on its git history.
>
> My 150116-license [3] branch in metrics shows how to use it.
>
> There are two use cases:
>
> (1) Fix or add the license headers in all project's files through
>       issuing
>
>       mvn license:format
>
>       Note that the commit [4] is a result of running mvn license:format
>       in the root directory of metrics
>
> (2) Check the presence of the headers and their correctness through
>
>       mvn license:check
>
>       Note that license:check is bound to the validation phase [5]
>
> Is [1] OK to be merged to hawkular-build-tools?
>
> Thanks,
>
> Peter
>
>
> [1] https://github.com/hawkular/hawkular-build-tools/pull/1
> [2]
> https://github.com/ppalaga/hawkular-build-tools/blob/150114-license/src/main/resources/hawkular-license/jboss-apache-2-template.txt#L1
> [3] https://github.com/ppalaga/rhq-metrics/tree/150116-license
> [4]
> https://github.com/ppalaga/rhq-metrics/commit/4fe8a6faed2bf70deb6e9cf82930d438e2532cd5
> [5] https://github.com/ppalaga/rhq-metrics/blob/150116-license/pom.xml#L491
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>


From theute at redhat.com  Tue Jan 20 04:28:30 2015
From: theute at redhat.com (Thomas Heute)
Date: Tue, 20 Jan 2015 10:28:30 +0100
Subject: [Hawkular-dev] Should the components depend on the bus ?
Message-ID: <54BE1FBE.5000009@redhat.com>


When we started the hawkular efforts, I had in mind that the components 
would do minimum tasks as a library with REST/Java APIs and do them well.

Inventory would manage resources (user defined (an "application", a 
cluster) or architecture defined (an EAP server, a VM, a Kube pod...)), 
assign ids...
Metrics would store/aggregate/compact metrics (like it is today)
Alerts would define some alert definition "model" and run an engine to 
define when to trigger an alert.
...

Hawkular project would then be a firm/comprehensive solution that are 
using all those components, would proxy the APIs, add security there 
(instead of in each component),...

But now I start to see that client aspect of the communication bus is 
part of those components I think I understand the motivation for that 
but not sure that this is what we really need. Am I the only one 
thinking that the communication aspect should be left out of the 
components ?

For instance in http://docs.hawkularinventory.apiary.io/ for the 
DumbFeed, I don't think it's the role of the Metrics to send 
notification to the bus, if we need more than collecting metrics then it 
is a job for Hawkular IMO (who may proxy the metrics request and send 
notification to the bus).

Thomas

From lponce at redhat.com  Tue Jan 20 04:49:53 2015
From: lponce at redhat.com (Lucas Ponce)
Date: Tue, 20 Jan 2015 04:49:53 -0500 (EST)
Subject: [Hawkular-dev] Should the components depend on the bus ?
In-Reply-To: <54BE1FBE.5000009@redhat.com>
References: <54BE1FBE.5000009@redhat.com>
Message-ID: <931241687.10642175.1421747393477.JavaMail.zimbra@redhat.com>

 
> When we started the hawkular efforts, I had in mind that the components
> would do minimum tasks as a library with REST/Java APIs and do them well.
> 
> Inventory would manage resources (user defined (an "application", a
> cluster) or architecture defined (an EAP server, a VM, a Kube pod...)),
> assign ids...
> Metrics would store/aggregate/compact metrics (like it is today)
> Alerts would define some alert definition "model" and run an engine to
> define when to trigger an alert.
> ...
> 
> Hawkular project would then be a firm/comprehensive solution that are
> using all those components, would proxy the APIs, add security there
> (instead of in each component),...
> 
> But now I start to see that client aspect of the communication bus is
> part of those components I think I understand the motivation for that
> but not sure that this is what we really need. Am I the only one
> thinking that the communication aspect should be left out of the
> components ?
>

I think there is info that will be shared between components, so it's needed to define a shared/common model between components.

For example, alerts component should "listen" from some point data/events to evaluate when to trigger an alert.

In the first prototypes we are supposing that it will be a "MetricsTopic" in the bus where alerts component can subscribe for this data.

This is a minimalist scenario.

But, also, yesterday we were discussing with Jay that we can have more complex scenarios, where an alert definition can compare two periods of time (for example, if this week was better than before), in this last scenario we can have requeriments to ask for aggregate data, and transform it in some model that alerts can use to evaluate alerts conditions.

In this last scenario, it seems that an alert definition could ask for data to metrics subsystem.

So, it would be nice if we can progress in the shared data between components to define what it could be best design to implement these scenarios.

I would start with common data (for example, queues/topic identified, data format shared, etc).


 
> For instance in http://docs.hawkularinventory.apiary.io/ for the
> DumbFeed, I don't think it's the role of the Metrics to send
> notification to the bus, if we need more than collecting metrics then it
> is a job for Hawkular IMO (who may proxy the metrics request and send
> notification to the bus).
> 
> Thomas
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> 

From lkrejci at redhat.com  Tue Jan 20 05:14:00 2015
From: lkrejci at redhat.com (Lukas Krejci)
Date: Tue, 20 Jan 2015 11:14 +0100
Subject: [Hawkular-dev] Should the components depend on the bus ?
In-Reply-To: <54BE1FBE.5000009@redhat.com>
References: <54BE1FBE.5000009@redhat.com>
Message-ID: <8126276.y32jeLsonI@localhost.localdomain>

IMHO, the communication should be built into the components precisely because 
they are meant to be components - parts of a bigger picture.

In that scenario, you will rarely encounter usecases where no communication 
between the components is needed. Fabric1 have zookeeper for similar purpose, 
kubernetes have etcd similarly, too.

I am a little bit nervous about using a bespoke solution for that though - but 
as long as it is made such that clients NOT using our bus implementation can 
still communicate with "us" over the actual channel, I'm ok with that (which 
from the little I have read seems to be the case).

Granted, we could abstract the communication out into the glue code as you 
suggest and it would work but I think the potential problems with that 
approach outweigh the requirement for the components to publish events onto 
the bus. Any change in the component API (or behavior!) would have to be 
reflected in the glue, too. The glue would become the bottleneck or would be 
massively harder to deploy in a distributed manner.

>From the POV of purity of the API and functionality, you are absolutely right 
that we should strive for separation of concerns as much as possible. But 
given the fact that our components are meant to work together, I think that 
communication over bus is one of the core requirements for each of them. Maybe 
there should be a config flag to switch such communication off for the times 
where the components will be used outside of hawkular. But I don't think it is 
worth the effort to suppose that the components will primarily be used and 
deployed on their own - I think the opposite is true.

On Tuesday, January 20, 2015 10:28:30 Thomas Heute wrote:
> When we started the hawkular efforts, I had in mind that the components
> would do minimum tasks as a library with REST/Java APIs and do them well.
> 
> Inventory would manage resources (user defined (an "application", a
> cluster) or architecture defined (an EAP server, a VM, a Kube pod...)),
> assign ids...
> Metrics would store/aggregate/compact metrics (like it is today)
> Alerts would define some alert definition "model" and run an engine to
> define when to trigger an alert.
> ...
> 
> Hawkular project would then be a firm/comprehensive solution that are
> using all those components, would proxy the APIs, add security there
> (instead of in each component),...
> 
> But now I start to see that client aspect of the communication bus is
> part of those components I think I understand the motivation for that
> but not sure that this is what we really need. Am I the only one
> thinking that the communication aspect should be left out of the
> components ?
> 
> For instance in http://docs.hawkularinventory.apiary.io/ for the
> DumbFeed, I don't think it's the role of the Metrics to send
> notification to the bus, if we need more than collecting metrics then it
> is a job for Hawkular IMO (who may proxy the metrics request and send
> notification to the bus).
> 

Note that in the DumbFeed example, things would work even without the 
notification. Things would just not be that friendly - basically stuff would 
not automagically appear in the "discovery queue". The user would still be 
able to set up the resource with the metric. They would just have to "remember 
to do so" and use manual look-up to stitch things together.

> Thomas
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev


From theute at redhat.com  Tue Jan 20 06:23:23 2015
From: theute at redhat.com (Thomas Heute)
Date: Tue, 20 Jan 2015 12:23:23 +0100
Subject: [Hawkular-dev] Should the components depend on the bus ?
In-Reply-To: <8126276.y32jeLsonI@localhost.localdomain>
References: <54BE1FBE.5000009@redhat.com>
	<8126276.y32jeLsonI@localhost.localdomain>
Message-ID: <54BE3AAB.7080309@redhat.com>


On 01/20/2015 11:14 AM, Lukas Krejci wrote:
> IMHO, the communication should be built into the components precisely because
> they are meant to be components - parts of a bigger picture.
>
> In that scenario, you will rarely encounter usecases where no communication
> between the components is needed. Fabric1 have zookeeper for similar purpose,
> kubernetes have etcd similarly, too.
I am not saying that they would not need to communicate, they don't 
necessarily have to communicate directly together
> I am a little bit nervous about using a bespoke solution for that though - but
> as long as it is made such that clients NOT using our bus implementation can
> still communicate with "us" over the actual channel, I'm ok with that (which
> from the little I have read seems to be the case).
How ?
> Granted, we could abstract the communication out into the glue code as you
> suggest and it would work but I think the potential problems with that
> approach outweigh the requirement for the components to publish events onto
> the bus. Any change in the component API (or behavior!) would have to be
> reflected in the glue, too.
Component API should not change, that's the contract. And this is what 
needs to be properly tested and hammered.  Behavior would unlikely need 
to change as well if the scope is well defined (HWK Metrics store 
metrics, there is not a lot of behavior to change, behavior would likely 
change at the glue level).
> The glue would become the bottleneck or would be
> massively harder to deploy in a distributed manner.
Why ? It doesn't necessarily have to change how it works but more how it 
is decomposed.

> >From the POV of purity of the API and functionality, you are absolutely right
> that we should strive for separation of concerns as much as possible. But
> given the fact that our components are meant to work together, I think that
> communication over bus is one of the core requirements for each of them. Maybe
> there should be a config flag to switch such communication off for the times
> where the components will be used outside of hawkular. But I don't think it is
> worth the effort to suppose that the components will primarily be used and
> deployed on their own - I think the opposite is true.

Also what are the plans to apply security uniformly across components ? 
We need to make sure that we don't duplicate efforts (and increase 
security issues), today there is keycloak integration in RHQ Metrics, I 
hope we can extract this into the "glue" and share with others.

Thomas



>
> On Tuesday, January 20, 2015 10:28:30 Thomas Heute wrote:
>> When we started the hawkular efforts, I had in mind that the components
>> would do minimum tasks as a library with REST/Java APIs and do them well.
>>
>> Inventory would manage resources (user defined (an "application", a
>> cluster) or architecture defined (an EAP server, a VM, a Kube pod...)),
>> assign ids...
>> Metrics would store/aggregate/compact metrics (like it is today)
>> Alerts would define some alert definition "model" and run an engine to
>> define when to trigger an alert.
>> ...
>>
>> Hawkular project would then be a firm/comprehensive solution that are
>> using all those components, would proxy the APIs, add security there
>> (instead of in each component),...
>>
>> But now I start to see that client aspect of the communication bus is
>> part of those components I think I understand the motivation for that
>> but not sure that this is what we really need. Am I the only one
>> thinking that the communication aspect should be left out of the
>> components ?
>>
>> For instance in http://docs.hawkularinventory.apiary.io/ for the
>> DumbFeed, I don't think it's the role of the Metrics to send
>> notification to the bus, if we need more than collecting metrics then it
>> is a job for Hawkular IMO (who may proxy the metrics request and send
>> notification to the bus).
>>
> Note that in the DumbFeed example, things would work even without the
> notification. Things would just not be that friendly - basically stuff would
> not automagically appear in the "discovery queue". The user would still be
> able to set up the resource with the metric. They would just have to "remember
> to do so" and use manual look-up to stitch things together.
>
>> Thomas
>> _______________________________________________
>> 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 Jan 20 07:56:37 2015
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Tue, 20 Jan 2015 13:56:37 +0100
Subject: [Hawkular-dev] Should the components depend on the bus ?
In-Reply-To: <54BE1FBE.5000009@redhat.com>
References: <54BE1FBE.5000009@redhat.com>
Message-ID: <40158F3A-F571-40B4-81BC-3279D81D76CE@redhat.com>


> Am 20.01.2015 um 10:28 schrieb Thomas Heute <theute at redhat.com>:
> 
> When we started the hawkular efforts, I had in mind that the components 
> would do minimum tasks as a library with REST/Java APIs and do them well.

Yes, as sort of what today are called (asynchronous) Micro-Services.

> 
> Hawkular project would then be a firm/comprehensive solution that are 
> using all those components, would proxy the APIs, add security there 
> (instead of in each component),...

Yes exactly. This is what I tried to picture in https://developer.jboss.org/en/rhq/blog/2014/08/14/thoughts-on-rhqnext-server-architecture
> 
> But now I start to see that client aspect of the communication bus is 
> part of those components I think I understand the motivation for that 
> but not sure that this is what we really need. Am I the only one 
> thinking that the communication aspect should be left out of the 
> components ?

The question is probably how this central Hawkular thing talks to the individual
components. One approach is certainly to use REST-calls, where some central
registry knows about the endpoints, so that e.g. for alerts to fetch some metric values
from some time ago, it would look up the metrics service endpoint for this and then do
the rest-call. I think this is what Netflix does with good success.

The other option is to use a (message) bus system, where Hawkular and parts
put messages on a bus Queue/Topic and the respective component can subscribe and
receive those messages. For example for incoming metrics, Hawkular would put them
into a topic and metrics and alerts would both subscribe to the topic and get incoming
metric data.
Similar if alerts needs past metrics it would put a message on a Destination where metrics
(and possibly other components) would wait for commands and react on them, putting the
result back on the bus (e.g. in a temporary destination that has been passed when sending
the command). Of course this also requires some wiring 

If I understand you correctly, the question is about the api between bus ("JMS") and the
components that so far have a REST-api and where it lives. 
If we try not to "pollute" the individual sub-projects with integration code, which makes a lot of
sense, we probably need to easily define "bus-listeners" inside the bus module, that read
a configuration (file) and know where to listen for events, how to invoke which rest-call and
how to proceed with responses. 

> 
> For instance in http://docs.hawkularinventory.apiary.io/ for the 
> DumbFeed, I don't think it's the role of the Metrics to send 
> notification to the bus, if we need more than collecting metrics then it 
> is a job for Hawkular IMO (who may proxy the metrics request and send 
> notification to the bus).

I guess that depends on the component. E.g. Metrics (and I am not sure
if I agree with the Dumb feed story ) could be a component that only reacts
to incoming requests, but does not initiate requests on its own.
Alerts on the other hand would also initiate requests, as e.g. the notification
senders would be (micro) services on their own, so if an alert fires the alert
engine would put a message on the bus to an alert notification sender to 
do its work.




From hrupp at redhat.com  Tue Jan 20 09:26:00 2015
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Tue, 20 Jan 2015 15:26:00 +0100
Subject: [Hawkular-dev] Should the components depend on the bus ?
In-Reply-To: <931241687.10642175.1421747393477.JavaMail.zimbra@redhat.com>
References: <54BE1FBE.5000009@redhat.com>
	<931241687.10642175.1421747393477.JavaMail.zimbra@redhat.com>
Message-ID: <90E19497-8D75-4EA1-B20B-446167D7A9C8@redhat.com>


> Am 20.01.2015 um 10:49 schrieb Lucas Ponce <lponce at redhat.com>:
>> 
> 
> I think there is info that will be shared between components, so it's needed to define a shared/common model between components.

We need defined APIs, that may result in common Java classes that e.g. describe one metric or a series of metrics for a tenant
or similar.
> 
> For example, alerts component should "listen" from some point data/events to evaluate when to trigger an alert.

Yes. I don't see this as a shared service/component, but rather part of Hawkular-alerts. This may pull in a common java
class that encodes how a metric looks like (see above).

> But, also, yesterday we were discussing with Jay that we can have more complex scenarios, where an alert definition can compare two periods of time (for example, if this week was better than before), in this last scenario we can have requeriments to ask for aggregate data, and transform it in some model that alerts can use to evaluate alerts conditions.

In this case alerts would send a request to metrics (directly or via bus) and ask for that data.




From mazz at redhat.com  Tue Jan 20 09:38:57 2015
From: mazz at redhat.com (John Mazzitelli)
Date: Tue, 20 Jan 2015 09:38:57 -0500 (EST)
Subject: [Hawkular-dev] Should the components depend on the bus ?
In-Reply-To: <90E19497-8D75-4EA1-B20B-446167D7A9C8@redhat.com>
References: <54BE1FBE.5000009@redhat.com>
	<931241687.10642175.1421747393477.JavaMail.zimbra@redhat.com>
	<90E19497-8D75-4EA1-B20B-446167D7A9C8@redhat.com>
Message-ID: <272658718.11145912.1421764737462.JavaMail.zimbra@redhat.com>

> We need defined APIs, that may result in common Java classes that e.g.
> describe one metric or a series of metrics for a tenant
> or similar.
>...
> Yes. I don't see this as a shared service/component, but rather part of
> Hawkular-alerts. This may pull in a common java
> class that encodes how a metric looks like (see above).

FWIW: we could base these on the JSON-encoded BasicMessage [1] - Jay has already prototyped his stuff using this, where a "metric" is JSON-encoded (and thus can be handled across any client in any language) but yet is a strongly-typed Java object that can be used.

[1] https://github.com/hawkular/hawkular-bus/blob/master/hawkular-bus-common/src/main/java/org/hawkular/bus/common/BasicMessage.java

From lponce at redhat.com  Tue Jan 20 09:49:31 2015
From: lponce at redhat.com (Lucas Ponce)
Date: Tue, 20 Jan 2015 09:49:31 -0500 (EST)
Subject: [Hawkular-dev] Should the components depend on the bus ?
In-Reply-To: <272658718.11145912.1421764737462.JavaMail.zimbra@redhat.com>
References: <54BE1FBE.5000009@redhat.com>
	<931241687.10642175.1421747393477.JavaMail.zimbra@redhat.com>
	<90E19497-8D75-4EA1-B20B-446167D7A9C8@redhat.com>
	<272658718.11145912.1421764737462.JavaMail.zimbra@redhat.com>
Message-ID: <1965276119.11185673.1421765371818.JavaMail.zimbra@redhat.com>

> > We need defined APIs, that may result in common Java classes that e.g.
> > describe one metric or a series of metrics for a tenant
> > or similar.
> >...
> > Yes. I don't see this as a shared service/component, but rather part of
> > Hawkular-alerts. This may pull in a common java
> > class that encodes how a metric looks like (see above).
> 
> FWIW: we could base these on the JSON-encoded BasicMessage [1] - Jay has
> already prototyped his stuff using this, where a "metric" is JSON-encoded
> (and thus can be handled across any client in any language) but yet is a
> strongly-typed Java object that can be used.
> 
> [1]
> https://github.com/hawkular/hawkular-bus/blob/master/hawkular-bus-common/src/main/java/org/hawkular/bus/common/BasicMessage.java

Yes, a PoC used that approach [1].

What I think (and I understand that it will be inferred from the APIs) it's the payload type like [2].

These classes I think they should live in a common package/artifact as it can be used per more than one component.

Or is the preferred approach is to use JSON as general payload inside the bus messages and convert it to concrete object inside the component ?




[1] https://github.com/lucasponce/rhq-alerts/blob/master/rhq-alerts/src/main/java/org/rhq/alerts/msg/common/MetricMessage.java

[2] https://github.com/lucasponce/rhq-alerts/blob/master/rhq-alerts/src/main/java/org/rhq/alerts/msg/common/SingleMetric.java


From hrupp at redhat.com  Tue Jan 20 09:55:36 2015
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Tue, 20 Jan 2015 15:55:36 +0100
Subject: [Hawkular-dev] Should the components depend on the bus ?
In-Reply-To: <8126276.y32jeLsonI@localhost.localdomain>
References: <54BE1FBE.5000009@redhat.com>
	<8126276.y32jeLsonI@localhost.localdomain>
Message-ID: <5371D4CB-5E05-4637-8647-832F59C67FA4@redhat.com>


> Am 20.01.2015 um 11:14 schrieb Lukas Krejci <lkrejci at redhat.com>:

> In that scenario, you will rarely encounter usecases where no communication 
> between the components is needed. Fabric1 have zookeeper for similar purpose, 
> kubernetes have etcd similarly, too.

Aren't zookeeper and etcd. distributed configuration databases and not meant to
replace a communication bus? My understanding is that you do not want to 
push incoming metrics in to ZK to later pull them off by other components like alerts.
ZK and etcd are afaiu registries, where a component can register itself and its
services and other components can look them up.

> the bus. Any change in the component API (or behavior!) would have to be 
> reflected in the glue, too. The glue would become the bottleneck or would be 
> massively harder to deploy in a distributed manner.

Yes about the former, not sure I understand the latter. With Java method
calls you also need to refactor all clients when a method signature changes.
With (REST) APIs you can offer multiple api versions in parallel on the receiver
side (through content negotiation) and still support old client versions while
in parallel offering new and enhanced services for newer client versions.




From mazz at redhat.com  Tue Jan 20 09:58:11 2015
From: mazz at redhat.com (John Mazzitelli)
Date: Tue, 20 Jan 2015 09:58:11 -0500 (EST)
Subject: [Hawkular-dev] Should the components depend on the bus ?
In-Reply-To: <1965276119.11185673.1421765371818.JavaMail.zimbra@redhat.com>
References: <54BE1FBE.5000009@redhat.com>
	<931241687.10642175.1421747393477.JavaMail.zimbra@redhat.com>
	<90E19497-8D75-4EA1-B20B-446167D7A9C8@redhat.com>
	<272658718.11145912.1421764737462.JavaMail.zimbra@redhat.com>
	<1965276119.11185673.1421765371818.JavaMail.zimbra@redhat.com>
Message-ID: <1989094085.11230125.1421765891201.JavaMail.zimbra@redhat.com>

> Or is the preferred approach is to use JSON as general payload inside the bus
> messages and convert it to concrete object inside the component ?

IMO, the preferred method is to use JSON as a general payload to open up the ability for clients to be non-Java based. Java clients/servers can use these Java objects as a "convenience" but as Jay and I have shown in our demos, utilizing JSON as the payload opens things up to being able to send and receive information via simple "curl" clients or other non-Java clients.

From jsanda at redhat.com  Tue Jan 20 11:35:51 2015
From: jsanda at redhat.com (John Sanda)
Date: Tue, 20 Jan 2015 11:35:51 -0500
Subject: [Hawkular-dev] embedding hawkular-metrics
Message-ID: <E57F3492-F4B8-49F7-9944-F5A968CC3012@redhat.com>

We already know from previous discussions that one of the use cases for metrics is embedding. There have been plenty of discussions with the WildFly team, notably with Heiko Braun, as well as discussions with the Fabric8 team about embedding metrics into their respective platforms. It has already been established that the dependency on JAX-RS prevents embedding the metrics UI components into the WildFly management console. Do we want to have a different, alternative stack for the embedded use case? An alternative stack would of course *not* depend on JAX-RS. It would maintain a smaller set of dependencies, and maybe more importantly it would require less and not more components/services from WildFly.

I like the idea of a small stack with minimal dependencies, but I do not necessarily like the idea of maintaining one stack for embedded and another stack for other use cases. In other words, I do not want to maintain two implementations of the REST endpoints. 

Thoughts?

From theute at redhat.com  Tue Jan 20 14:03:56 2015
From: theute at redhat.com (Thomas Heute)
Date: Tue, 20 Jan 2015 20:03:56 +0100
Subject: [Hawkular-dev] embedding hawkular-metrics
In-Reply-To: <E57F3492-F4B8-49F7-9944-F5A968CC3012@redhat.com>
References: <E57F3492-F4B8-49F7-9944-F5A968CC3012@redhat.com>
Message-ID: <54BEA69C.1080005@redhat.com>


On 01/20/2015 05:35 PM, John Sanda wrote:
> We already know from previous discussions that one of the use cases for metrics is embedding. There have been plenty of discussions with the WildFly team, notably with Heiko Braun, as well as discussions with the Fabric8 team about embedding metrics into their respective platforms. It has already been established that the dependency on JAX-RS prevents embedding the metrics UI components into the WildFly management console. Do we want to have a different, alternative stack for the embedded use case? An alternative stack would of course *not* depend on JAX-RS. It would maintain a smaller set of dependencies, and maybe more importantly it would require less and not more components/services from WildFly.
>
> I like the idea of a small stack with minimal dependencies, but I do not necessarily like the idea of maintaining one stack for embedded and another stack for other use cases. In other words, I do not want to maintain two implementations of the REST endpoints.
2 definitely sounds bad, what option do we have to maintain a unique one 
for both usecases ?

Thomas
>
> Thoughts?
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev


From jsanda at redhat.com  Tue Jan 20 15:31:03 2015
From: jsanda at redhat.com (John Sanda)
Date: Tue, 20 Jan 2015 15:31:03 -0500
Subject: [Hawkular-dev] Keycloak integration
In-Reply-To: <54B6766D.1010805@redhat.com>
References: <548196EE.30105@redhat.com> <549163D3.3070402@redhat.com>
	<5492F205.1000805@redhat.com> <5497EDDE.6060505@redhat.com>
	<5499573F.7050303@redhat.com> <54AA4D22.7020609@redhat.com>
	<DA7A4E9C-65C5-45FC-989F-DC8641D4A921@redhat.com>
	<54AE951D.4040408@redhat.com> <54B6766D.1010805@redhat.com>
Message-ID: <9E19AD42-AFAC-4BCE-8AD9-568C47AF769C@redhat.com>

Hi Juca,

For the dev environment, it looks like the keycloak appliance is used. Does it use an embedded h2 database or something similar? Will realms, user, and other auth info be persisted across restarts?

What are the steps for creating realms/users? I am thinking about after I do whatever is necessary to install/start the appliance and after I start the metrics server.

Is there a way to easily disable the authentication/authorization? While it is not critical, I am thinking it might be nice if we could do that in situations where we are debugging test failures for instance.

> On Jan 14, 2015, at 9:00 AM, Juraci Paix?o Kr?hling <jpkroehling at redhat.com> wrote:
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> I have collected some thoughts on this work created an "article" on
> the RHQ.next space.
> 
> If there are more details needed/wanted, I can expand it. I didn't
> want to put all the details there, otherwise "tl;dr" :-)
> 
> https://developer.jboss.org/wiki/KeycloakIntegration
> 
> - - Juca.
> 
> On 01/08/2015 03:33 PM, Juraci Paix?o Kr?hling wrote:
>> On 01/08/2015 12:40 PM, Heiko W.Rupp wrote:
>>> Also keep in mind that in the longer run we need to have a way
>>> of granting some access rights to GET /tenants/foo/metrics/bla
>>> from a user of tenant=acme.
>> 
>> This is pretty much the only part which is not done yet on the PR.
>> I can think of some solutions for that, but I'd wait until the
>> initial version is merged.
>> 
>> - Juca.
>> 
>> _______________________________________________ rhq-devel mailing
>> list rhq-devel at lists.fedorahosted.org 
>> https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
>> 
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
> 
> iQEcBAEBAgAGBQJUtnZtAAoJECKM1e+fkPrXJzQH/isLKuqKwG9XgO9MWO8hcxmz
> fbc1EpBbloifJOuQfN67SzrQ2lOrFyV3LB9q9o/vLHakhGGhM0eZIbadChKta60k
> MI02vppahpEp+pdW9aDnyr1dCyIbuecWikqPeyNPxCwfuhzYmAsFpUOwX3gUvtXN
> /s0qDXrJ1yOsMzW3fGnjOCLWs6BtXERCxxklfbTbxtPn0Y8YV5Bv2Z4oV9C+syIs
> kuGFMK3eTNA0OEQsqdQsAO2Tjd43I9Z0/9zpiaVtgRvIAm109Y/sBcOjS+AwNH2b
> rhCOm+7Rh9NNgIXAkVMPWXLXX4yWaxWtpzhm/6/jYw5t6Xmg/vHpYdWgqAfd2Z8=
> =SbsT
> -----END PGP SIGNATURE-----
> _______________________________________________
> rhq-devel mailing list
> rhq-devel at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/rhq-devel



From jsanda at redhat.com  Tue Jan 20 23:17:18 2015
From: jsanda at redhat.com (John Sanda)
Date: Tue, 20 Jan 2015 23:17:18 -0500
Subject: [Hawkular-dev] embedding hawkular-metrics
In-Reply-To: <54BEA69C.1080005@redhat.com>
References: <E57F3492-F4B8-49F7-9944-F5A968CC3012@redhat.com>
	<54BEA69C.1080005@redhat.com>
Message-ID: <26302928-D9C3-43E2-AD88-863097C0D3ED@redhat.com>


> On Jan 20, 2015, at 2:03 PM, Thomas Heute <theute at redhat.com> wrote:
> 
> 
> On 01/20/2015 05:35 PM, John Sanda wrote:
>> We already know from previous discussions that one of the use cases for metrics is embedding. There have been plenty of discussions with the WildFly team, notably with Heiko Braun, as well as discussions with the Fabric8 team about embedding metrics into their respective platforms. It has already been established that the dependency on JAX-RS prevents embedding the metrics UI components into the WildFly management console. Do we want to have a different, alternative stack for the embedded use case? An alternative stack would of course *not* depend on JAX-RS. It would maintain a smaller set of dependencies, and maybe more importantly it would require less and not more components/services from WildFly.
>> 
>> I like the idea of a small stack with minimal dependencies, but I do not necessarily like the idea of maintaining one stack for embedded and another stack for other use cases. In other words, I do not want to maintain two implementations of the REST endpoints.
> 2 definitely sounds bad, what option do we have to maintain a unique one for both usecases ?
> 

One option could be undertow core + json parser. I have not investigated enough to know what if any functionality we get/use from JAX-RS that we might need to implement on our own. We would need a JSON parser.

Another option could be netty + json parser. As with undertow, there may be some functionality we currently get/use from JAX-RS that we might need to implement on our own. One potential advantage of netty over undertow is the support for additional protocols. The Cassandra driver is also built on netty.

The last option I have thought about is vert.x 3.0. It looks like the minimum/core runtime dependencies are netty, jackson, log4j, and slf4j. This is pretty slim as well. It gives us higher level APIs  and support for implementing REST endpoints. We also have support for additional protocols since this is built on netty.

Note that none of these options are based on any of JEE. One of my primary considerations for this has been minimal dependencies.


- John

From jpkroehling at redhat.com  Wed Jan 21 02:24:43 2015
From: jpkroehling at redhat.com (=?UTF-8?B?SnVyYWNpIFBhaXjDo28gS3LDtmhsaW5n?=)
Date: Wed, 21 Jan 2015 08:24:43 +0100
Subject: [Hawkular-dev] Keycloak integration
In-Reply-To: <9E19AD42-AFAC-4BCE-8AD9-568C47AF769C@redhat.com>
References: <548196EE.30105@redhat.com>
	<549163D3.3070402@redhat.com>	<5492F205.1000805@redhat.com>
	<5497EDDE.6060505@redhat.com>	<5499573F.7050303@redhat.com>
	<54AA4D22.7020609@redhat.com>	<DA7A4E9C-65C5-45FC-989F-DC8641D4A921@redhat.com>	<54AE951D.4040408@redhat.com>
	<54B6766D.1010805@redhat.com>
	<9E19AD42-AFAC-4BCE-8AD9-568C47AF769C@redhat.com>
Message-ID: <54BF543B.2000607@redhat.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/20/2015 09:31 PM, John Sanda wrote:
> For the dev environment, it looks like the keycloak appliance is
> used. Does it use an embedded h2 database or something similar?
> Will realms, user, and other auth info be persisted across
> restarts?

Yes, it uses an embedded database and data is persisted across restarts.

> What are the steps for creating realms/users? I am thinking about
> after I do whatever is necessary to install/start the appliance and
> after I start the metrics server.

The usual way to create a realm is by logging in as admin on the
Keycloak console (/auth) and creating a realm from there. It's also
possible to import a realm during the server startup by passing a
system property pointing to the realm's JSON file (which is what we do
in the start.sh).

To create a regular user, you can just self-register. Once you access
the Hawkular's web console, you'll be redirected to a login screen. On
this screen, there's a "register" link. You can use it to register
yourself. To change the roles, you'll need to login to the Keycloak
web console as admin and add roles to your user.

> Is there a way to easily disable the authentication/authorization?
> While it is not critical, I am thinking it might be nice if we
> could do that in situations where we are debugging test failures
> for instance.

Yes: just remove the authentication parts on the web.xml . Everything
should work fine. Not sure, though, what would happen if you try to
call a resource that is protected by the container via @RolesAllowed.

- - Juca.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJUv1Q7AAoJECKM1e+fkPrXfFYIAJu06+Tg8suTU0pSWKbp8b1o
+ISU8htC3HXMMvXoE9dDqA3wQHPrChlN8sOwBciaQyLkv6RvM0EPfbxYQc6G6f25
2Ln0NM6tc7QVVgQYYcW+nIkbzWrX7cRpooPsqqM7KrWv7a5RUinhQWqNqky6VIPJ
oJQiwRUlpqzmeKMGhKtxWJwcEwyezKvVnwUp+c4VL1rSNxFJqqOItWfliWfxkS1s
Jzh/4WQt8QkoYtiuGxO3LwDsPNkfv/EQ3pYzWLYYNKKHmCzJNP8n+W+4P9QDZzLi
4MEBjcrwyRTi50x8mOUoPZKHdf3nh2MjVoHKdZaU36qnXejkf+i7zd372R+nogA=
=nkOZ
-----END PGP SIGNATURE-----

From hrupp at redhat.com  Wed Jan 21 04:52:35 2015
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Wed, 21 Jan 2015 10:52:35 +0100
Subject: [Hawkular-dev] embedding hawkular-metrics
In-Reply-To: <26302928-D9C3-43E2-AD88-863097C0D3ED@redhat.com>
References: <E57F3492-F4B8-49F7-9944-F5A968CC3012@redhat.com>
	<54BEA69C.1080005@redhat.com>
	<26302928-D9C3-43E2-AD88-863097C0D3ED@redhat.com>
Message-ID: <6B48C823-DC3B-4553-8460-C14F7149539C@redhat.com>


> Am 21.01.2015 um 05:17 schrieb John Sanda <jsanda at redhat.com>:
> 
> One option could be undertow core + json parser. I have not investigated enough to know what if any functionality we get/use from JAX-RS that we might need to implement on our own. We would need a JSON parser.

WildFly has afaik Jackson as mapper in its list of modules.

> 
> Another option could be netty + json parser. As with undertow, there may be some functionality we currently get/use from JAX-RS that we might need to implement on our own. One potential advantage of netty over undertow is the support for additional protocols. 

So we pull in (yet another version of) netty into WIldFly to workaround its existing Undertow http thingy?

> The Cassandra driver is also built on netty.
> 
> The last option I have thought about is vert.x 3.0. It looks like the minimum/core runtime dependencies are netty, jackson, log4j, and slf4j. This is pretty slim as well. It gives us higher level APIs  and support for implementing REST endpoints. We also have support for additional protocols since this is built on netty.



From tsegismo at redhat.com  Wed Jan 21 05:58:00 2015
From: tsegismo at redhat.com (Thomas Segismont)
Date: Wed, 21 Jan 2015 11:58:00 +0100
Subject: [Hawkular-dev] Should the components depend on the bus ?
In-Reply-To: <54BF85D0.10708@redhat.com>
References: <54BF85D0.10708@redhat.com>
Message-ID: <54BF8638.9050307@redhat.com>

Le 20/01/2015 11:14, Lukas Krejci a ?crit :
> But I don't think it is
> worth the effort to suppose that the components will primarily be used and
> deployed on their own - I think the opposite is true.

I think nobody expects the components to be primarily used on their own.

It may not be our team's priority to work on individual components
packaging or to promote them individually. But I believe it's worth the
effort to keep that kind of usage in mind before taking design
decisions. Otherwise it will quickly become hard to do, thus lowering
the chances for community to take over.




From tsegismo at redhat.com  Wed Jan 21 05:58:32 2015
From: tsegismo at redhat.com (Thomas Segismont)
Date: Wed, 21 Jan 2015 11:58:32 +0100
Subject: [Hawkular-dev] Should the components depend on the bus ?
In-Reply-To: <54BF85E2.4090902@redhat.com>
References: <54BF85E2.4090902@redhat.com>
Message-ID: <54BF8658.5060606@redhat.com>

Le 20/01/2015 13:56, Heiko W.Rupp a ?crit :
> If I understand you correctly, the question is about the api between bus ("JMS") and the
> components that so far have a REST-api and where it lives.
> If we try not to "pollute" the individual sub-projects with integration code, which makes a lot of
> sense, we probably need to easily define "bus-listeners" inside the bus module, that read
> a configuration (file) and know where to listen for events, how to invoke which rest-call and
> how to proceed with responses.

I like the idea



From tsegismo at redhat.com  Wed Jan 21 06:17:16 2015
From: tsegismo at redhat.com (Thomas Segismont)
Date: Wed, 21 Jan 2015 12:17:16 +0100
Subject: [Hawkular-dev] Should the components depend on the bus ?
In-Reply-To: <40158F3A-F571-40B4-81BC-3279D81D76CE@redhat.com>
References: <54BE1FBE.5000009@redhat.com>
	<40158F3A-F571-40B4-81BC-3279D81D76CE@redhat.com>
Message-ID: <54BF8ABC.70501@redhat.com>

Le 20/01/2015 13:56, Heiko W.Rupp a ?crit :
> Alerts on the other hand would also initiate requests, as e.g. the notification
> senders would be (micro) services on their own, so if an alert fires the alert
> engine would put a message on the bus to an alert notification sender to
> do its work.

+1 for alerts senders as a separate service, but like ptrans (standalone 
application). That woud make writing/working with sender extensions easier.

From tsegismo at redhat.com  Wed Jan 21 06:20:33 2015
From: tsegismo at redhat.com (Thomas Segismont)
Date: Wed, 21 Jan 2015 12:20:33 +0100
Subject: [Hawkular-dev] Keycloak integration
In-Reply-To: <54BF543B.2000607@redhat.com>
References: <548196EE.30105@redhat.com>	<549163D3.3070402@redhat.com>	<5492F205.1000805@redhat.com>	<5497EDDE.6060505@redhat.com>	<5499573F.7050303@redhat.com>	<54AA4D22.7020609@redhat.com>	<DA7A4E9C-65C5-45FC-989F-DC8641D4A921@redhat.com>	<54AE951D.4040408@redhat.com>	<54B6766D.1010805@redhat.com>	<9E19AD42-AFAC-4BCE-8AD9-568C47AF769C@redhat.com>
	<54BF543B.2000607@redhat.com>
Message-ID: <54BF8B81.8050408@redhat.com>

Le 21/01/2015 08:24, Juraci Paix?o Kr?hling a ?crit :
>> Is there a way to easily disable the authentication/authorization?
>> >While it is not critical, I am thinking it might be nice if we
>> >could do that in situations where we are debugging test failures
>> >for instance.
> Yes: just remove the authentication parts on the web.xml . Everything
> should work fine. Not sure, though, what would happen if you try to
> call a resource that is protected by the container via @RolesAllowed.

What does the KC team recommend to do for such problems (which are most 
probably shared across users)?

From hrupp at redhat.com  Wed Jan 21 06:37:39 2015
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Wed, 21 Jan 2015 12:37:39 +0100
Subject: [Hawkular-dev] Should the components depend on the bus ?
In-Reply-To: <54BF8ABC.70501@redhat.com>
References: <54BE1FBE.5000009@redhat.com>
	<40158F3A-F571-40B4-81BC-3279D81D76CE@redhat.com>
	<54BF8ABC.70501@redhat.com>
Message-ID: <5D3F4BBC-6B45-4C70-9564-EC1707FAD709@redhat.com>


> Am 21.01.2015 um 12:17 schrieb Thomas Segismont <tsegismo at redhat.com>:
> +1 for alerts senders as a separate service, but like ptrans (standalone 
> application). That woud make writing/working with sender extensions easier.

Can you elaborate more? What would be the benefit of implementing them as a separate
java process as opposed to e.g. a message driven bean listening on the bus?
How would standalone processes be used in a scenario where all of Hawkular is deployed
on one hardware and inside e.g. one WildFly server?




From jpkroehling at redhat.com  Wed Jan 21 08:32:03 2015
From: jpkroehling at redhat.com (=?windows-1252?Q?Juraci_Paix=E3o_Kr=F6hling?=)
Date: Wed, 21 Jan 2015 14:32:03 +0100
Subject: [Hawkular-dev] Keycloak integration
In-Reply-To: <54BF8B81.8050408@redhat.com>
References: <548196EE.30105@redhat.com>	<549163D3.3070402@redhat.com>	<5492F205.1000805@redhat.com>	<5497EDDE.6060505@redhat.com>	<5499573F.7050303@redhat.com>	<54AA4D22.7020609@redhat.com>	<DA7A4E9C-65C5-45FC-989F-DC8641D4A921@redhat.com>	<54AE951D.4040408@redhat.com>	<54B6766D.1010805@redhat.com>	<9E19AD42-AFAC-4BCE-8AD9-568C47AF769C@redhat.com>	<54BF543B.2000607@redhat.com>
	<54BF8B81.8050408@redhat.com>
Message-ID: <54BFAA53.3020107@redhat.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/21/2015 12:20 PM, Thomas Segismont wrote:
> Le 21/01/2015 08:24, Juraci Paix?o Kr?hling a ?crit :
>>> Is there a way to easily disable the
>>> authentication/authorization?
>>>> While it is not critical, I am thinking it might be nice if
>>>> we could do that in situations where we are debugging test
>>>> failures for instance.
>> Yes: just remove the authentication parts on the web.xml .
>> Everything should work fine. Not sure, though, what would happen
>> if you try to call a resource that is protected by the container
>> via @RolesAllowed.
> 
> What does the KC team recommend to do for such problems (which are
> most probably shared across users)?

Just had a quick chat with Marek about it and he suggested something
similar: to disable it via web.xml . There's no flag or special setup
that would allow an application otherwise protected by Keycloak to
bypass it, as it could be viewed as an attack vector.

One interesting thought that he shared was: if the application were to
be protected by any other JAAS provider, the auth would also have to
be disabled on web.xml . In that sense, I think that auth could be
counted on something that is part of the environment, like the
application server itself.

If we face a situation where disabling the auth is indeed valuable,
I'll try to come up with the flag that would accomplish that and see
if the Keycloak team would accept a PR.

- - Juca.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJUv6pTAAoJECKM1e+fkPrXUxUH/1i0naSA6XfYavsCyINLlfR4
C3vB3IWpDtMkEX4lsbt6J7EI0EKpZty7Up5OeaQhngHueIUyVqPRVBUn/PZmCdqD
PdmraLzv9+3aPtcPavT3uVZqpMgeJ9l+BjQW+z/ouj/VMwTkz/X6u2/Eim6ZzX4B
364R5KWxnZkLIftgOreACqTRlVLn5ErPTP1jSE58o7cXjbAb5EARXareXVWHOtdE
2SjtBBdO9xYVfPm37+CD7FnRl/s00e+DHFaDHWDqHm1D+uuCTR6zm81KO8Dcg855
e5hFtybRYaSStmjwOJFDJ+D7wtPJXzjgtpjAoM3PhDx6VjslVXoJJjkfVJPft20=
=fKcB
-----END PGP SIGNATURE-----

From jsanda at redhat.com  Wed Jan 21 08:33:05 2015
From: jsanda at redhat.com (John Sanda)
Date: Wed, 21 Jan 2015 08:33:05 -0500
Subject: [Hawkular-dev] embedding hawkular-metrics
In-Reply-To: <6B48C823-DC3B-4553-8460-C14F7149539C@redhat.com>
References: <E57F3492-F4B8-49F7-9944-F5A968CC3012@redhat.com>
	<54BEA69C.1080005@redhat.com>
	<26302928-D9C3-43E2-AD88-863097C0D3ED@redhat.com>
	<6B48C823-DC3B-4553-8460-C14F7149539C@redhat.com>
Message-ID: <8CAA4BB8-AC20-4FF2-9488-437A8A051B63@redhat.com>


> On Jan 21, 2015, at 4:52 AM, Heiko W.Rupp <hrupp at redhat.com> wrote:
> 
> 
>> Am 21.01.2015 um 05:17 schrieb John Sanda <jsanda at redhat.com>:
>> 
>> One option could be undertow core + json parser. I have not investigated enough to know what if any functionality we get/use from JAX-RS that we might need to implement on our own. We would need a JSON parser.
> 
> WildFly has afaik Jackson as mapper in its list of modules.

I do not see it in WF Core 8.2.0.Final. I have not checked more recent versions WF Core though.

> 
>> 
>> Another option could be netty + json parser. As with undertow, there may be some functionality we currently get/use from JAX-RS that we might need to implement on our own. One potential advantage of netty over undertow is the support for additional protocols. 
> 
> So we pull in (yet another version of) netty into WIldFly to workaround its existing Undertow http thingy?

The issue here is not trying to work around undertow. The issue is that hawkular-metrics currently requires more than  WF Core to be embedded in WF. If I understand correctly, it would be find if our solution requires dependencies X, Z provided they remain implementation details and can be packaged up as a module because then it WF Core would just require that additional module instead as opposed to more WF services. With that said, it will be easier to embed in general with fewer dependencies.

With respect to netty, we already require it for the Cassandra driver. I think it would make sense for metrics and the driver to use the same version. Then we are not pulling in yet another version.

> 
>> The Cassandra driver is also built on netty.
>> 
>> The last option I have thought about is vert.x 3.0. It looks like the minimum/core runtime dependencies are netty, jackson, log4j, and slf4j. This is pretty slim as well. It gives us higher level APIs  and support for implementing REST endpoints. We also have support for additional protocols since this is built on netty.
> 



From mazz at redhat.com  Wed Jan 21 09:33:11 2015
From: mazz at redhat.com (John Mazzitelli)
Date: Wed, 21 Jan 2015 09:33:11 -0500 (EST)
Subject: [Hawkular-dev] embedding hawkular-metrics
In-Reply-To: <8CAA4BB8-AC20-4FF2-9488-437A8A051B63@redhat.com>
References: <E57F3492-F4B8-49F7-9944-F5A968CC3012@redhat.com>
	<54BEA69C.1080005@redhat.com>
	<26302928-D9C3-43E2-AD88-863097C0D3ED@redhat.com>
	<6B48C823-DC3B-4553-8460-C14F7149539C@redhat.com>
	<8CAA4BB8-AC20-4FF2-9488-437A8A051B63@redhat.com>
Message-ID: <702766969.12298673.1421850791271.JavaMail.zimbra@redhat.com>

> >> might need to implement on our own. We would need a JSON parser.

Google's GSON?  That's what h-bus is using. Or do you need something more?

From miburman at redhat.com  Wed Jan 21 09:35:57 2015
From: miburman at redhat.com (Michael Burman)
Date: Wed, 21 Jan 2015 16:35:57 +0200
Subject: [Hawkular-dev] embedding hawkular-metrics
In-Reply-To: <8CAA4BB8-AC20-4FF2-9488-437A8A051B63@redhat.com>
References: <E57F3492-F4B8-49F7-9944-F5A968CC3012@redhat.com>	<54BEA69C.1080005@redhat.com>	<26302928-D9C3-43E2-AD88-863097C0D3ED@redhat.com>	<6B48C823-DC3B-4553-8460-C14F7149539C@redhat.com>
	<8CAA4BB8-AC20-4FF2-9488-437A8A051B63@redhat.com>
Message-ID: <54BFB94D.7090408@redhat.com>

On 21.01.2015 15:33, John Sanda wrote:
> I do not see it in WF Core 8.2.0.Final. I have not checked more recent 
> versions WF Core though. 

There's no JSON parser in the wildfly-core as far as I can see. 
wildfly/pom.xml includes jackson2. It is however used in some of the 
examples done by the Undertow group (such as the performance race, where 
there is a JSONHandler). Hardly a complex task.

   - Micke

From tsegismo at redhat.com  Wed Jan 21 09:43:36 2015
From: tsegismo at redhat.com (Thomas Segismont)
Date: Wed, 21 Jan 2015 15:43:36 +0100
Subject: [Hawkular-dev] Should the components depend on the bus ?
In-Reply-To: <5D3F4BBC-6B45-4C70-9564-EC1707FAD709@redhat.com>
References: <54BE1FBE.5000009@redhat.com>	<40158F3A-F571-40B4-81BC-3279D81D76CE@redhat.com>	<54BF8ABC.70501@redhat.com>
	<5D3F4BBC-6B45-4C70-9564-EC1707FAD709@redhat.com>
Message-ID: <54BFBB18.2040905@redhat.com>

Le 21/01/2015 12:37, Heiko W.Rupp a ?crit :
>> +1 for alerts senders as a separate service, but like ptrans (standalone
>> application). That woud make writing/working with sender extensions easier.
>
> Can you elaborate more? What would be the benefit of implementing them as a separate
> java process as opposed to e.g. a message driven bean listening on the bus?

It sounds like I misunderstood your sentence: "Alerts on the other hand 
would also initiate requests, as e.g. the notification
senders would be (micro) services on their own".
I believed you were arguing in favor of notification senders in their 
own process.

If notifications senders are alone in a standalone Java application, 
then sender extension model can be made easy: we make a sender base 
which takes care of listening to the bus and users write simple Sender 
classes (almost like in RHQ.classic).

> How would standalone processes be used in a scenario where all of Hawkular is deployed
> on one hardware and inside e.g. one WildFly server?

On one physical or virtual server, it's not a problem.

Inside a Wildfly server, we could repackage the sender base and 
extension as a WAR and let the container start it.



If notification extensions must be message driven beans, how can you 
make use of them outside a JavaEE container?

From jsanda at redhat.com  Wed Jan 21 11:36:20 2015
From: jsanda at redhat.com (John Sanda)
Date: Wed, 21 Jan 2015 11:36:20 -0500
Subject: [Hawkular-dev] embedding hawkular-metrics
In-Reply-To: <54BFB94D.7090408@redhat.com>
References: <E57F3492-F4B8-49F7-9944-F5A968CC3012@redhat.com>
	<54BEA69C.1080005@redhat.com>
	<26302928-D9C3-43E2-AD88-863097C0D3ED@redhat.com>
	<6B48C823-DC3B-4553-8460-C14F7149539C@redhat.com>
	<8CAA4BB8-AC20-4FF2-9488-437A8A051B63@redhat.com>
	<54BFB94D.7090408@redhat.com>
Message-ID: <E5AC4815-83E1-45DA-BBBE-61F0298E1B64@redhat.com>


> On Jan 21, 2015, at 9:35 AM, Michael Burman <miburman at redhat.com> wrote:
> 
> On 21.01.2015 15:33, John Sanda wrote:
>> I do not see it in WF Core 8.2.0.Final. I have not checked more recent 
>> versions WF Core though. 
> 
> There's no JSON parser in the wildfly-core as far as I can see. 
> wildfly/pom.xml includes jackson2. It is however used in some of the 
> examples done by the Undertow group (such as the performance race, where 
> there is a JSONHandler). Hardly a complex task.
> 

I don?t think particular json parser is too important for the discussion. The issue is embedding in WF currently requires deploying additional WF services above and beyond what is in WF core. Whether we use jackson, gson, or something else will not require additional WF services. The parser will be a self-contained dependency.

From hbraun at redhat.com  Wed Jan 21 13:47:57 2015
From: hbraun at redhat.com (Heiko Braun)
Date: Wed, 21 Jan 2015 19:47:57 +0100
Subject: [Hawkular-dev] embedding hawkular-metrics
In-Reply-To: <8CAA4BB8-AC20-4FF2-9488-437A8A051B63@redhat.com>
References: <E57F3492-F4B8-49F7-9944-F5A968CC3012@redhat.com>
	<54BEA69C.1080005@redhat.com>
	<26302928-D9C3-43E2-AD88-863097C0D3ED@redhat.com>
	<6B48C823-DC3B-4553-8460-C14F7149539C@redhat.com>
	<8CAA4BB8-AC20-4FF2-9488-437A8A051B63@redhat.com>
Message-ID: <03016ABE-ACE5-4356-A733-09E621215EB2@redhat.com>


> On 21 Jan 2015, at 14:33, John Sanda <jsanda at redhat.com <mailto:jsanda at redhat.com>> wrote:
> 
> The issue here is not trying to work around undertow. The issue is that hawkular-metrics currently requires more than WF Core to be embedded in WF. If I understand correctly, it would be find if our solution requires dependencies X, Z provided they remain implementation details and can be packaged up as a module because then it WF Core would just require that additional module instead as opposed to more WF services. With that said, it will be easier to embed in general with fewer dependencies.

yes, both undertow and netty fall into this category. undertow has the benfit of being present in WF already. Netty on the other hand was brought to the table, because it has more out-of-the-box protocols. Not sure if that?s needed though. 
 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20150121/570f8eed/attachment.html 

From hbraun at redhat.com  Wed Jan 21 15:04:26 2015
From: hbraun at redhat.com (Heiko Braun)
Date: Wed, 21 Jan 2015 21:04:26 +0100
Subject: [Hawkular-dev] embedding hawkular-metrics
In-Reply-To: <03016ABE-ACE5-4356-A733-09E621215EB2@redhat.com>
References: <E57F3492-F4B8-49F7-9944-F5A968CC3012@redhat.com>
	<54BEA69C.1080005@redhat.com>
	<26302928-D9C3-43E2-AD88-863097C0D3ED@redhat.com>
	<6B48C823-DC3B-4553-8460-C14F7149539C@redhat.com>
	<8CAA4BB8-AC20-4FF2-9488-437A8A051B63@redhat.com>
	<03016ABE-ACE5-4356-A733-09E621215EB2@redhat.com>
Message-ID: <EB3F635A-0904-4374-A950-24A293105C58@redhat.com>

Some additional information regarding the wildfly integration and the rest interface in particular:

Any subsystem in wildfly can register an undertow HTTP handler or an undertow HTTP upgrade handler. The HTTP handler exposes the regular undertow API for building HTTP based endpoints [1]. This one should be straight forward to use for implementing the REST interface you currently have in rhq-metrics. 

The upgrade handler on the other hand does HTTP upgrade to a custom protocol of your choice (if needed in the future). It can as well be used to provide web socket based access to your services.

Taking into consideration that undertow can also be easily embedded [2]  I think this covers a lot of ground.

Regards, Heiko

[1] http://undertow.io/documentation/core/undertow-handler-guide.html <http://undertow.io/documentation/core/undertow-handler-guide.html>
[2] http://undertow.io/documentation/core/bootstrapping.html




 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20150121/0205d0cb/attachment-0001.html 

From mithomps at redhat.com  Wed Jan 21 21:07:52 2015
From: mithomps at redhat.com (mike thompson)
Date: Wed, 21 Jan 2015 18:07:52 -0800
Subject: [Hawkular-dev] UI Dev Changes (typescript version change from 1.3.0
	to 1.4.1)
Message-ID: <168B9323-45C9-41F0-A07B-11C933C9215F@redhat.com>

If you are doing UI work in hawkular(rhq-metrics right now), the version of typescript has been bumped to version 1.4.1. This is reflected in the build so nothing is needed to be done. However, if you are doing UI dev work then you should update the version of typescript so that your IDE will pick up the new version. As a first step, I have changed the version but not added any typescript 1.4.1 syntax changes to minimize change as a first step. Syntax additions will find their way into the codebase soon though.

To check which version you are using use ?tsc ?version?. If you are using npm to load typescript you can use the command ?npm update typescript -g? to update to the new version.

? Mike



From hrupp at redhat.com  Thu Jan 22 05:06:10 2015
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Thu, 22 Jan 2015 11:06:10 +0100
Subject: [Hawkular-dev] Roles and Permissions in Hawkular
Message-ID: <D5D2AC2A-6413-4814-9E12-EC0AAE42AC11@redhat.com>

Hey,

one thing that we did not touch yet, but we probably should are user roles and their permissions.

The driver for me here is that the current rhq-metrics rest api offers endpoints to upload and retrieve (metric) data,
but also to modify (meta)meta data like the retention period of metrics. This is something I consider as more
restrictive, as you don't want arbitrary feeds to just set the retention period to 10years without anyone noticing.
There are probably other endpoints (in existing rhq-metrics) that need more elevated rights as well.
Same applies of course for the more overall Hawkular project.

We are trying to (conceptually) align with what WildFly offers (at least on the role side), so that users who know one, also feel at home with the other. There are obvious differences though with what RHQ has been offering for a long time (even before AS7).
Not only from the fact that expect to "superuser" no roles are built in, but also in the fact that the assignment of role to resource is not "direct", but done via resource groups, that can be composed on the fly.
See e.g. the first part of https://developer.jboss.org/community/rhq/next/blog/2014/11/11/thoughts-on-tenants-for-rhqnext  for a quick intro into that.
Current RHQ RBAC also has shortcomings where the WildFly one is better (and still, there may be some more fine grained permissions needed). E.g. we have so called "operations" (a lot like the operations on WildFly resources), where we are not
able to differentiate between "harmless" show-xyz operations and more sensitive "reboot box X" ones

From Brian Stansberry:
---
WildFly RBAC isn't heavily based on resource assignment. It's about assigning different constraints to roles and then providing information about the actions users want to take and the resource/attribute/operation involved and seeing if the constraints are met.

The answers as to whether a constraint is violated don't generally fall along resource lines. The main constraints:

1) Is it a read or a write. Presumably dealing this kind of thing won't be an issue with any authorization scheme. :)

2) Does a write affect persistent configuration? This often depends on the particular attribute/operation, not the resource. Perhaps it's not so critical though.

3) Is the resource/attribute/operation configured as security sensitive? This is the key one and it doesn't map cleanly to resource assignment, since individual attributes can be sensitive while the overall resource is not, and different classifications of security sensitive can differ as to whether reads and writes are both sensitive, or just writes.
---

Anyway: we need to start tagging endpoints with information about access levels so that we can enforce them by different policies. Those policies should probably not only take the user + credentials into account, but also the origin of requests, as for the above example, a request coming from the same machine or e.g. the Hawkular-glue may be treated differently than one coming from some random dump feed on the internet.

Note, that those access levels usually do not replace authentication (via KeyCloak), but are applied after successful authentication and probably role assignment.
Depending on the use case (embedded Hawkular-metrics, Standalone Hawkular-Metrics, Standalone Hawkular) the
check points may be at different places, or we decide to e.g. always enforce at the component boundary.

The following two drawings should illustrate this



The green circle illustrates the "check being at java-level" on the standalone side,
which also would still work for the embedded case when the rest-api is replaced
by some other implementation.



For the Hawkular server, we  could move the check earlier e.g at the message-gw.
Or just pass the additional information (origin, ...) on the message on the bus and 
then keep the checks at Hawkular-metrics core as in above case.

  Heiko




-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20150122/929af2e7/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sec1.png
Type: image/png
Size: 15983 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/hawkular-dev/attachments/20150122/929af2e7/attachment-0002.png 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sec2.png
Type: image/png
Size: 19072 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/hawkular-dev/attachments/20150122/929af2e7/attachment-0003.png 

From jpkroehling at redhat.com  Thu Jan 22 05:22:28 2015
From: jpkroehling at redhat.com (=?UTF-8?B?SnVyYWNpIFBhaXjDo28gS3LDtmhsaW5n?=)
Date: Thu, 22 Jan 2015 11:22:28 +0100
Subject: [Hawkular-dev] Demo about the Keycloak integration
Message-ID: <54C0CF64.5090108@redhat.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

All,

As mentioned yesterday on the IRC channel, I'll be doing a demo
tomorrow (Friday) at 16:00 UTC about the Keycloak integration.

The topics will be mostly around what I've described on the wiki
page[1] but I'll also show some code to explain where the changes are
and how to use it.

1 - https://developer.jboss.org/wiki/KeycloakIntegration

Around 15:50 UTC I'll be sending the link to the conference, which
will probably take place as a Google Hangout, unless someone has
objections.

- - Juca.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJUwM9jAAoJECKM1e+fkPrXdYgH/iUkPUy+IailX3+bPg1n8P4X
8iigT8Csgv9qf+qihUzf0p34VCq4J9IKo6DVdoO5OPET7GAuUQq65GEGzFRKeFpO
W5vccLOu4YzzqIDG/sg4SAHc4t0r5Qnz7pBY4ZZvyqj/dRPpObE9beJPf5y97UK2
8UZz9qpVD8PbhTntAT3glaD62qwH6cD5lyONNgZzaEysvNIZ9eXgoo1X20sDrerb
lswPNXickPim/h/R1Fql3JFWwejsUETvXilH0eDTk0WM+xyvadnYP+GyxGwbMT9g
SAFjCOAXTErwg00lLMLHXqLkNk6QNGCrfCEh2GcA6bTIFy/EK7AM8rAJ0V0/aTA=
=FT3o
-----END PGP SIGNATURE-----

From theute at redhat.com  Thu Jan 22 06:14:51 2015
From: theute at redhat.com (Thomas Heute)
Date: Thu, 22 Jan 2015 12:14:51 +0100
Subject: [Hawkular-dev] Demo about the Keycloak integration
In-Reply-To: <54C0CF64.5090108@redhat.com>
References: <54C0CF64.5090108@redhat.com>
Message-ID: <54C0DBAB.4010200@redhat.com>

Make it a recorded Hawkular Google Hangout Air if possible:
https://plus.google.com/u/0/b/100667078659222571663/100667078659222571663/about

Let's use this as an attempt, would be good to share demos more often 
later about Hawkular.

If you have issues, fallback to regular Hangout.

Thomas



On 01/22/2015 11:22 AM, Juraci Paix?o Kr?hling wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> All,
>
> As mentioned yesterday on the IRC channel, I'll be doing a demo
> tomorrow (Friday) at 16:00 UTC about the Keycloak integration.
>
> The topics will be mostly around what I've described on the wiki
> page[1] but I'll also show some code to explain where the changes are
> and how to use it.
>
> 1 - https://developer.jboss.org/wiki/KeycloakIntegration
>
> Around 15:50 UTC I'll be sending the link to the conference, which
> will probably take place as a Google Hangout, unless someone has
> objections.
>
> - - Juca.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
>
> iQEcBAEBAgAGBQJUwM9jAAoJECKM1e+fkPrXdYgH/iUkPUy+IailX3+bPg1n8P4X
> 8iigT8Csgv9qf+qihUzf0p34VCq4J9IKo6DVdoO5OPET7GAuUQq65GEGzFRKeFpO
> W5vccLOu4YzzqIDG/sg4SAHc4t0r5Qnz7pBY4ZZvyqj/dRPpObE9beJPf5y97UK2
> 8UZz9qpVD8PbhTntAT3glaD62qwH6cD5lyONNgZzaEysvNIZ9eXgoo1X20sDrerb
> lswPNXickPim/h/R1Fql3JFWwejsUETvXilH0eDTk0WM+xyvadnYP+GyxGwbMT9g
> SAFjCOAXTErwg00lLMLHXqLkNk6QNGCrfCEh2GcA6bTIFy/EK7AM8rAJ0V0/aTA=
> =FT3o
> -----END PGP SIGNATURE-----
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev


From jsanda at redhat.com  Thu Jan 22 15:48:48 2015
From: jsanda at redhat.com (John Sanda)
Date: Thu, 22 Jan 2015 15:48:48 -0500
Subject: [Hawkular-dev] embedding hawkular-metrics
In-Reply-To: <EB3F635A-0904-4374-A950-24A293105C58@redhat.com>
References: <E57F3492-F4B8-49F7-9944-F5A968CC3012@redhat.com>
	<54BEA69C.1080005@redhat.com>
	<26302928-D9C3-43E2-AD88-863097C0D3ED@redhat.com>
	<6B48C823-DC3B-4553-8460-C14F7149539C@redhat.com>
	<8CAA4BB8-AC20-4FF2-9488-437A8A051B63@redhat.com>
	<03016ABE-ACE5-4356-A733-09E621215EB2@redhat.com>
	<EB3F635A-0904-4374-A950-24A293105C58@redhat.com>
Message-ID: <64BEBA7A-BC54-46DA-8911-660B9871E4B4@redhat.com>

On Jan 21, 2015, at 3:04 PM, Heiko Braun <hbraun at redhat.com> wrote:
> 
> Some additional information regarding the wildfly integration and the rest interface in particular:
> 
> Any subsystem in wildfly can register an undertow HTTP handler or an undertow HTTP upgrade handler. The HTTP handler exposes the regular undertow API for building HTTP based endpoints [1]. This one should be straight forward to use for implementing the REST interface you currently have in rhq-metrics. 
> 
> The upgrade handler on the other hand does HTTP upgrade to a custom protocol of your choice (if needed in the future). It can as well be used to provide web socket based access to your services.
> 
> Taking into consideration that undertow can also be easily embedded [2]  I think this covers a lot of ground.
> 
> Regards, Heiko
> 
> [1] http://undertow.io/documentation/core/undertow-handler-guide.html <http://undertow.io/documentation/core/undertow-handler-guide.html>
> [2] http://undertow.io/documentation/core/bootstrapping.html <http://undertow.io/documentation/core/bootstrapping.html>
> 

Thanks for the info Heiko. Here is what we need to figure out. Provided that all of the business logic resides in the core service, would the amount of work involved with building another implementation with undertow be small enough that it would be worth have the two implementations. If the amount of work is small, would this be something you (and by you I basically mean the WF team) would be comfortable owning?

One thing that comes to mind is the keycloak integration. I am not how much effort/duplication would be involved. If it does look like it will be a lot of effort and/or duplication, then we really need to consider a more minimal stack without JAX-RS.

I have another, somewhat related question. The LiveOak project is also working with hawkular-metrics. I think that they are deploying the metrics war side by side with their stuff. If we wind up with a more minimal implementation as you describe, how would that work with LiveOak which is ok with consuming a war since they are running in a server that already has war deployments, JAX-RS, etc.?

- John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20150122/c78f828e/attachment.html 

From ppalaga at redhat.com  Fri Jan 23 10:01:46 2015
From: ppalaga at redhat.com (Peter Palaga)
Date: Fri, 23 Jan 2015 16:01:46 +0100
Subject: [Hawkular-dev] How to work with the license plugin
Message-ID: <54C2625A.3070006@redhat.com>

Hi *,

Have you ever updated the copyright range after you changed a file?

To spare us from the tedious manual work and to bring in consistency and 
standards required by Red Hat Legal dept., the license plugin was 
recently included [1] in metrics. Other projects will follow soon.

Here here is a couple of recommendations how to work with the plugin:

(1) Having the file templates up to date in your IDE can save you some work

  git clone  https://github.com/hawkular/hawkular-build-tools.git
  cd hawkular-build-tools/ide-configs

... and import what is there. If your IDE is not supported, you are 
welcome to contribute a configuration. Nevertheless, one can work 
without an IDE support, see (2).

(2) The license plugin is able to add/fix licenses as necessary. Just invoke

    mvn license:format

in the root of your project (assuming license plugin is configured in 
the pom hierarchy.)

(3) The license:check goal is now bound to validation phase in metrics. 
It can make your build fail. If you want to avoid the checks for any 
reason (reduce build time, known temporary inconsistencies, ...) feel 
free to build with

   -Dlicense.failOnMissing=false

But note that Travis will fail if you push files that do not meet the 
standards.

(4) From my sustaining engineer's experience, I can say that it is often 
handy to have non-code changes in separate commits. This holds not only 
for code formatting but also for copyright range updates. Please keep 
them separate if possible.
A typical workflow might look like this:
   (i) code, build with -Dlicense.failOnMissing=false, commit
       as many times as you need
   (ii) mvn license:format; git commit -m "License headers added or
        fixed"
   (iii) git push ... ; hub pull-request ...

Thanks,

Peter

[1] https://github.com/rhq-project/rhq-metrics/pull/132

From tsegismo at redhat.com  Fri Jan 23 10:42:02 2015
From: tsegismo at redhat.com (Thomas Segismont)
Date: Fri, 23 Jan 2015 16:42:02 +0100
Subject: [Hawkular-dev] How to work with the license plugin
In-Reply-To: <54C2625A.3070006@redhat.com>
References: <54C2625A.3070006@redhat.com>
Message-ID: <54C26BCA.5050500@redhat.com>

Thanks for sharing this Peter

Le 23/01/2015 16:01, Peter Palaga a ?crit :
> Hi *,
>
> Have you ever updated the copyright range after you changed a file?
>
> To spare us from the tedious manual work and to bring in consistency and
> standards required by Red Hat Legal dept., the license plugin was
> recently included [1] in metrics. Other projects will follow soon.
>
> Here here is a couple of recommendations how to work with the plugin:
>
> (1) Having the file templates up to date in your IDE can save you some work
>
>    git clone  https://github.com/hawkular/hawkular-build-tools.git
>    cd hawkular-build-tools/ide-configs
>
> ... and import what is there. If your IDE is not supported, you are
> welcome to contribute a configuration. Nevertheless, one can work
> without an IDE support, see (2).
>
> (2) The license plugin is able to add/fix licenses as necessary. Just invoke
>
>      mvn license:format
>
> in the root of your project (assuming license plugin is configured in
> the pom hierarchy.)
>
> (3) The license:check goal is now bound to validation phase in metrics.
> It can make your build fail. If you want to avoid the checks for any
> reason (reduce build time, known temporary inconsistencies, ...) feel
> free to build with
>
>     -Dlicense.failOnMissing=false
>
> But note that Travis will fail if you push files that do not meet the
> standards.
>
> (4) From my sustaining engineer's experience, I can say that it is often
> handy to have non-code changes in separate commits. This holds not only
> for code formatting but also for copyright range updates. Please keep
> them separate if possible.
> A typical workflow might look like this:
>     (i) code, build with -Dlicense.failOnMissing=false, commit
>         as many times as you need
>     (ii) mvn license:format; git commit -m "License headers added or
>          fixed"
>     (iii) git push ... ; hub pull-request ...
>
> Thanks,
>
> Peter
>
> [1] https://github.com/rhq-project/rhq-metrics/pull/132
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>


From ppalaga at redhat.com  Fri Jan 23 12:31:14 2015
From: ppalaga at redhat.com (Peter Palaga)
Date: Fri, 23 Jan 2015 18:31:14 +0100
Subject: [Hawkular-dev] How to work with the license plugin
In-Reply-To: <54C26BCA.5050500@redhat.com>
References: <54C2625A.3070006@redhat.com> <54C26BCA.5050500@redhat.com>
Message-ID: <54C28562.9090300@redhat.com>

A minor correction: to build faster ignoring known inconsistencies, 
building with

   -Dlicense.skip=true

is even better than -Dlicense.failOnMissing=false
-- P

On 01/23/2015 04:42 PM, Thomas Segismont wrote:
> Thanks for sharing this Peter
>
> Le 23/01/2015 16:01, Peter Palaga a ?crit :
>> Hi *,
>>
>> Have you ever updated the copyright range after you changed a file?
>>
>> To spare us from the tedious manual work and to bring in consistency and
>> standards required by Red Hat Legal dept., the license plugin was
>> recently included [1] in metrics. Other projects will follow soon.
>>
>> Here here is a couple of recommendations how to work with the plugin:
>>
>> (1) Having the file templates up to date in your IDE can save you some work
>>
>>     git clone  https://github.com/hawkular/hawkular-build-tools.git
>>     cd hawkular-build-tools/ide-configs
>>
>> ... and import what is there. If your IDE is not supported, you are
>> welcome to contribute a configuration. Nevertheless, one can work
>> without an IDE support, see (2).
>>
>> (2) The license plugin is able to add/fix licenses as necessary. Just invoke
>>
>>       mvn license:format
>>
>> in the root of your project (assuming license plugin is configured in
>> the pom hierarchy.)
>>
>> (3) The license:check goal is now bound to validation phase in metrics.
>> It can make your build fail. If you want to avoid the checks for any
>> reason (reduce build time, known temporary inconsistencies, ...) feel
>> free to build with
>>
>>      -Dlicense.failOnMissing=false
>>
>> But note that Travis will fail if you push files that do not meet the
>> standards.
>>
>> (4) From my sustaining engineer's experience, I can say that it is often
>> handy to have non-code changes in separate commits. This holds not only
>> for code formatting but also for copyright range updates. Please keep
>> them separate if possible.
>> A typical workflow might look like this:
>>      (i) code, build with -Dlicense.failOnMissing=false, commit
>>          as many times as you need
>>      (ii) mvn license:format; git commit -m "License headers added or
>>           fixed"
>>      (iii) git push ... ; hub pull-request ...
>>
>> Thanks,
>>
>> Peter
>>
>> [1] https://github.com/rhq-project/rhq-metrics/pull/132
>> _______________________________________________
>> 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 jpkroehling at redhat.com  Fri Jan 23 12:32:06 2015
From: jpkroehling at redhat.com (=?UTF-8?B?SnVyYWNpIFBhaXjDo28gS3LDtmhsaW5n?=)
Date: Fri, 23 Jan 2015 18:32:06 +0100
Subject: [Hawkular-dev] Outcome of Keycloak Demo
Message-ID: <54C28596.2060909@redhat.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

All,

We had today our Keycloak Demo and I'd like to thank everyone who
joined. It was a very nice experience.

During the hangout, a few points were raised:

1) Would it be possible/desirable to make the Keycloak integration
optional?

2) Would it be possible to not use the Keycloak appliance
distribution, using Wildfly instead?

For the first question, I'll open a new thread to discuss it.

About the second, I'm going to work on the start.sh script next week
and do it. The main advantage is that we'll have a place where the
final users can use as reference in setting up their environment, and
having Wildfly as start base is more comfortable than having Keycloak
Appliance, even though the final outcome is the same (ie: Wildfly +
Keycloak server + Keycloak adapters = Keycloak Appliance).

Once again, I encourage you to try out the branch and see if you find
any problems that I might have not seen.

Best,
Juca.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJUwoWWAAoJECKM1e+fkPrXpVMH/0R7TdQ59IgGBby4QCCzxUVS
IbAdC4+35b3nVF9306uekj2xBJu9i/Dj1ixp4KGeeQXOLVWVKIt1SLOO+1vXnG3a
2nDWfmTLuqm387tVhp8yNLj2e7I+JyQBNsBC1CAsLZUS1EWzlQ6/p2zy8r8LzH3X
myVbiZg68LchHQiJMCa0ZF9i0pV+TuZXVYahuYFofmrwGsu+fTH2212XYPCtTaQB
BRtytP6BE3Dm6X38zJYHeZJTADrP9ySNpk4ghxZ69EnVVbG0wfDPi49JRq5jI0ff
l6WvhNBv+eQYOxcSY7Rjmw/+khgJpRr/jKci1zAkQ82mxFb9OpbxVnyYKnVX4xs=
=rJGL
-----END PGP SIGNATURE-----

From jpkroehling at redhat.com  Fri Jan 23 12:54:42 2015
From: jpkroehling at redhat.com (=?UTF-8?B?SnVyYWNpIFBhaXjDo28gS3LDtmhsaW5n?=)
Date: Fri, 23 Jan 2015 18:54:42 +0100
Subject: [Hawkular-dev] Should Keycloak integration be optional?
Message-ID: <54C28AE2.3010509@redhat.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

As I mentioned on the previous email, one of the questions during the
demo was if it would be possible to have the Keycloak integration as
an optional part.

In the backend part, it's not hard to disable Keycloak as the
authentication mechanism, as it's just JAAS. That would require,
though, a second JAAS implementation to replace it.

In the frontend part, however, it's a bit more complicated. The setup
right now is that the web console is treated as an HTML5 single-page
app. This means that the web console is one application and the
backend is a different one, and they propagate the authentication by
using the tokens: the web console gets a token from the Keycloak
JavaScript adapter once the user logs in and sends it along with each
request to the backend. The backend (Keycloak Wildfly Adapter) reads
this token and retrieves the user data from the Keycloak server,
allowing the request to execute or not.

This means that either:

1) web console and REST API (and possibly other wars) become one, so
that the HTML5 single-page app can be served only after the user logs
in (classic Java EE application)

2) the backend JAAS adapter would need to support also some sort of
token exchange, with the frontend abstracting the Keycloak adapter to
work with one auth mechanism or another, possibly auto identifying
what is the backend's auth mechanism.

3) ??

I don't think that the first option is a real one. Having small wars,
each taking care of one concern, is a goal on the project.

So, would an effort in making Keycloak an optional part be worth it?
Should I pursue it?

- - Juca.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJUworiAAoJECKM1e+fkPrX8oMH/jC6DSOzx5gJuQNVHsojO6jB
xHjAbhiF89mnlC9iHBKTmZnJ6O4sOs870tibxhhmNvJs+N5wvQVCWhv+5JdqONfe
ETP4O7iKYLHu317DuNW8gl3FRP9Mgj/FkpgGhanikOLZ7S1B9/86zv8qdQ1/C6Hm
EM1MOIlSqqwPk+QPj/51Uo6rMG42ObG6P+mJOu7IhuJK4LS0uZI3yCIyk42+ngit
+T05kOfYOL24nOcL4iCjb0+Qg9SjNPASklq79Kz1h9tMZkq3CAXwyPJ0ty0kKSwR
mejY48LahgwmGQF53zovQJbb7Lpek+Uu9+G/vbcaJGLgqs5qwQq+3qa3e81Q9I0=
=5KoB
-----END PGP SIGNATURE-----

From jsanda at redhat.com  Fri Jan 23 13:25:31 2015
From: jsanda at redhat.com (John Sanda)
Date: Fri, 23 Jan 2015 13:25:31 -0500
Subject: [Hawkular-dev] Should Keycloak integration be optional?
In-Reply-To: <54C28AE2.3010509@redhat.com>
References: <54C28AE2.3010509@redhat.com>
Message-ID: <44431E91-1FEE-4549-A657-2B76E12954D0@redhat.com>


> On Jan 23, 2015, at 12:54 PM, Juraci Paix?o Kr?hling <jpkroehling at redhat.com> wrote:
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> As I mentioned on the previous email, one of the questions during the
> demo was if it would be possible to have the Keycloak integration as
> an optional part.
> 
> In the backend part, it's not hard to disable Keycloak as the
> authentication mechanism, as it's just JAAS. That would require,
> though, a second JAAS implementation to replace it.
> 
> In the frontend part, however, it's a bit more complicated. The setup
> right now is that the web console is treated as an HTML5 single-page
> app. This means that the web console is one application and the
> backend is a different one, and they propagate the authentication by
> using the tokens: the web console gets a token from the Keycloak
> JavaScript adapter once the user logs in and sends it along with each
> request to the backend. The backend (Keycloak Wildfly Adapter) reads
> this token and retrieves the user data from the Keycloak server,
> allowing the request to execute or not.
> 
> This means that either:
> 
> 1) web console and REST API (and possibly other wars) become one, so
> that the HTML5 single-page app can be served only after the user logs
> in (classic Java EE application)
> 
> 2) the backend JAAS adapter would need to support also some sort of
> token exchange, with the frontend abstracting the Keycloak adapter to
> work with one auth mechanism or another, possibly auto identifying
> what is the backend's auth mechanism.
> 
> 3) ??
> 
> I don't think that the first option is a real one. Having small wars,
> each taking care of one concern, is a goal on the project.
> 
> So, would an effort in making Keycloak an optional part be worth it?
> Should I pursue it?
> 

I am not sure about for production use, but for development I like the idea of being able to flip a switch to turn it on/off. I also agree that option 1 is undesirable. 

From jsanda at redhat.com  Fri Jan 23 13:41:56 2015
From: jsanda at redhat.com (John Sanda)
Date: Fri, 23 Jan 2015 13:41:56 -0500
Subject: [Hawkular-dev] JUnit and TestNG
Message-ID: <2EBD56E5-26B8-43E0-A781-79383757E828@redhat.com>

The decision was made a while ago to migrate from TestNG to JUnit. There was a PR[1] that migrated some of the integration tests to JUnit. I wound up rejecting the PR and keeping the integration tests in TestNG because it is not clear to me how JUnit supports some of the features that we have used and will continue to use with TestNG. Dependent methods is a good example. For the metrics aggregation tests in RHQ, there are tests for computing the 1 hr metrics, and there are tests for computing the 6 hr metrics. The 6 hr metrics test depends on the 1 hr metrics test. In JUnit the set up/tear down methods are considered part of the test fixture. In TestNG, they are configuration methods. This is a big difference because if a configuration method fails, then subsequent tests are skipped. This makes a lot of sense for integration tests. If I cannot create a connection to the database for example, then it is pointless to run the tests which rely on that connection.

My understanding is that there were a couple reasons for the change - 1) Arquillian has better support for JUnit than for TestNG and 2) JUnit is more up to date than earlier versions like 3.x (e.g., annotation driven). hawkular-metrics does not use Arquillian so I do not care about 1) and 2) is not much of a reason. Unless JUnit provides similar capabilities, I prefer to keep integration/functional tests in TestNG for hawkular-metrics.

[1] https://github.com/rhq-project/rhq-metrics/pull/101 <https://github.com/rhq-project/rhq-metrics/pull/101>


- John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20150123/2483fe5c/attachment.html 

From jsanda at redhat.com  Sun Jan 25 21:28:50 2015
From: jsanda at redhat.com (John Sanda)
Date: Sun, 25 Jan 2015 21:28:50 -0500
Subject: [Hawkular-dev] embedding hawkular-metrics
In-Reply-To: <64BEBA7A-BC54-46DA-8911-660B9871E4B4@redhat.com>
References: <E57F3492-F4B8-49F7-9944-F5A968CC3012@redhat.com>
	<54BEA69C.1080005@redhat.com>
	<26302928-D9C3-43E2-AD88-863097C0D3ED@redhat.com>
	<6B48C823-DC3B-4553-8460-C14F7149539C@redhat.com>
	<8CAA4BB8-AC20-4FF2-9488-437A8A051B63@redhat.com>
	<03016ABE-ACE5-4356-A733-09E621215EB2@redhat.com>
	<EB3F635A-0904-4374-A950-24A293105C58@redhat.com>
	<64BEBA7A-BC54-46DA-8911-660B9871E4B4@redhat.com>
Message-ID: <F32BBF04-F35D-4F74-8776-FE05953E1642@redhat.com>


> On Jan 22, 2015, at 3:48 PM, John Sanda <jsanda at redhat.com> wrote:
> 
> On Jan 21, 2015, at 3:04 PM, Heiko Braun <hbraun at redhat.com <mailto:hbraun at redhat.com>> wrote:
>> 
>> Some additional information regarding the wildfly integration and the rest interface in particular:
>> 
>> Any subsystem in wildfly can register an undertow HTTP handler or an undertow HTTP upgrade handler. The HTTP handler exposes the regular undertow API for building HTTP based endpoints [1]. This one should be straight forward to use for implementing the REST interface you currently have in rhq-metrics. 
>> 
>> The upgrade handler on the other hand does HTTP upgrade to a custom protocol of your choice (if needed in the future). It can as well be used to provide web socket based access to your services.
>> 
>> Taking into consideration that undertow can also be easily embedded [2]  I think this covers a lot of ground.
>> 
>> Regards, Heiko
>> 
>> [1] http://undertow.io/documentation/core/undertow-handler-guide.html <http://undertow.io/documentation/core/undertow-handler-guide.html>
>> [2] http://undertow.io/documentation/core/bootstrapping.html <http://undertow.io/documentation/core/bootstrapping.html>
>> 
> 
> Thanks for the info Heiko. Here is what we need to figure out. Provided that all of the business logic resides in the core service, would the amount of work involved with building another implementation with undertow be small enough that it would be worth have the two implementations. If the amount of work is small, would this be something you (and by you I basically mean the WF team) would be comfortable owning?
> 
> One thing that comes to mind is the keycloak integration. I am not how much effort/duplication would be involved. If it does look like it will be a lot of effort and/or duplication, then we really need to consider a more minimal stack without JAX-RS.
> 
> I have another, somewhat related question. The LiveOak project is also working with hawkular-metrics. I think that they are deploying the metrics war side by side with their stuff. If we wind up with a more minimal implementation as you describe, how would that work with LiveOak which is ok with consuming a war since they are running in a server that already has war deployments, JAX-RS, etc.?
> 
> - John

The more I think about this the more I think that the hawkular team should own this. One of the initial requirements for metrics early on was minimal dependencies in order to make it easy to embed. Stefan said he would start looking into an implementation built on undertow core. As far as the questions around maintaining the current JAX-RS implementation versus (or in addition to) something else, I do not think we need to rush a decision. I think we ought to at least get a working prototype in place and then revisit that discussion.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20150125/a4c8eb16/attachment.html 

From theute at redhat.com  Mon Jan 26 03:59:05 2015
From: theute at redhat.com (Thomas Heute)
Date: Mon, 26 Jan 2015 09:59:05 +0100
Subject: [Hawkular-dev] Should Keycloak integration be optional?
In-Reply-To: <54C28AE2.3010509@redhat.com>
References: <54C28AE2.3010509@redhat.com>
Message-ID: <54C601D9.9030102@redhat.com>

In terms of priority, we should focus on Hawkular (not just metrics) 
with Keycloak support and having it optional is not the priority.

Thomas

On 01/23/2015 06:54 PM, Juraci Paix?o Kr?hling wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> As I mentioned on the previous email, one of the questions during the
> demo was if it would be possible to have the Keycloak integration as
> an optional part.
>
> In the backend part, it's not hard to disable Keycloak as the
> authentication mechanism, as it's just JAAS. That would require,
> though, a second JAAS implementation to replace it.
>
> In the frontend part, however, it's a bit more complicated. The setup
> right now is that the web console is treated as an HTML5 single-page
> app. This means that the web console is one application and the
> backend is a different one, and they propagate the authentication by
> using the tokens: the web console gets a token from the Keycloak
> JavaScript adapter once the user logs in and sends it along with each
> request to the backend. The backend (Keycloak Wildfly Adapter) reads
> this token and retrieves the user data from the Keycloak server,
> allowing the request to execute or not.
>
> This means that either:
>
> 1) web console and REST API (and possibly other wars) become one, so
> that the HTML5 single-page app can be served only after the user logs
> in (classic Java EE application)
>
> 2) the backend JAAS adapter would need to support also some sort of
> token exchange, with the frontend abstracting the Keycloak adapter to
> work with one auth mechanism or another, possibly auto identifying
> what is the backend's auth mechanism.
>
> 3) ??
>
> I don't think that the first option is a real one. Having small wars,
> each taking care of one concern, is a goal on the project.
>
> So, would an effort in making Keycloak an optional part be worth it?
> Should I pursue it?
>
> - - Juca.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
>
> iQEcBAEBAgAGBQJUworiAAoJECKM1e+fkPrX8oMH/jC6DSOzx5gJuQNVHsojO6jB
> xHjAbhiF89mnlC9iHBKTmZnJ6O4sOs870tibxhhmNvJs+N5wvQVCWhv+5JdqONfe
> ETP4O7iKYLHu317DuNW8gl3FRP9Mgj/FkpgGhanikOLZ7S1B9/86zv8qdQ1/C6Hm
> EM1MOIlSqqwPk+QPj/51Uo6rMG42ObG6P+mJOu7IhuJK4LS0uZI3yCIyk42+ngit
> +T05kOfYOL24nOcL4iCjb0+Qg9SjNPASklq79Kz1h9tMZkq3CAXwyPJ0ty0kKSwR
> mejY48LahgwmGQF53zovQJbb7Lpek+Uu9+G/vbcaJGLgqs5qwQq+3qa3e81Q9I0=
> =5KoB
> -----END PGP SIGNATURE-----
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>

From ppalaga at redhat.com  Mon Jan 26 05:12:25 2015
From: ppalaga at redhat.com (Peter Palaga)
Date: Mon, 26 Jan 2015 11:12:25 +0100
Subject: [Hawkular-dev] JUnit and TestNG
In-Reply-To: <2EBD56E5-26B8-43E0-A781-79383757E828@redhat.com>
References: <2EBD56E5-26B8-43E0-A781-79383757E828@redhat.com>
Message-ID: <54C61309.2030804@redhat.com>

Hi John, thanks for posting this here so that everybody can see and 
comment. More inline...

On 01/23/2015 07:41 PM, John Sanda wrote:
> The decision was made a while ago to migrate from TestNG to JUnit. There
> was a PR[1] that migrated some of the integration tests to JUnit. I
> wound up rejecting the PR and keeping the integration tests in TestNG
> because it is not clear to me how JUnit supports some of the features
> that we have used and will continue to use with TestNG. Dependent
> methods is a good example.

This seems to imply that we use Dependent methods in rhq-metrics 
already. Sorry, I am not aware of that. Could you please point me to 
tests using them?

> For the metrics aggregation tests in RHQ,

Or you mean the old RHQ project here?

> there are tests for computing the 1 hr metrics, and there are tests for
> computing the 6 hr metrics. The 6 hr metrics test depends on the 1 hr
> metrics test.


[Assuming that the following is a required feature distinct from 
dependent tests]

> In JUnit the set up/tear down methods are considered part
> of the test fixture. In TestNG, they are configuration methods. This is
> a big difference because if a configuration method fails, then
> subsequent tests are skipped. This makes a lot of sense for integration
> tests. If I cannot create a connection to the database for example, then
> it is pointless to run the tests which rely on that connection.

"The JUnit way is to do this at runtime is org.junit.Assume." 
http://stackoverflow.com/a/1689309 This is exactly what we need, is it not?

> My understanding is that there were a couple reasons for the change - 1)
> Arquillian has better support for JUnit than for TestNG and 2) JUnit is
> more up to date than earlier versions like 3.x (e.g., annotation
> driven). hawkular-metrics does not use Arquillian so I do not care about
> 1) and 2) is not much of a reason. Unless JUnit provides similar
> capabilities, I prefer to keep integration/functional tests in TestNG
> for hawkular-metrics.

So you propose to remove jUnit from metrics altogether, right?

There is also reason 3) for introducing metrics: more mainstream, no 
need to learn new testing framework for more devs, having more tests and 
better coverage as a result.

 > Unless JUnit provides similar capabilities

Yes, we should state clearly, what is required but missing in jUnit. Now 
it seems that only dependent tests could fall into this category (but I 
am still not convinced that we really need them). Can anybody name other 
important features missing from jUnit?

Thanks,

Peter


> [1] https://github.com/rhq-project/rhq-metrics/pull/101
>
>
> - John
>
>
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>


From jpkroehling at redhat.com  Mon Jan 26 09:19:52 2015
From: jpkroehling at redhat.com (=?windows-1252?Q?Juraci_Paix=E3o_Kr=F6hling?=)
Date: Mon, 26 Jan 2015 15:19:52 +0100
Subject: [Hawkular-dev] Roles and Permissions in Hawkular
In-Reply-To: <D5D2AC2A-6413-4814-9E12-EC0AAE42AC11@redhat.com>
References: <D5D2AC2A-6413-4814-9E12-EC0AAE42AC11@redhat.com>
Message-ID: <54C64D08.9020507@redhat.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/22/2015 11:06 AM, Heiko W.Rupp wrote:
> Anyway: we need to start tagging endpoints with information about
> access levels so that we can enforce them by different policies.
> Those policies should probably not only take the user + credentials
> into account, but also the origin of requests, as for the above
> example, a request coming from the same machine or e.g. the
> Hawkular-glue may be treated differently than one coming from some
> random dump feed on the internet.
> 
> Note, that those access levels usually do not replace
> authentication (via KeyCloak), but are applied after successful
> authentication and probably role assignment. Depending on the use
> case (embedded Hawkular-metrics, Standalone Hawkular-Metrics,
> Standalone Hawkular) the check points may be at different places,
> or we decide to e.g. always enforce at the component boundary.

Keycloak supports nested roles, so, the checks on the Java side could
be *very* fine grained, while the roles that we "expose" are just a
grouping of those roles, probably to match Wildfly's names (monitor,
auditor, ...).

Also, if the backend is indeed going to be JAX-RS, the code can be
free from explicit checks by annotating the methods with the JAAS'
RolesAllowed and related.

Besides, we can also have roles that are exclusive to some
applications. So, user "jdoe" when using the application "standalone"
has an additional "standalone-super-duper" role. This way, instead of
checking the "origin", we can check if a specific role is present and
let JAAS handle the authorization part as well.

- - Juca.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJUxk0IAAoJECKM1e+fkPrXmB0H/3YU7UXRc7htABhCRycurejP
gDQly/3DYu8qm1UNmYvMVeobQH14Kd0AQMW1RlNqldR8Nes6+b0Fg5Wm8U3F3YoY
nLs+Mp727FfmbSJHSXVTUUwbf43tHdCLSxo1LpSDmxcMvexmRXYYyJGO/M6Uo6YN
HpLy5gZdg+053xHjkinPcjxZY98tl7YYwLM31M1YQUf+a+kdqwSpIy9CN/Pjylbl
oW9pGsn/oi7ZFdcJICJosBet1Vf3blbiMY98pzZ/0Yy2iv+UmbeGqa7hmUWWjmFJ
b2kwxoh286sEe/I4cLoZUcAVoz4FDl5JIGy4IXX8KYHYHXZxJ0QpZeehQkmoo/E=
=OQj9
-----END PGP SIGNATURE-----

From jpkroehling at redhat.com  Mon Jan 26 10:46:25 2015
From: jpkroehling at redhat.com (=?UTF-8?B?SnVyYWNpIFBhaXjDo28gS3LDtmhsaW5n?=)
Date: Mon, 26 Jan 2015 16:46:25 +0100
Subject: [Hawkular-dev] Realm selection modal
Message-ID: <54C66151.9040704@redhat.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

All,

Once the Keycloak integration PR gets merged, I intend to work on the
registration feature and that will impact the "realm selection modal"
(which was also discussed during the demo).

So, I'd like to ask for ideas on how to implement that. What we know
so far:

- - At first, each user is a tenant. So, the registration page could ask
for:
  * an "account name" (serves as the realm name)
  * email address (this user will serve as the realm's super user)
  * password

  As the output, it shows the user a set of credentials. For instance,
a UUID which will serve as "password" for wildfly-sender or other
remote agents.

This registration feature would be in a separate WAR, available
probably on the /registration context.

When logging in, we need to tell Keycloak against which realm to
authenticate this user. So, we have two main choices here:

Option 1
 * Allow the user to enter their account name on the first page.
 * We then redirect the user to the Keycloak login page, based on the
account name he entered. If the realm name exists, Keycloak shows the
login page. Otherwise, Keycloak complains.

- - or -

Option 2
 * We store the user's email and realm on our side
 * Before sending the user to the login page, we ask for the user's
email address. We then retrieve the realm for this address and send
the user for authentication.


I like the first option more, because:

 * We can change this logic on the future to pre-fill the user's
account based on some other meta-data (sub-domain, for instance).

 * Option 2 opens a door to email harvesting (the first step in an
attack reconnaissance phase): just enter a bunch of email address and
wait for a login page to appear and you have a confirmation that this
email exists.

As this is a topic that was discussed on the demo, I'd like to hear
your opinions/suggestions on how to implement this.

- - Juca.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJUxmFRAAoJECKM1e+fkPrX8dMIAIiu//9xPvkmztXsjt1bpV6V
SdgkfIk9Yctg4S4bRR2Cg2sigZ3Yq7zH/0CmiC/NCdh9dGYITjCPUmVjmmbEFVIz
e/n+cPLOpnH7j0GGq0yPF7BY/eJGLCC2RkY/OjnxkLBQ8TgoMC2sS5eQ5EJFywz0
EoB/YOJG4riokD9/bhuL5ztjGB/V9GxsoMwUks7YQIquhbGbiZ9aVi0ieAwFFuUh
MwtU5r4BoeVqDpwegkU5KU8Y3Jy20LtDm8kwKezsGNPyqkFeSUPymgn4uCnqlatM
j7cEP7KFlG6zCmoxUZNHnuMfGS+sTF0oezJFanyheb6+idI8leUMrrUo0Oi9/Cs=
=RPxX
-----END PGP SIGNATURE-----

From jpkroehling at redhat.com  Mon Jan 26 10:49:46 2015
From: jpkroehling at redhat.com (=?windows-1252?Q?Juraci_Paix=E3o_Kr=F6hling?=)
Date: Mon, 26 Jan 2015 16:49:46 +0100
Subject: [Hawkular-dev] Outcome of Keycloak Demo
In-Reply-To: <54C28596.2060909@redhat.com>
References: <54C28596.2060909@redhat.com>
Message-ID: <54C6621A.1050004@redhat.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/23/2015 06:32 PM, Juraci Paix?o Kr?hling wrote:
> 1) Would it be possible/desirable to make the Keycloak integration 
> optional?

Based on Thomas' email, I'll skip this. If the priority for this
changes in the future, I'll revisit this topic.

> 2) Would it be possible to not use the Keycloak appliance 
> distribution, using Wildfly instead?

I've just changed the start.sh and the PR has been updated.

If there are no complains before Wednesday, I'd then ask the reviewers
to take a final review and merge this PR.

- - Juca.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJUxmIZAAoJECKM1e+fkPrXSO4H/3KAvkLAI6nz86ps5n5+5BzN
yIOz0AI0s71CbCwmqWXX9LDEr0aLH43a1+mZlX/8QbWHfERdWnn5cXo4bUvcYoRl
C2V+Zi+ZSdoTcH7XnDvwmcOSIBohraU5OYwIfKdiQ570s0pOTmd/T5z4WGKQ9l53
cUuNg6wga2AX8UIIwc5J0tgUJP/t2lUs+5k9v7cYAP0lpGN+NoogsDxZm6aN73ad
DHTdhE63rZhPpMwqGQ8eBuMyANTtbowYM9JjopAvFgNxuGtAMhrNl3HNr4KUOHW/
4oZ/Vz/hAfus5M4TSngp9xcCMGmaXv9tnRI3uXa+ZP6wkZAeq4p/mE+7yAiHkc0=
=avu5
-----END PGP SIGNATURE-----

From tsegismo at redhat.com  Tue Jan 27 04:34:12 2015
From: tsegismo at redhat.com (Thomas Segismont)
Date: Tue, 27 Jan 2015 10:34:12 +0100
Subject: [Hawkular-dev] Should Keycloak integration be optional?
In-Reply-To: <54C601D9.9030102@redhat.com>
References: <54C28AE2.3010509@redhat.com> <54C601D9.9030102@redhat.com>
Message-ID: <54C75B94.8080103@redhat.com>

Le 26/01/2015 09:59, Thomas Heute a ?crit :
> In terms of priority, we should focus on Hawkular (not just metrics)

Agreed

> with Keycloak support and having it optional is not the priority.

Some more context maybe. I asked the question during the hangout and 
here's why. The PR as-is makes it impossible:
* to start a development container without KC
* to run tests/integration tests without KC
* to install a metrics server without KC

 From my perspective, that's important enough to consider making it or 
optional or holding the merge to let us think more about the problem.



From jpkroehling at redhat.com  Tue Jan 27 09:21:03 2015
From: jpkroehling at redhat.com (=?windows-1252?Q?Juraci_Paix=E3o_Kr=F6hling?=)
Date: Tue, 27 Jan 2015 15:21:03 +0100
Subject: [Hawkular-dev] Should Keycloak integration be optional?
In-Reply-To: <54C75B94.8080103@redhat.com>
References: <54C28AE2.3010509@redhat.com> <54C601D9.9030102@redhat.com>
	<54C75B94.8080103@redhat.com>
Message-ID: <54C79ECF.7020109@redhat.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/27/2015 10:34 AM, Thomas Segismont wrote:
> Le 26/01/2015 09:59, Thomas Heute a ?crit :
>> In terms of priority, we should focus on Hawkular (not just
>> metrics)
> 
> Agreed
> 
>> with Keycloak support and having it optional is not the
>> priority.
> 
> Some more context maybe. I asked the question during the hangout
> and here's why. The PR as-is makes it impossible: * to start a
> development container without KC * to run tests/integration tests
> without KC * to install a metrics server without KC

While I agree that an optional KC would make the above points easier,
I'm failing to see the concrete advantages that it would bring,
specially considering that the main code will depend on features that
KC is today bringing (multi tenancy security, for one).

For instance, to start a development environment, one can run the
start.sh script that currently takes care of installing Wildfly and
Cassandra. With the PR, KC is added to this mix.

About the integration tests, I'd argue that the correct way to run the
integration tests is with the security framework enabled, whatever
this framework is. The reason being that this framework (plus the
container itself) would provide tenant information to the target code.
What we have on the PR is exactly this: the tests know nothing about
KC, the target code knows nothing about KC, but KC is installed on the
container and provides user information to the target code (or blocks
the request, if the wrong credentials are provided). For tests where
no tenant-specific logic is performed, a common credential can be used
for all tests, which would make more sense than disabling the security
framework for those tests.

I'm not sure what you mean in your last point, though.

> From my perspective, that's important enough to consider making it
> or optional or holding the merge to let us think more about the
> problem.
> 

Indeed! I think discussing this at this phase is critical, so that we
can get into a consensus about the expectations :-)

- - Juca.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJUx57PAAoJECKM1e+fkPrXAo4H+we+iMpdNIiYhUAEzkssFNGh
jE2BdLmyUaKbciswTrxY8nC5xruqz3h77n5bNZhF/oyeygePxgB+MmIt14Bnrxej
ht35GzAZBLRiLz7Ybt9dubkiOc8D5fUUM7CmZjpQ7ZNwdOg2r0XRyh8DGfWV+nlV
BoaEV5HvxBu9FLIPhrY9Bc6woTv8H4vJdf1/VPU7c6+D55LHX8IL7tbxrQsmLYq1
QWq8h892fpLCOrbri6kw/o3xUV9X80As5ovIQUOzlGrvsuyT/PwwbmVwCjZ8hwfC
QnaiqKHfzadz8Wl3cuDSFU7/P5cC3SAWiOvZPXFXJ0CHu4Dk7UMQAevrwguHEFE=
=Hh/n
-----END PGP SIGNATURE-----

From vrockai at redhat.com  Tue Jan 27 12:09:55 2015
From: vrockai at redhat.com (Viliam Rockai)
Date: Tue, 27 Jan 2015 18:09:55 +0100
Subject: [Hawkular-dev] Console project structure and plugins
Message-ID: <1422378595.5650.29.camel@vrockai-laptop>

Hey All,

I want to start this thread to gather some information about how
components are shared between projects. So, to make the terminology
clear, lets check this stuff:
https://github.com/vrockai/hawkular/tree/master/ui/console/alerts
https://github.com/vrockai/hawkular/tree/master/ui/console/metrics

are future components/widgets which are going to be used on the console
page. Those components are Hawtio 2.x plugins.

According to:
https://github.com/hawtio/hawtio/blob/master/docs/Overview2dotX.md

I expect exposing plugins as bower packages is the preferred way in
Hawtio 2.x. From my perspective (angular guy) this is pretty much what
is expected. The only way to expose/share those components as bower
packages to third-parties would be to put them in separate repo. As was
already said on IRC, this may be overkill. I see two ways of resolution:

1. Create separate repository for each component. Those all would be
bower dependencies of the hawkular console.
Pros: possibly consistent with the Hawtio 2.x ways, modularity = we
download only what we need. 
Cons: lots of repositories to take care of.

2. Create a single repository for all the plugins. The whole library of
sibling components, similar to i.e. Angular-UI. 
Pros: easier maintenance. 
Cons: less modular = need to download whole library before we filter
which plugins we want to use.

I see, that the 2nd approach already exists in the hawtio repository,
probably the best way would be to put our components to this repo:
https://github.com/hawtio/hawtio-ui

Thanks for your thoughts,

Viliam


From hrupp at redhat.com  Tue Jan 27 12:13:11 2015
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Tue, 27 Jan 2015 18:13:11 +0100
Subject: [Hawkular-dev] Meeting recording of Jan 27th meeting
Message-ID: <7D4F6DFC-934C-4C50-B65C-990BA90A9A22@redhat.com>

Hey,

find below a link to the (video) recording of todays meeting. For those not on the call, I was talking a bit about
Continuous Deployment and especially about KanBan and the respective Jira boards and also how we 
should use them and proceed. 

https://bluejeans.com/s/81Xm/

You should be able to see the boards when you go to issues.jboss.org and then in the top
menu bar go on "Agile".

This is the link to the overall board

https://issues.jboss.org/secure/RapidBoard.jspa?rapidView=1242

One thing that I did not talk about is the reporting - we do not yet have enough data
in the system. I will do that as soon as we have more data available.

  Heiko



From mithomps at redhat.com  Tue Jan 27 12:25:36 2015
From: mithomps at redhat.com (mike thompson)
Date: Tue, 27 Jan 2015 09:25:36 -0800
Subject: [Hawkular-dev] Console project structure and plugins
In-Reply-To: <1422378595.5650.29.camel@vrockai-laptop>
References: <1422378595.5650.29.camel@vrockai-laptop>
Message-ID: <F3EDF0DC-0014-4D22-98A9-FF8FEE7C3704@redhat.com>


> On 27 Jan 2015, at 09:09, Viliam Rockai <vrockai at redhat.com> wrote:
> 
> Hey All,
> 
> I want to start this thread to gather some information about how
> components are shared between projects. So, to make the terminology
> clear, lets check this stuff:
> https://github.com/vrockai/hawkular/tree/master/ui/console/alerts
> https://github.com/vrockai/hawkular/tree/master/ui/console/metrics
> 
> are future components/widgets which are going to be used on the console
> page. Those components are Hawtio 2.x plugins.
> 
> According to:
> https://github.com/hawtio/hawtio/blob/master/docs/Overview2dotX.md
> 
> I expect exposing plugins as bower packages is the preferred way in
> Hawtio 2.x. From my perspective (angular guy) this is pretty much what
> is expected. The only way to expose/share those components as bower
> packages to third-parties would be to put them in separate repo. As was
> already said on IRC, this may be overkill. I see two ways of resolution:
> 
> 1. Create separate repository for each component. Those all would be
> bower dependencies of the hawkular console.
> Pros: possibly consistent with the Hawtio 2.x ways, modularity = we
> download only what we need. 
> Cons: lots of repositories to take care of.
> 
> 2. Create a single repository for all the plugins. The whole library of
> sibling components, similar to i.e. Angular-UI. 
> Pros: easier maintenance. 
> Cons: less modular = need to download whole library before we filter
> which plugins we want to use.

We could use a combination of 1 + 2 meaning: use the directory structure of 2, but publishing each of those plugins as bower components to pulled into the main Hawkular-console (or other hawt.io consoles). This keeps the plugins free of maven as only the Hawkular console build would use maven to pull in the bower components. Each plugin publishes a new version when ready and Hawkular console can assemble using whatever versions.
Pros: easier maintenance, code is all in one place. We get bower components and versioning.
Cons: there is no need for a target directory (because no maven for ui plugins) so bower/npm component artefacts get downloaded into source dir.


> 
> I see, that the 2nd approach already exists in the hawtio repository,
> probably the best way would be to put our components to this repo:
> https://github.com/hawtio/hawtio-ui
> 
> Thanks for your thoughts,
> 
> Viliam
> 
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev



From vrockai at redhat.com  Tue Jan 27 12:51:07 2015
From: vrockai at redhat.com (Viliam Rockai)
Date: Tue, 27 Jan 2015 18:51:07 +0100
Subject: [Hawkular-dev] Console project structure and plugins
In-Reply-To: <F3EDF0DC-0014-4D22-98A9-FF8FEE7C3704@redhat.com>
References: <1422378595.5650.29.camel@vrockai-laptop>
	<F3EDF0DC-0014-4D22-98A9-FF8FEE7C3704@redhat.com>
Message-ID: <1422381067.5650.45.camel@vrockai-laptop>

On Tue, 2015-01-27 at 09:25 -0800, mike thompson wrote:
> > On 27 Jan 2015, at 09:09, Viliam Rockai <vrockai at redhat.com> wrote:
> > 
> > Hey All,
> > 
> > I want to start this thread to gather some information about how
> > components are shared between projects. So, to make the terminology
> > clear, lets check this stuff:
> > https://github.com/vrockai/hawkular/tree/master/ui/console/alerts
> > https://github.com/vrockai/hawkular/tree/master/ui/console/metrics
> > 
> > are future components/widgets which are going to be used on the console
> > page. Those components are Hawtio 2.x plugins.
> > 
> > According to:
> > https://github.com/hawtio/hawtio/blob/master/docs/Overview2dotX.md
> > 
> > I expect exposing plugins as bower packages is the preferred way in
> > Hawtio 2.x. From my perspective (angular guy) this is pretty much what
> > is expected. The only way to expose/share those components as bower
> > packages to third-parties would be to put them in separate repo. As was
> > already said on IRC, this may be overkill. I see two ways of resolution:
> > 
> > 1. Create separate repository for each component. Those all would be
> > bower dependencies of the hawkular console.
> > Pros: possibly consistent with the Hawtio 2.x ways, modularity = we
> > download only what we need. 
> > Cons: lots of repositories to take care of.
> > 
> > 2. Create a single repository for all the plugins. The whole library of
> > sibling components, similar to i.e. Angular-UI. 
> > Pros: easier maintenance. 
> > Cons: less modular = need to download whole library before we filter
> > which plugins we want to use.
> 
> We could use a combination of 1 + 2 meaning: use the directory structure of 2, but publishing each of those plugins as bower components to pulled into the main Hawkular-console (or other hawt.io consoles). This keeps the plugins free of maven as only the Hawkular console build would use maven to pull in the bower components. Each plugin publishes a new version when ready and Hawkular console can assemble using whatever versions.
> Pros: easier maintenance, code is all in one place. We get bower components and versioning.
> Cons: there is no need for a target directory (because no maven for ui plugins) so bower/npm component artefacts get downloaded into source dir.
> 

I don't understand, can you please show it on some example directory
structure? Do you mean to have number of directories (one for each
plugin) with bower.json in each directory? I'm confused, because bower
package == repository. I can't publish a plugin within a repository.
Once published, it's the whole repository which is published, not just
one sub-directory in it.

Bower and npm stuff in the src directory: In the LO console we wanted to
avoid this. The idea was, once you do "mvn clean" you should have the
same files as before the build and everything else is deleted.
Using .gitignore for special node/bower directories may be obvious to
people developing the console, but may cause some pain to people who
expect the src not to contain anything new (cached packages, which are
not updated, ...) after cleaning. But if it's not a maven project, I
don't think this applies. If this is only a case for the "bower package"
repository of our plugins, I don't see it as a con.

> 
> > 
> > I see, that the 2nd approach already exists in the hawtio repository,
> > probably the best way would be to put our components to this repo:
> > https://github.com/hawtio/hawtio-ui
> > 
> > Thanks for your thoughts,
> > 
> > Viliam
> > 
> > _______________________________________________
> > hawkular-dev mailing list
> > hawkular-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hawkular-dev
> 



From theute at redhat.com  Tue Jan 27 14:05:17 2015
From: theute at redhat.com (Thomas Heute)
Date: Tue, 27 Jan 2015 20:05:17 +0100
Subject: [Hawkular-dev] Console project structure and plugins
In-Reply-To: <1422378595.5650.29.camel@vrockai-laptop>
References: <1422378595.5650.29.camel@vrockai-laptop>
Message-ID: <54C7E16D.8000707@redhat.com>


On 01/27/2015 06:09 PM, Viliam Rockai wrote:
> Hey All,
>
> I want to start this thread to gather some information about how
> components are shared between projects. So, to make the terminology
> clear, lets check this stuff:
> https://github.com/vrockai/hawkular/tree/master/ui/console/alerts
> https://github.com/vrockai/hawkular/tree/master/ui/console/metrics
>
> are future components/widgets which are going to be used on the console
> page. Those components are Hawtio 2.x plugins.
>
> According to:
> https://github.com/hawtio/hawtio/blob/master/docs/Overview2dotX.md
>
> I expect exposing plugins as bower packages is the preferred way in
> Hawtio 2.x. From my perspective (angular guy) this is pretty much what
> is expected. The only way to expose/share those components as bower
> packages to third-parties would be to put them in separate repo. As was
> already said on IRC, this may be overkill. I see two ways of resolution:
>
> 1. Create separate repository for each component. Those all would be
> bower dependencies of the hawkular console.
> Pros: possibly consistent with the Hawtio 2.x ways, modularity = we
> download only what we need.
> Cons: lots of repositories to take care of.
>
> 2. Create a single repository for all the plugins. The whole library of
> sibling components, similar to i.e. Angular-UI.
> Pros: easier maintenance.
> Cons: less modular = need to download whole library before we filter
> which plugins we want to use.
>
> I see, that the 2nd approach already exists in the hawtio repository,
> probably the best way would be to put our components to this repo:
> https://github.com/hawtio/hawtio-ui
We need to be able to release early/often and be relatively independent. 
I don't think our components are generic enough for this repository 
anyway (since they depend on our services).

It's a long term goal to be able to consume Fabric8 hawt.io plugin and 
to be embeddable with OpenShift Dev console but in the immediate the 
priority is to have a standalone monitoring project. In the short/medium 
term we will anyway only build plugins that we need for hawkular so the 
cons of having to download the whole library doesn't really apply. I 
don't know anything about Bower/hawt.io and UI stuff of 2014/2015 but 
option 2 sounds good at least initially while we need to develop fast 
and will likely want to reorg code a couple of times before we are 
satisfied.

I notice that they have a single repo for multiple plugins so I guess we 
can as well ?

Thomas

Thomas

>
> Thanks for your thoughts,
>
> Viliam
>
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev


From mithomps at redhat.com  Tue Jan 27 14:06:52 2015
From: mithomps at redhat.com (mike thompson)
Date: Tue, 27 Jan 2015 11:06:52 -0800
Subject: [Hawkular-dev] Console project structure and plugins
In-Reply-To: <1422381067.5650.45.camel@vrockai-laptop>
References: <1422378595.5650.29.camel@vrockai-laptop>
	<F3EDF0DC-0014-4D22-98A9-FF8FEE7C3704@redhat.com>
	<1422381067.5650.45.camel@vrockai-laptop>
Message-ID: <2F9E2069-8F55-4DD7-8229-9A5A59F36C6F@redhat.com>


> On 27 Jan 2015, at 09:51, Viliam Rockai <vrockai at redhat.com> wrote:
> 
> On Tue, 2015-01-27 at 09:25 -0800, mike thompson wrote:
>>> On 27 Jan 2015, at 09:09, Viliam Rockai <vrockai at redhat.com> wrote:
>>> 
>>> Hey All,
>>> 
>>> I want to start this thread to gather some information about how
>>> components are shared between projects. So, to make the terminology
>>> clear, lets check this stuff:
>>> https://github.com/vrockai/hawkular/tree/master/ui/console/alerts
>>> https://github.com/vrockai/hawkular/tree/master/ui/console/metrics
>>> 
>>> are future components/widgets which are going to be used on the console
>>> page. Those components are Hawtio 2.x plugins.
>>> 
>>> According to:
>>> https://github.com/hawtio/hawtio/blob/master/docs/Overview2dotX.md
>>> 
>>> I expect exposing plugins as bower packages is the preferred way in
>>> Hawtio 2.x. From my perspective (angular guy) this is pretty much what
>>> is expected. The only way to expose/share those components as bower
>>> packages to third-parties would be to put them in separate repo. As was
>>> already said on IRC, this may be overkill. I see two ways of resolution:
>>> 
>>> 1. Create separate repository for each component. Those all would be
>>> bower dependencies of the hawkular console.
>>> Pros: possibly consistent with the Hawtio 2.x ways, modularity = we
>>> download only what we need. 
>>> Cons: lots of repositories to take care of.
>>> 
>>> 2. Create a single repository for all the plugins. The whole library of
>>> sibling components, similar to i.e. Angular-UI. 
>>> Pros: easier maintenance. 
>>> Cons: less modular = need to download whole library before we filter
>>> which plugins we want to use.
>> 
>> We could use a combination of 1 + 2 meaning: use the directory structure of 2, but publishing each of those plugins as bower components to pulled into the main Hawkular-console (or other hawt.io consoles). This keeps the plugins free of maven as only the Hawkular console build would use maven to pull in the bower components. Each plugin publishes a new version when ready and Hawkular console can assemble using whatever versions.
>> Pros: easier maintenance, code is all in one place. We get bower components and versioning.
>> Cons: there is no need for a target directory (because no maven for ui plugins) so bower/npm component artefacts get downloaded into source dir.
>> 
> 
> I don't understand, can you please show it on some example directory
> structure? Do you mean to have number of directories (one for each
> plugin) with bower.json in each directory? I'm confused, because bower
> package == repository. I can't publish a plugin within a repository.
> Once published, it's the whole repository which is published, not just
> one sub-directory in it.

> 
> Bower and npm stuff in the src directory: In the LO console we wanted to
> avoid this. The idea was, once you do "mvn clean" you should have the
> same files as before the build and everything else is deleted.
> Using .gitignore for special node/bower directories may be obvious to
> people developing the console, but may cause some pain to people who
> expect the src not to contain anything new (cached packages, which are
> not updated, ...) after cleaning. But if it's not a maven project, I
> don't think this applies. If this is only a case for the "bower package"
> repository of our plugins, I don't see it as a con.

Nevermind, bower does require the git end point (its own repo) because it uses the tags for versioning. So back to 1, 2 and possibly 3?

3. Use Hawkular repo as git endpoint for a single bower package. This means we would have to setup bower at the root of the project (so that it is a proper bower package). 
Pros: This would give us one bower component/package that  would not require another git repo(s).
Cons: We would have only one plugin/package and it would need to be versioned at the same rate as Hawkular because they would both be using the same git tag for versions. Also some bower.json file would need to be exposed at the root directory level.

> 
>> 
>>> 
>>> I see, that the 2nd approach already exists in the hawtio repository,
>>> probably the best way would be to put our components to this repo:
>>> https://github.com/hawtio/hawtio-ui
>>> 
>>> Thanks for your thoughts,
>>> 
>>> Viliam

FWIW: I still like the option 1) multiple git repos (as long a we limit it to a couple repos). Just because this is the way js/bower package management is supposed to work.

>>> 
>>> _______________________________________________
>>> hawkular-dev mailing list
>>> hawkular-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>> 
> 
> 



From mithomps at redhat.com  Tue Jan 27 15:31:54 2015
From: mithomps at redhat.com (mike thompson)
Date: Tue, 27 Jan 2015 12:31:54 -0800
Subject: [Hawkular-dev] Console project structure and plugins
In-Reply-To: <54C7E16D.8000707@redhat.com>
References: <1422378595.5650.29.camel@vrockai-laptop>
	<54C7E16D.8000707@redhat.com>
Message-ID: <1DCCBF44-8DCF-4E30-BB48-7FF1E7AF5C3D@redhat.com>


> On 27 Jan 2015, at 11:05, Thomas Heute <theute at redhat.com> wrote:
> 
> 
> On 01/27/2015 06:09 PM, Viliam Rockai wrote:
>> Hey All,
>> 
>> I want to start this thread to gather some information about how
>> components are shared between projects. So, to make the terminology
>> clear, lets check this stuff:
>> https://github.com/vrockai/hawkular/tree/master/ui/console/alerts
>> https://github.com/vrockai/hawkular/tree/master/ui/console/metrics
>> 
>> are future components/widgets which are going to be used on the console
>> page. Those components are Hawtio 2.x plugins.
>> 
>> According to:
>> https://github.com/hawtio/hawtio/blob/master/docs/Overview2dotX.md
>> 
>> I expect exposing plugins as bower packages is the preferred way in
>> Hawtio 2.x. From my perspective (angular guy) this is pretty much what
>> is expected. The only way to expose/share those components as bower
>> packages to third-parties would be to put them in separate repo. As was
>> already said on IRC, this may be overkill. I see two ways of resolution:
>> 
>> 1. Create separate repository for each component. Those all would be
>> bower dependencies of the hawkular console.
>> Pros: possibly consistent with the Hawtio 2.x ways, modularity = we
>> download only what we need.
>> Cons: lots of repositories to take care of.
>> 
>> 2. Create a single repository for all the plugins. The whole library of
>> sibling components, similar to i.e. Angular-UI.
>> Pros: easier maintenance.
>> Cons: less modular = need to download whole library before we filter
>> which plugins we want to use.
>> 
>> I see, that the 2nd approach already exists in the hawtio repository,
>> probably the best way would be to put our components to this repo:
>> https://github.com/hawtio/hawtio-ui
> We need to be able to release early/often and be relatively independent. 
> I don't think our components are generic enough for this repository 
> anyway (since they depend on our services).
> 
> It's a long term goal to be able to consume Fabric8 hawt.io plugin and 
> to be embeddable with OpenShift Dev console but in the immediate the 
> priority is to have a standalone monitoring project. In the short/medium 
> term we will anyway only build plugins that we need for hawkular so the 
> cons of having to download the whole library doesn't really apply. I 
> don't know anything about Bower/hawt.io and UI stuff of 2014/2015 but 
> option 2 sounds good at least initially while we need to develop fast 
> and will likely want to reorg code a couple of times before we are 
> satisfied.
> 
> I notice that they have a single repo for multiple plugins so I guess we 
> can as well ?
Perhaps you are looking at the old plugins some of which have not been migrated to the new hawt.io 2 plugin architecture. Right now there are 11 bower packages(and corresponding repos):

http://bower.io/search/?q=hawtio <http://bower.io/search/?q=hawtio>

Plugins are bower packages and require a git repo but several plugins can be packaged into a single bower package.

So that sounds like our best bet to add another git repo for the ui and wrap all of our plugins up into that bower package.

> 
> Thomas
> 
> Thomas
> 
>> 
>> Thanks for your thoughts,
>> 
>> Viliam
>> 
>> _______________________________________________
>> hawkular-dev mailing list
>> hawkular-dev at lists.jboss.org <mailto:hawkular-dev at lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/hawkular-dev <https://lists.jboss.org/mailman/listinfo/hawkular-dev>
> 
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org <mailto:hawkular-dev at lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/hawkular-dev <https://lists.jboss.org/mailman/listinfo/hawkular-dev>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20150127/df29b9c9/attachment-0001.html 

From jpkroehling at redhat.com  Wed Jan 28 03:38:18 2015
From: jpkroehling at redhat.com (=?windows-1252?Q?Juraci_Paix=E3o_Kr=F6hling?=)
Date: Wed, 28 Jan 2015 09:38:18 +0100
Subject: [Hawkular-dev] Console project structure and plugins
In-Reply-To: <1422378595.5650.29.camel@vrockai-laptop>
References: <1422378595.5650.29.camel@vrockai-laptop>
Message-ID: <54C89FFA.7090709@redhat.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/27/2015 06:09 PM, Viliam Rockai wrote:
> 1. Create separate repository for each component. Those all would
> be bower dependencies of the hawkular console. Pros: possibly
> consistent with the Hawtio 2.x ways, modularity = we download only
> what we need. Cons: lots of repositories to take care of.

I'd go with this one, coupled with a good CI mechanism. For Jenkins,
you could have "pipes" and a "release" plugin, so, if the modules are
independent enough, releasing should not take an effort bigger than
clicking on a button (if that's what you mean by "lots of repositories
to take care of").

- - Juca.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJUyJ/6AAoJECKM1e+fkPrXOCUH/1WEYUVWksIya2Y3kZKmXnjv
JhFsGcmYHUFNk+3I+fnJGJzQuvOfpd0mErPjDleqV11yMDyLZQx843c50eIjiK1F
uJelnyOUWQBv0fg05akL0P/xdb4Tc9rCfMWXyzOdQVlcX/70/JWFMxfxJLqXD2U1
r9UUzQOq2BLrGs+SOEHRHL1F2W1zKoBdwyng8v3TY/auqMzIz3EN1XcJIGZVaX+G
LvobmEy1MqU9L5l90fHodY3WpS+47pZehG91FrlcMnr0EHwUxCo1ByWT+qQ9OzVZ
7QlzacwupjmSSBewUmJnZFubH9X6zg2pR/q19wkT9CQ91ROeVL89bAVKnsFrP58=
=MM7m
-----END PGP SIGNATURE-----

From theute at redhat.com  Wed Jan 28 06:04:53 2015
From: theute at redhat.com (Thomas Heute)
Date: Wed, 28 Jan 2015 12:04:53 +0100
Subject: [Hawkular-dev] Console project structure and plugins
In-Reply-To: <54C89FFA.7090709@redhat.com>
References: <1422378595.5650.29.camel@vrockai-laptop>
	<54C89FFA.7090709@redhat.com>
Message-ID: <54C8C255.3090609@redhat.com>


On 01/28/2015 09:38 AM, Juraci Paix?o Kr?hling wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 01/27/2015 06:09 PM, Viliam Rockai wrote:
>> 1. Create separate repository for each component. Those all would
>> be bower dependencies of the hawkular console. Pros: possibly
>> consistent with the Hawtio 2.x ways, modularity = we download only
>> what we need. Cons: lots of repositories to take care of.
> I'd go with this one, coupled with a good CI mechanism. For Jenkins,
> you could have "pipes" and a "release" plugin, so, if the modules are
> independent enough, releasing should not take an effort bigger than
> clicking on a button (if that's what you mean by "lots of repositories
> to take care of").
+ productization ;)


>
> - - Juca.
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
>
> iQEcBAEBAgAGBQJUyJ/6AAoJECKM1e+fkPrXOCUH/1WEYUVWksIya2Y3kZKmXnjv
> JhFsGcmYHUFNk+3I+fnJGJzQuvOfpd0mErPjDleqV11yMDyLZQx843c50eIjiK1F
> uJelnyOUWQBv0fg05akL0P/xdb4Tc9rCfMWXyzOdQVlcX/70/JWFMxfxJLqXD2U1
> r9UUzQOq2BLrGs+SOEHRHL1F2W1zKoBdwyng8v3TY/auqMzIz3EN1XcJIGZVaX+G
> LvobmEy1MqU9L5l90fHodY3WpS+47pZehG91FrlcMnr0EHwUxCo1ByWT+qQ9OzVZ
> 7QlzacwupjmSSBewUmJnZFubH9X6zg2pR/q19wkT9CQ91ROeVL89bAVKnsFrP58=
> =MM7m
> -----END PGP SIGNATURE-----
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev


From hrupp at redhat.com  Wed Jan 28 06:48:26 2015
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Wed, 28 Jan 2015 12:48:26 +0100
Subject: [Hawkular-dev] Logging ...
Message-ID: <F23B80F3-E163-4A25-94FD-AAB67FA66648@redhat.com>

Hey,

We should / need to start using logging codes just like Wildfly does.

11:19:27,714 INFO  [org.wildfly.extension.io] (ServerService Thread Pool -- 31) WFLYIO001: Worker 'default' has auto-configured to 8 core threads with 64 task threads based on your 4 available processors
11:19:27,716 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 32) JBAS010280: Activating Infinispan subsystem.

We have two options here

1) 
We  use "HAWK" as our prefix and the following  code ranges initially

0-999  Hawkular (integration)
1000-1999 Hawkular-Metrics
2000-2999 Hawkular-Alerts (notifiers should probably be broken out in separate blocks)
3000-3999 Hawkular-Inventory
4000-4999 Hawkular-Bus

2)
We use a prefix per component (e.g. HAWK, HKMET, HKAL, ...) and each component has its own code range starting
at 0 

Personally I prefer option 1

There is already documentation on this available

	? https://developer.jboss.org/wiki/HowToLogInJBossProjects
	? https://developer.jboss.org/wiki/InternationalizedLoggingAndExceptions
	? https://developer.jboss.org/wiki/JBossLoggingTooling

While the documentation and examples look a bit complicated, I think we can "reduce" them for
our purpose for Warnings and Errors and do not need them on debug/trace level.
For info level I guess one should personal judgement (and then if it is not important enough for
its own code, it is probably not really something at info, but rather at debug level).

In practice we would probably end up with something like:

import org.jboss.logging.*;
public interface RestApiLogger {

    RestApiLogger LOGGER = Logger.getMessageLogger(RestApiLogger.class,"org.hawkular.inventory.rest");

    @LogMessage(level = Logger.Level.WARN)
    @Message(id = 3000, value = "Something bad has happened")
    void warn(@Cause Throwable t);

  < plus much more refined messages here >
}

and then in code

} catch (Exception e) {
    RestApiLogger.LOGGER.warn(e);
    return Response.serverError().entity(e).build();
}



-- 
Reg. Adresse: Red Hat GmbH, Technopark II, Haus C, 
Werner-von-Siemens-Ring 14, D-85630 Grasbrunn
Handelsregister: Amtsgericht M?nchen HRB 153243
Gesch?ftsf?hrer: Charles Cachera, Michael Cunningham, Paul Hickey, Charlie Peters



From lponce at redhat.com  Wed Jan 28 06:57:19 2015
From: lponce at redhat.com (Lucas Ponce)
Date: Wed, 28 Jan 2015 06:57:19 -0500 (EST)
Subject: [Hawkular-dev] Logging ...
In-Reply-To: <F23B80F3-E163-4A25-94FD-AAB67FA66648@redhat.com>
References: <F23B80F3-E163-4A25-94FD-AAB67FA66648@redhat.com>
Message-ID: <1401520273.2306861.1422446239726.JavaMail.zimbra@redhat.com>

And what about the logging packages ?

> import org.jboss.logging.*;

vs

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

I personally vote for org.slf4j.

I prefer a mix on option 1) and 2), a common numeration for codes, but each component can still using a specific acronym.

That it can help better to follow traces/logs.

Also, this point can be discussed later, but is there any convention for debug, like this one: 

        if (LOG.isDebugEnabled()) {
            LOG.debug("Message received: [{}]", msg);
        }

I mean, I like to use DEBUG for verbosity, but to reduce performance penalty, we can discuss a common approach.

Above one is just a suggestion.

Thanks,
Lucas


----- Original Message -----
> From: "Heiko W.Rupp" <hrupp at redhat.com>
> To: hawkular-dev at lists.jboss.org
> Sent: Wednesday, January 28, 2015 12:48:26 PM
> Subject: [Hawkular-dev] Logging ...
> 
> Hey,
> 
> We should / need to start using logging codes just like Wildfly does.
> 
> 11:19:27,714 INFO  [org.wildfly.extension.io] (ServerService Thread Pool --
> 31) WFLYIO001: Worker 'default' has auto-configured to 8 core threads with
> 64 task threads based on your 4 available processors
> 11:19:27,716 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread
> Pool -- 32) JBAS010280: Activating Infinispan subsystem.
> 
> We have two options here
> 
> 1)
> We  use "HAWK" as our prefix and the following  code ranges initially
> 
> 0-999  Hawkular (integration)
> 1000-1999 Hawkular-Metrics
> 2000-2999 Hawkular-Alerts (notifiers should probably be broken out in
> separate blocks)
> 3000-3999 Hawkular-Inventory
> 4000-4999 Hawkular-Bus
> 
> 2)
> We use a prefix per component (e.g. HAWK, HKMET, HKAL, ...) and each
> component has its own code range starting
> at 0
> 
> Personally I prefer option 1
> 
> There is already documentation on this available
> 
> 	? https://developer.jboss.org/wiki/HowToLogInJBossProjects
> 	? https://developer.jboss.org/wiki/InternationalizedLoggingAndExceptions
> 	? https://developer.jboss.org/wiki/JBossLoggingTooling
> 
> While the documentation and examples look a bit complicated, I think we can
> "reduce" them for
> our purpose for Warnings and Errors and do not need them on debug/trace
> level.
> For info level I guess one should personal judgement (and then if it is not
> important enough for
> its own code, it is probably not really something at info, but rather at
> debug level).
> 
> In practice we would probably end up with something like:
> 
> import org.jboss.logging.*;
> public interface RestApiLogger {
> 
>     RestApiLogger LOGGER =
>     Logger.getMessageLogger(RestApiLogger.class,"org.hawkular.inventory.rest");
> 
>     @LogMessage(level = Logger.Level.WARN)
>     @Message(id = 3000, value = "Something bad has happened")
>     void warn(@Cause Throwable t);
> 
>   < plus much more refined messages here >
> }
> 
> and then in code
> 
> } catch (Exception e) {
>     RestApiLogger.LOGGER.warn(e);
>     return Response.serverError().entity(e).build();
> }
> 
> 
> 
> --
> Reg. Adresse: Red Hat GmbH, Technopark II, Haus C,
> Werner-von-Siemens-Ring 14, D-85630 Grasbrunn
> Handelsregister: Amtsgericht M?nchen HRB 153243
> Gesch?ftsf?hrer: Charles Cachera, Michael Cunningham, Paul Hickey, Charlie
> Peters
> 
> 
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>


From theute at redhat.com  Wed Jan 28 07:32:19 2015
From: theute at redhat.com (Thomas Heute)
Date: Wed, 28 Jan 2015 13:32:19 +0100
Subject: [Hawkular-dev] Logging ...
In-Reply-To: <1401520273.2306861.1422446239726.JavaMail.zimbra@redhat.com>
References: <F23B80F3-E163-4A25-94FD-AAB67FA66648@redhat.com>
	<1401520273.2306861.1422446239726.JavaMail.zimbra@redhat.com>
Message-ID: <54C8D6D3.7060305@redhat.com>

Luckily we won't have to enter a long debate as some has been formalized 
already here: https://mojo.redhat.com/docs/DOC-65954 ;)

(Sorry it's an internal document)

Thomas


On 01/28/2015 12:57 PM, Lucas Ponce wrote:
> And what about the logging packages ?
>
>> import org.jboss.logging.*;
> vs
>
> import org.slf4j.Logger;
> import org.slf4j.LoggerFactory;
>
> I personally vote for org.slf4j.
>
> I prefer a mix on option 1) and 2), a common numeration for codes, but each component can still using a specific acronym.
>
> That it can help better to follow traces/logs.
>
> Also, this point can be discussed later, but is there any convention for debug, like this one:
>
>          if (LOG.isDebugEnabled()) {
>              LOG.debug("Message received: [{}]", msg);
>          }
>
> I mean, I like to use DEBUG for verbosity, but to reduce performance penalty, we can discuss a common approach.
>
> Above one is just a suggestion.
>
> Thanks,
> Lucas
>
>
> ----- Original Message -----
>> From: "Heiko W.Rupp" <hrupp at redhat.com>
>> To: hawkular-dev at lists.jboss.org
>> Sent: Wednesday, January 28, 2015 12:48:26 PM
>> Subject: [Hawkular-dev] Logging ...
>>
>> Hey,
>>
>> We should / need to start using logging codes just like Wildfly does.
>>
>> 11:19:27,714 INFO  [org.wildfly.extension.io] (ServerService Thread Pool --
>> 31) WFLYIO001: Worker 'default' has auto-configured to 8 core threads with
>> 64 task threads based on your 4 available processors
>> 11:19:27,716 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread
>> Pool -- 32) JBAS010280: Activating Infinispan subsystem.
>>
>> We have two options here
>>
>> 1)
>> We  use "HAWK" as our prefix and the following  code ranges initially
>>
>> 0-999  Hawkular (integration)
>> 1000-1999 Hawkular-Metrics
>> 2000-2999 Hawkular-Alerts (notifiers should probably be broken out in
>> separate blocks)
>> 3000-3999 Hawkular-Inventory
>> 4000-4999 Hawkular-Bus
>>
>> 2)
>> We use a prefix per component (e.g. HAWK, HKMET, HKAL, ...) and each
>> component has its own code range starting
>> at 0
>>
>> Personally I prefer option 1
>>
>> There is already documentation on this available
>>
>> 	? https://developer.jboss.org/wiki/HowToLogInJBossProjects
>> 	? https://developer.jboss.org/wiki/InternationalizedLoggingAndExceptions
>> 	? https://developer.jboss.org/wiki/JBossLoggingTooling
>>
>> While the documentation and examples look a bit complicated, I think we can
>> "reduce" them for
>> our purpose for Warnings and Errors and do not need them on debug/trace
>> level.
>> For info level I guess one should personal judgement (and then if it is not
>> important enough for
>> its own code, it is probably not really something at info, but rather at
>> debug level).
>>
>> In practice we would probably end up with something like:
>>
>> import org.jboss.logging.*;
>> public interface RestApiLogger {
>>
>>      RestApiLogger LOGGER =
>>      Logger.getMessageLogger(RestApiLogger.class,"org.hawkular.inventory.rest");
>>
>>      @LogMessage(level = Logger.Level.WARN)
>>      @Message(id = 3000, value = "Something bad has happened")
>>      void warn(@Cause Throwable t);
>>
>>    < plus much more refined messages here >
>> }
>>
>> and then in code
>>
>> } catch (Exception e) {
>>      RestApiLogger.LOGGER.warn(e);
>>      return Response.serverError().entity(e).build();
>> }
>>
>>
>>
>> --
>> Reg. Adresse: Red Hat GmbH, Technopark II, Haus C,
>> Werner-von-Siemens-Ring 14, D-85630 Grasbrunn
>> Handelsregister: Amtsgericht M?nchen HRB 153243
>> Gesch?ftsf?hrer: Charles Cachera, Michael Cunningham, Paul Hickey, Charlie
>> Peters
>>
>>
>> _______________________________________________
>> 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  Wed Jan 28 07:47:41 2015
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Wed, 28 Jan 2015 13:47:41 +0100
Subject: [Hawkular-dev] Logging ...
In-Reply-To: <1401520273.2306861.1422446239726.JavaMail.zimbra@redhat.com>
References: <F23B80F3-E163-4A25-94FD-AAB67FA66648@redhat.com>
	<1401520273.2306861.1422446239726.JavaMail.zimbra@redhat.com>
Message-ID: <E098DE23-987E-49F7-BB90-4B670D320D8B@redhat.com>


> Am 28.01.2015 um 12:57 schrieb Lucas Ponce <lponce at redhat.com>:
> Also, this point can be discussed later, but is there any convention for debug, like this one: 
> 
>        if (LOG.isDebugEnabled()) {
>            LOG.debug("Message received: [{}]", msg);
>        }
> 
> I mean, I like to use DEBUG for verbosity, but to reduce performance penalty, we can discuss a common approach.

Isn't that relatively common usage anyway?
Seriously - if some code has dozens of ifDebugEnabled() calls, it may make
a lot of sense to factor that out to the start of the method or even in to the constructor
so that this goes    if (isDebug) ... { log.debug() } 

Or do you mean the usage of the ugly uppercase LOG variable :-)?

From lponce at redhat.com  Wed Jan 28 08:33:09 2015
From: lponce at redhat.com (Lucas Ponce)
Date: Wed, 28 Jan 2015 08:33:09 -0500 (EST)
Subject: [Hawkular-dev] Logging ...
In-Reply-To: <E098DE23-987E-49F7-BB90-4B670D320D8B@redhat.com>
References: <F23B80F3-E163-4A25-94FD-AAB67FA66648@redhat.com>
	<1401520273.2306861.1422446239726.JavaMail.zimbra@redhat.com>
	<E098DE23-987E-49F7-BB90-4B670D320D8B@redhat.com>
Message-ID: <706083138.2398975.1422451989074.JavaMail.zimbra@redhat.com>


> > Am 28.01.2015 um 12:57 schrieb Lucas Ponce <lponce at redhat.com>:
> > Also, this point can be discussed later, but is there any convention for
> > debug, like this one:
> > 
> >        if (LOG.isDebugEnabled()) {
> >            LOG.debug("Message received: [{}]", msg);
> >        }
> > 
> > I mean, I like to use DEBUG for verbosity, but to reduce performance
> > penalty, we can discuss a common approach.
> 
> Isn't that relatively common usage anyway?
> Seriously - if some code has dozens of ifDebugEnabled() calls, it may make
> a lot of sense to factor that out to the start of the method or even in to
> the constructor
> so that this goes    if (isDebug) ... { log.debug() }

+1

> 
> Or do you mean the usage of the ugly uppercase LOG variable :-)?

I don't have any preference ussing log, _log, LOG, or whatever :-) just asking what is the preferred nomenclature, or if these things are in some doc that probably I missed.

Thx.

> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> 

From mazz at redhat.com  Wed Jan 28 11:26:18 2015
From: mazz at redhat.com (John Mazzitelli)
Date: Wed, 28 Jan 2015 11:26:18 -0500 (EST)
Subject: [Hawkular-dev] Logging ...
In-Reply-To: <706083138.2398975.1422451989074.JavaMail.zimbra@redhat.com>
References: <F23B80F3-E163-4A25-94FD-AAB67FA66648@redhat.com>
	<1401520273.2306861.1422446239726.JavaMail.zimbra@redhat.com>
	<E098DE23-987E-49F7-BB90-4B670D320D8B@redhat.com>
	<706083138.2398975.1422451989074.JavaMail.zimbra@redhat.com>
Message-ID: <650169041.2530204.1422462378834.JavaMail.zimbra@redhat.com>

This page shows how you can put this in your pom.xml to process the message bundles:

https://developer.jboss.org/wiki/JBossLoggingTooling#jive_content_id_mavenprocessorplugin

And this is a good snippet that shows how org.jboss.logging is used:

@MessageLogger("JBREM")  
public interface MyLogger {  
   @Message(id = 1, value = "JBoss Remoting version %s")  
   @LogMessage(level = INFO)  
   void greet(String version);  
  
   @Message(id = 2, value = "Error connecting from %s to %s: %s")  
   @LogMessage(level = ERROR)  
   void connectionError(SocketAddress src, SocketAddress dst, String reason);  
  
   // trace stuff has different restrictions  
   @Message(value = "Connection established from %s to %s")  
   @LogMessage(level = TRACE)  
   void connectionEstablished(SocketAddress src, SocketAddress dst);  

    // THIS SHOWS USING @Cause
    @LogMessage(level = Level.ERROR)
    @Message(id = 3, value = "Error Message: %s")
    void errorWithCause(@Cause Throwable cause, String error);
}  
  
public class Foo   
{  
  MyLogger log;  
  
  static  
  {  
   log = Logger.getMessageLogger(MyLogger.class, "org.jboss.remoting"); // defaults to current locale  
   log.greet(getVersionString());  
   // etc.  
  }  
}  

From tsegismo at redhat.com  Thu Jan 29 06:20:08 2015
From: tsegismo at redhat.com (Thomas Segismont)
Date: Thu, 29 Jan 2015 12:20:08 +0100
Subject: [Hawkular-dev] Should Keycloak integration be optional?
In-Reply-To: <54C79ECF.7020109@redhat.com>
References: <54C28AE2.3010509@redhat.com>
	<54C601D9.9030102@redhat.com>	<54C75B94.8080103@redhat.com>
	<54C79ECF.7020109@redhat.com>
Message-ID: <54CA1768.8050105@redhat.com>

Hi Juca,

Le 27/01/2015 15:21, Juraci Paix?o Kr?hling a ?crit :
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 01/27/2015 10:34 AM, Thomas Segismont wrote:
>> Le 26/01/2015 09:59, Thomas Heute a ?crit :
>>> In terms of priority, we should focus on Hawkular (not just
>>> metrics)
>>
>> Agreed
>>
>>> with Keycloak support and having it optional is not the
>>> priority.
>>
>> Some more context maybe. I asked the question during the hangout
>> and here's why. The PR as-is makes it impossible: * to start a
>> development container without KC * to run tests/integration tests
>> without KC * to install a metrics server without KC
>
> While I agree that an optional KC would make the above points easier,
> I'm failing to see the concrete advantages that it would bring,

Here is a concrete advantage: not being dependent on KC to run a metrics 
server. More below.

> specially considering that the main code will depend on features that
> KC is today bringing (multi tenancy security, for one).
>

After your demo, my understanding was as follows.

1. In terms of APIs, the main code would depend on JAAS rather than KC 
(/@RolesAllowed/ and inspection of a /Subject/ for custom interceptors).

So the good news is that we don't have to implement a pluggable 
identity/authorization tool, it's already there, it's JAAS. And KC is a 
possible backend.

2. With the exception of the console, the impact of making KC optional 
is limited to:
* making the build process create two artifacts for the rest-servlet 
module, one WAR with KC configured in the web.xml, another WAR with 
"classic" security definitions
* creating a JAAS login module to lookup for tenants, users, roles, in a 
simple properties file (or a couple of them).
* finding a way for running the REST integration tests with and without 
KC enabled

As for the console project, I understood that it is considered a 
facility for users of the sole metrics project, not a base for the 
future Hawkular suite. I'd be fine if, for now, it only supported 
basic/digest auth.

> For instance, to start a development environment, one can run the
> start.sh script that currently takes care of installing Wildfly and
> Cassandra. With the PR, KC is added to this mix.
>
> About the integration tests, I'd argue that the correct way to run the
> integration tests is with the security framework enabled, whatever
> this framework is. The reason being that this framework (plus the
> container itself) would provide tenant information to the target code.
> What we have on the PR is exactly this: the tests know nothing about
> KC, the target code knows nothing about KC, but KC is installed on the
> container and provides user information to the target code (or blocks
> the request, if the wrong credentials are provided). For tests where
> no tenant-specific logic is performed, a common credential can be used
> for all tests, which would make more sense than disabling the security
> framework for those tests.

See my answer above about integration tests impact.

>
> I'm not sure what you mean in your last point, though.

My last point was "The PR makes it impossible to install a metrics 
server without KC". I meant that if one needs to configure and run a KC 
server in order to run a metrics server, then many potential users will 
not even give it a try. Potential users here are admins and 
production-focused developers who are working with combos like 
Grafana/Graphite/collectd

Even if "metrics server alone" on its own is not the team's top 
priority, I think it should remain *a* priority, for the reason I've 
just given.

>
>>  From my perspective, that's important enough to consider making it
>> or optional or holding the merge to let us think more about the
>> problem.
>>
>
> Indeed! I think discussing this at this phase is critical, so that we
> can get into a consensus about the expectations :-)

True, and thanks for having patiently awaited my reply ;)

>
> - - Juca.

Thomas

From tsegismo at redhat.com  Thu Jan 29 08:38:02 2015
From: tsegismo at redhat.com (Thomas Segismont)
Date: Thu, 29 Jan 2015 14:38:02 +0100
Subject: [Hawkular-dev] Logging ...
In-Reply-To: <E098DE23-987E-49F7-BB90-4B670D320D8B@redhat.com>
References: <F23B80F3-E163-4A25-94FD-AAB67FA66648@redhat.com>	<1401520273.2306861.1422446239726.JavaMail.zimbra@redhat.com>
	<E098DE23-987E-49F7-BB90-4B670D320D8B@redhat.com>
Message-ID: <54CA37BA.4050202@redhat.com>

Le 28/01/2015 13:47, Heiko W.Rupp a ?crit :
>
>> Am 28.01.2015 um 12:57 schrieb Lucas Ponce <lponce at redhat.com>:
>> Also, this point can be discussed later, but is there any convention for debug, like this one:
>>
>>         if (LOG.isDebugEnabled()) {
>>             LOG.debug("Message received: [{}]", msg);
>>         }
>>
>> I mean, I like to use DEBUG for verbosity, but to reduce performance penalty, we can discuss a common approach.
>
> Isn't that relatively common usage anyway?
> Seriously - if some code has dozens of ifDebugEnabled() calls, it may make
> a lot of sense to factor that out to the start of the method or even in to the constructor
> so that this goes    if (isDebug) ... { log.debug() }
>

As far as I understand this logging framework, parameters of the message 
should be defined as parameters of a method in the logging interface 
annotated with @MessageLogger. The method should define the logging level.

If my assumption is correct, then in most cases the #isXXXEnabled calls 
can be avoided, as their purpose is to guard calls to #toString and 
String concatenation.

Pursuing with Lucas' example, it should look like this:

     MessagingLogger.LOGGER.messageReceived(msg);

With MessagingLogger looking like:

@MessageLogger(projectCode = "HAWK")
interface MessagingLogger extends BasicLogger {


     /**
      * The default logger.
      */
     MessagingLogger LOGGER = ...;


     @LogMessage(level = Level.DEBUG)
     @Message(id = 1, value = "Message received: %s")
     void messageReceived(String msg);

}

> Or do you mean the usage of the ugly uppercase LOG variable :-)?

Ugly is certainly a matter of taste :p

From jshaughn at redhat.com  Thu Jan 29 09:32:59 2015
From: jshaughn at redhat.com (Jay Shaughnessy)
Date: Thu, 29 Jan 2015 09:32:59 -0500
Subject: [Hawkular-dev] Logging ...
In-Reply-To: <54CA37BA.4050202@redhat.com>
References: <F23B80F3-E163-4A25-94FD-AAB67FA66648@redhat.com>	<1401520273.2306861.1422446239726.JavaMail.zimbra@redhat.com>	<E098DE23-987E-49F7-BB90-4B670D320D8B@redhat.com>
	<54CA37BA.4050202@redhat.com>
Message-ID: <54CA449B.9030105@redhat.com>


By passing parameters to the message methods we defer to the generated 
method impl the String concatenation involved in merging the parameters 
with the static text.  If String concatenation is the only extra work 
being done for debug messages then we don't need any isDebugEnabled() 
wrapping logic.  But if it is not, meaning we need to do extra work to 
generate those parameters, or if we want to conditionally execute any 
other logic, we'll want to use the isDebugEnabled() wrapping.

The thing that bothers me in this design is the log level annotation 
being located with the message definition and not the logging command.  
It's very convenient to scan code and see what is being logged at what 
level.  You may all hate the idea, but I wonder if the message method 
names should incorporate a prefix with the log level.  So, something like:

      @LogMessage(level = Level.DEBUG)
      @Message(id = 1, value = "Message received: %s")
      void dMessageReceived(String msg);

Using prefixes of  't', 'd', 'i', 'w', 'e', 'f' may make the code-read 
more obvious.  Just a thought.

Oh, And I'd vote for "Log" as opposed to all upper or lower ( "LOGGER", 
"LOG", "log") but I don't really care.


On 1/29/2015 8:38 AM, Thomas Segismont wrote:
> Le 28/01/2015 13:47, Heiko W.Rupp a ?crit :
>>> Am 28.01.2015 um 12:57 schrieb Lucas Ponce <lponce at redhat.com>:
>>> Also, this point can be discussed later, but is there any convention for debug, like this one:
>>>
>>>          if (LOG.isDebugEnabled()) {
>>>              LOG.debug("Message received: [{}]", msg);
>>>          }
>>>
>>> I mean, I like to use DEBUG for verbosity, but to reduce performance penalty, we can discuss a common approach.
>> Isn't that relatively common usage anyway?
>> Seriously - if some code has dozens of ifDebugEnabled() calls, it may make
>> a lot of sense to factor that out to the start of the method or even in to the constructor
>> so that this goes    if (isDebug) ... { log.debug() }
>>
> As far as I understand this logging framework, parameters of the message
> should be defined as parameters of a method in the logging interface
> annotated with @MessageLogger. The method should define the logging level.
>
> If my assumption is correct, then in most cases the #isXXXEnabled calls
> can be avoided, as their purpose is to guard calls to #toString and
> String concatenation.
>
> Pursuing with Lucas' example, it should look like this:
>
>       MessagingLogger.LOGGER.messageReceived(msg);
>
> With MessagingLogger looking like:
>
> @MessageLogger(projectCode = "HAWK")
> interface MessagingLogger extends BasicLogger {
>
>
>       /**
>        * The default logger.
>        */
>       MessagingLogger LOGGER = ...;
>
>
>       @LogMessage(level = Level.DEBUG)
>       @Message(id = 1, value = "Message received: %s")
>       void messageReceived(String msg);
>
> }
>
>> Or do you mean the usage of the ugly uppercase LOG variable :-)?
> Ugly is certainly a matter of taste :p
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>
>


From ppalaga at redhat.com  Thu Jan 29 11:04:35 2015
From: ppalaga at redhat.com (Peter Palaga)
Date: Thu, 29 Jan 2015 17:04:35 +0100
Subject: [Hawkular-dev] Logging ...
In-Reply-To: <54CA449B.9030105@redhat.com>
References: <F23B80F3-E163-4A25-94FD-AAB67FA66648@redhat.com>	<1401520273.2306861.1422446239726.JavaMail.zimbra@redhat.com>	<E098DE23-987E-49F7-BB90-4B670D320D8B@redhat.com>	<54CA37BA.4050202@redhat.com>
	<54CA449B.9030105@redhat.com>
Message-ID: <54CA5A13.3030804@redhat.com>

Hi *, inline...

On 01/29/2015 03:32 PM, Jay Shaughnessy wrote:
>
> By passing parameters to the message methods we defer to the generated
> method impl the String concatenation involved in merging the parameters
> with the static text.  If String concatenation is the only extra work
> being done for debug messages then we don't need any isDebugEnabled()
> wrapping logic.  But if it is not, meaning we need to do extra work to
> generate those parameters, or if we want to conditionally execute any
> other logic, we'll want to use the isDebugEnabled() wrapping.

Yes, jboss logging was designed with performance in mind. The expensive 
merging of the message template with params is not performed for 
disabled levels and there are no expensive varargs in game (never? or 
just typically?). There was a thread on thecore about this some time ago.

Therefore, one can omit log.isXXXenabled() if there is no extra work to 
generate those parameters as noted by Jay.


> The thing that bothers me in this design is the log level annotation
> being located with the message definition and not the logging command.
> It's very convenient to scan code and see what is being logged at what
> level.  You may all hate the idea, but I wonder if the message method
> names should incorporate a prefix with the log level.  So, something like:
>
>        @LogMessage(level = Level.DEBUG)
>        @Message(id = 1, value = "Message received: %s")
>        void dMessageReceived(String msg);
>
> Using prefixes of  't', 'd', 'i', 'w', 'e', 'f' may make the code-read
> more obvious.  Just a thought.

+1 I find such prefixes handy.
I'd even personaly vote for longer versions like 
debugMessageReceived(String msg);

> Oh, And I'd vote for "Log" as opposed to all upper or lower ( "LOGGER",
> "LOG", "log") but I don't really care.

No, CamelCase is reserved for class names in Java.
LOG is a natural choice for a static final field, but it is not really a 
constant.
log is best, IMO.

-- Peter

> On 1/29/2015 8:38 AM, Thomas Segismont wrote:
>> Le 28/01/2015 13:47, Heiko W.Rupp a ?crit :
>>>> Am 28.01.2015 um 12:57 schrieb Lucas Ponce <lponce at redhat.com>:
>>>> Also, this point can be discussed later, but is there any convention for debug, like this one:
>>>>
>>>>           if (LOG.isDebugEnabled()) {
>>>>               LOG.debug("Message received: [{}]", msg);
>>>>           }
>>>>
>>>> I mean, I like to use DEBUG for verbosity, but to reduce performance penalty, we can discuss a common approach.
>>> Isn't that relatively common usage anyway?
>>> Seriously - if some code has dozens of ifDebugEnabled() calls, it may make
>>> a lot of sense to factor that out to the start of the method or even in to the constructor
>>> so that this goes    if (isDebug) ... { log.debug() }
>>>
>> As far as I understand this logging framework, parameters of the message
>> should be defined as parameters of a method in the logging interface
>> annotated with @MessageLogger. The method should define the logging level.
>>
>> If my assumption is correct, then in most cases the #isXXXEnabled calls
>> can be avoided, as their purpose is to guard calls to #toString and
>> String concatenation.
>>
>> Pursuing with Lucas' example, it should look like this:
>>
>>        MessagingLogger.LOGGER.messageReceived(msg);
>>
>> With MessagingLogger looking like:
>>
>> @MessageLogger(projectCode = "HAWK")
>> interface MessagingLogger extends BasicLogger {
>>
>>
>>        /**
>>         * The default logger.
>>         */
>>        MessagingLogger LOGGER = ...;
>>
>>
>>        @LogMessage(level = Level.DEBUG)
>>        @Message(id = 1, value = "Message received: %s")
>>        void messageReceived(String msg);
>>
>> }
>>
>>> Or do you mean the usage of the ugly uppercase LOG variable :-)?
>> Ugly is certainly a matter of taste :p
>> _______________________________________________
>> 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 jshaughn at redhat.com  Thu Jan 29 11:07:51 2015
From: jshaughn at redhat.com (Jay Shaughnessy)
Date: Thu, 29 Jan 2015 08:07:51 -0800
Subject: [Hawkular-dev] [hawkular/hawkular-alerts] 88f4f1: HWKALERTS-1
 Prepare an initial version
Message-ID: <54ca5ad791882_69283f93433eb2bc792aa@hookshot-fe3-cp1-prd.iad.github.net.mail>

  Branch: refs/heads/master
  Home:   https://github.com/hawkular/hawkular-alerts
  Commit: 88f4f1ff84345f380b11455331437b722867ac27
      https://github.com/hawkular/hawkular-alerts/commit/88f4f1ff84345f380b11455331437b722867ac27
  Author: Lucas Ponce <ponce.ballesteros at gmail.com>
  Date:   2015-01-29 (Thu, 29 Jan 2015)

  Changed paths:
    M .gitignore
    A README.adoc
    A examples/example-alerts-ui/pom.xml
    A examples/example-alerts-ui/src/main/webapp/WEB-INF/jboss-web.xml
    A examples/example-alerts-ui/src/main/webapp/WEB-INF/web.xml
    A examples/example-alerts-ui/src/main/webapp/index.jsp
    A hawkular-alerts-api/pom.xml
    A hawkular-alerts-api/src/main/java/org/hawkular/alerts/api/model/condition/Alert.java
    A hawkular-alerts-api/src/main/java/org/hawkular/alerts/api/model/condition/AvailabilityCondition.java
    A hawkular-alerts-api/src/main/java/org/hawkular/alerts/api/model/condition/AvailabilityConditionEval.java
    A hawkular-alerts-api/src/main/java/org/hawkular/alerts/api/model/condition/CompareCondition.java
    A hawkular-alerts-api/src/main/java/org/hawkular/alerts/api/model/condition/CompareConditionEval.java
    A hawkular-alerts-api/src/main/java/org/hawkular/alerts/api/model/condition/Condition.java
    A hawkular-alerts-api/src/main/java/org/hawkular/alerts/api/model/condition/ConditionEval.java
    A hawkular-alerts-api/src/main/java/org/hawkular/alerts/api/model/condition/StringCondition.java
    A hawkular-alerts-api/src/main/java/org/hawkular/alerts/api/model/condition/StringConditionEval.java
    A hawkular-alerts-api/src/main/java/org/hawkular/alerts/api/model/condition/ThresholdCondition.java
    A hawkular-alerts-api/src/main/java/org/hawkular/alerts/api/model/condition/ThresholdConditionEval.java
    A hawkular-alerts-api/src/main/java/org/hawkular/alerts/api/model/condition/ThresholdRangeCondition.java
    A hawkular-alerts-api/src/main/java/org/hawkular/alerts/api/model/condition/ThresholdRangeConditionEval.java
    A hawkular-alerts-api/src/main/java/org/hawkular/alerts/api/model/dampening/Dampening.java
    A hawkular-alerts-api/src/main/java/org/hawkular/alerts/api/model/data/Availability.java
    A hawkular-alerts-api/src/main/java/org/hawkular/alerts/api/model/data/Data.java
    A hawkular-alerts-api/src/main/java/org/hawkular/alerts/api/model/data/NumericData.java
    A hawkular-alerts-api/src/main/java/org/hawkular/alerts/api/model/data/StringData.java
    A hawkular-alerts-api/src/main/java/org/hawkular/alerts/api/model/notification/Notification.java
    A hawkular-alerts-api/src/main/java/org/hawkular/alerts/api/model/trigger/Trigger.java
    A hawkular-alerts-api/src/main/java/org/hawkular/alerts/api/model/trigger/TriggerTemplate.java
    A hawkular-alerts-api/src/main/java/org/hawkular/alerts/api/services/AlertsService.java
    A hawkular-alerts-api/src/main/java/org/hawkular/alerts/api/services/DefinitionsService.java
    A hawkular-alerts-api/src/main/java/org/hawkular/alerts/api/services/NotificationsService.java
    A hawkular-alerts-api/src/main/java/org/hawkular/alerts/api/services/NotifierListener.java
    A hawkular-alerts-bus/pom.xml
    A hawkular-alerts-bus/src/main/java/org/hawkular/alerts/bus/init/AlertEngineRegister.java
    A hawkular-alerts-bus/src/main/java/org/hawkular/alerts/bus/listener/AlertDataListener.java
    A hawkular-alerts-bus/src/main/java/org/hawkular/alerts/bus/listener/NotifierTypeListener.java
    A hawkular-alerts-bus/src/main/java/org/hawkular/alerts/bus/messages/AlertData.java
    A hawkular-alerts-bus/src/main/java/org/hawkular/alerts/bus/messages/AlertDataMessage.java
    A hawkular-alerts-bus/src/main/java/org/hawkular/alerts/bus/sender/NotificationSender.java
    A hawkular-alerts-ear/pom.xml
    A hawkular-alerts-ear/src/main/application/META-INF/jboss-deployment-structure.xml
    A hawkular-alerts-engine/pom.xml
    A hawkular-alerts-engine/src/main/java/org/hawkular/alerts/engine/impl/BasicAlertsServiceImpl.java
    A hawkular-alerts-engine/src/main/java/org/hawkular/alerts/engine/impl/DroolsRulesEngineImpl.java
    A hawkular-alerts-engine/src/main/java/org/hawkular/alerts/engine/impl/MemDefinitionsServiceImpl.java
    A hawkular-alerts-engine/src/main/java/org/hawkular/alerts/engine/impl/MemNotificationsServiceImpl.java
    A hawkular-alerts-engine/src/main/java/org/hawkular/alerts/engine/rules/RulesEngine.java
    A hawkular-alerts-engine/src/main/resources/META-INF/kmodule.xml
    A hawkular-alerts-engine/src/main/resources/META-INF/maven/pom.properties
    A hawkular-alerts-engine/src/main/resources/hawkular-alerts/conditions.data
    A hawkular-alerts-engine/src/main/resources/hawkular-alerts/dampening.data
    A hawkular-alerts-engine/src/main/resources/hawkular-alerts/notifiers.data
    A hawkular-alerts-engine/src/main/resources/hawkular-alerts/triggers.data
    A hawkular-alerts-engine/src/main/resources/org/hawkular/alerts/engine/rules/ConditionMatch.drl
    A hawkular-alerts-engine/src/test/java/org/hawkular/alerts/engine/RulesEngineTest.java
    A hawkular-alerts-engine/src/test/resources/simplelogger.properties
    A hawkular-alerts-rest/pom.xml
    A hawkular-alerts-rest/src/main/java/org/hawkular/alerts/rest/AlertsHandler.java
    A hawkular-alerts-rest/src/main/java/org/hawkular/alerts/rest/HawkularAlertsApp.java
    A hawkular-alerts-rest/src/main/java/org/hawkular/alerts/rest/NotificationHandler.java
    A hawkular-alerts-rest/src/main/java/org/hawkular/alerts/rest/TriggersHandler.java
    A hawkular-alerts-rest/src/main/webapp/WEB-INF/beans.xml
    A hawkular-alerts-rest/src/main/webapp/WEB-INF/jboss-web.xml
    A hawkular-alerts-rest/src/main/webapp/WEB-INF/web.xml
    A hawkular-alerts-rest/src/main/webapp/index.jsp
    A hawkular-notifiers-api/pom.xml
    A hawkular-notifiers-api/src/main/java/org/hawkular/notifiers/api/model/NotificationMessage.java
    A hawkular-notifiers-api/src/main/java/org/hawkular/notifiers/api/model/NotifierRegistrationMessage.java
    A hawkular-notifiers-api/src/main/java/org/hawkular/notifiers/api/model/NotifierTypeRegistrationMessage.java
    A hawkular-notifiers-email/pom.xml
    A hawkular-notifiers-email/src/main/java/org/hawkular/notifiers/email/notifications/EmailListener.java
    A hawkular-notifiers-email/src/main/java/org/hawkular/notifiers/email/registration/RegisterListener.java
    A hawkular-notifiers-email/src/main/java/org/hawkular/notifiers/email/registration/RegistrationInit.java
    A hawkular-notifiers-email/src/main/webapp/WEB-INF/jboss-deployment-structure.xml
    A hawkular-notifiers-email/src/main/webapp/WEB-INF/jboss-web.xml
    A hawkular-notifiers-email/src/main/webapp/WEB-INF/web.xml
    A hawkular-notifiers-email/src/main/webapp/index.jsp
    A hawkular-notifiers-sms/pom.xml
    A hawkular-notifiers-sms/src/main/java/org/hawkular/notifiers/sms/notifications/SmsListener.java
    A hawkular-notifiers-sms/src/main/java/org/hawkular/notifiers/sms/registration/RegisterListener.java
    A hawkular-notifiers-sms/src/main/java/org/hawkular/notifiers/sms/registration/RegistrationInit.java
    A hawkular-notifiers-sms/src/main/webapp/WEB-INF/jboss-deployment-structure.xml
    A hawkular-notifiers-sms/src/main/webapp/WEB-INF/jboss-web.xml
    A hawkular-notifiers-sms/src/main/webapp/WEB-INF/web.xml
    A hawkular-notifiers-sms/src/main/webapp/index.jsp
    A hawkular-notifiers-snmp/pom.xml
    A hawkular-notifiers-snmp/src/main/java/org/hawkular/notifiers/snmp/notifications/SnmpListener.java
    A hawkular-notifiers-snmp/src/main/java/org/hawkular/notifiers/snmp/registration/RegisterListener.java
    A hawkular-notifiers-snmp/src/main/java/org/hawkular/notifiers/snmp/registration/RegistrationInit.java
    A hawkular-notifiers-snmp/src/main/webapp/WEB-INF/jboss-deployment-structure.xml
    A hawkular-notifiers-snmp/src/main/webapp/WEB-INF/jboss-web.xml
    A hawkular-notifiers-snmp/src/main/webapp/WEB-INF/web.xml
    A hawkular-notifiers-snmp/src/main/webapp/index.jsp
    A pom.xml

  Log Message:
  -----------
  HWKALERTS-1 Prepare an initial version


  Commit: a0312d4026d9563ca9886d7107e97b75bc7d0732
      https://github.com/hawkular/hawkular-alerts/commit/a0312d4026d9563ca9886d7107e97b75bc7d0732
  Author: Jay Shaughnessy <jshaughn at redhat.com>
  Date:   2015-01-29 (Thu, 29 Jan 2015)

  Changed paths:
    M .gitignore
    A README.adoc
    A examples/example-alerts-ui/pom.xml
    A examples/example-alerts-ui/src/main/webapp/WEB-INF/jboss-web.xml
    A examples/example-alerts-ui/src/main/webapp/WEB-INF/web.xml
    A examples/example-alerts-ui/src/main/webapp/index.jsp
    A hawkular-alerts-api/pom.xml
    A hawkular-alerts-api/src/main/java/org/hawkular/alerts/api/model/condition/Alert.java
    A hawkular-alerts-api/src/main/java/org/hawkular/alerts/api/model/condition/AvailabilityCondition.java
    A hawkular-alerts-api/src/main/java/org/hawkular/alerts/api/model/condition/AvailabilityConditionEval.java
    A hawkular-alerts-api/src/main/java/org/hawkular/alerts/api/model/condition/CompareCondition.java
    A hawkular-alerts-api/src/main/java/org/hawkular/alerts/api/model/condition/CompareConditionEval.java
    A hawkular-alerts-api/src/main/java/org/hawkular/alerts/api/model/condition/Condition.java
    A hawkular-alerts-api/src/main/java/org/hawkular/alerts/api/model/condition/ConditionEval.java
    A hawkular-alerts-api/src/main/java/org/hawkular/alerts/api/model/condition/StringCondition.java
    A hawkular-alerts-api/src/main/java/org/hawkular/alerts/api/model/condition/StringConditionEval.java
    A hawkular-alerts-api/src/main/java/org/hawkular/alerts/api/model/condition/ThresholdCondition.java
    A hawkular-alerts-api/src/main/java/org/hawkular/alerts/api/model/condition/ThresholdConditionEval.java
    A hawkular-alerts-api/src/main/java/org/hawkular/alerts/api/model/condition/ThresholdRangeCondition.java
    A hawkular-alerts-api/src/main/java/org/hawkular/alerts/api/model/condition/ThresholdRangeConditionEval.java
    A hawkular-alerts-api/src/main/java/org/hawkular/alerts/api/model/dampening/Dampening.java
    A hawkular-alerts-api/src/main/java/org/hawkular/alerts/api/model/data/Availability.java
    A hawkular-alerts-api/src/main/java/org/hawkular/alerts/api/model/data/Data.java
    A hawkular-alerts-api/src/main/java/org/hawkular/alerts/api/model/data/NumericData.java
    A hawkular-alerts-api/src/main/java/org/hawkular/alerts/api/model/data/StringData.java
    A hawkular-alerts-api/src/main/java/org/hawkular/alerts/api/model/notification/Notification.java
    A hawkular-alerts-api/src/main/java/org/hawkular/alerts/api/model/trigger/Trigger.java
    A hawkular-alerts-api/src/main/java/org/hawkular/alerts/api/model/trigger/TriggerTemplate.java
    A hawkular-alerts-api/src/main/java/org/hawkular/alerts/api/services/AlertsService.java
    A hawkular-alerts-api/src/main/java/org/hawkular/alerts/api/services/DefinitionsService.java
    A hawkular-alerts-api/src/main/java/org/hawkular/alerts/api/services/NotificationsService.java
    A hawkular-alerts-api/src/main/java/org/hawkular/alerts/api/services/NotifierListener.java
    A hawkular-alerts-bus/pom.xml
    A hawkular-alerts-bus/src/main/java/org/hawkular/alerts/bus/init/AlertEngineRegister.java
    A hawkular-alerts-bus/src/main/java/org/hawkular/alerts/bus/listener/AlertDataListener.java
    A hawkular-alerts-bus/src/main/java/org/hawkular/alerts/bus/listener/NotifierTypeListener.java
    A hawkular-alerts-bus/src/main/java/org/hawkular/alerts/bus/messages/AlertData.java
    A hawkular-alerts-bus/src/main/java/org/hawkular/alerts/bus/messages/AlertDataMessage.java
    A hawkular-alerts-bus/src/main/java/org/hawkular/alerts/bus/sender/NotificationSender.java
    A hawkular-alerts-ear/pom.xml
    A hawkular-alerts-ear/src/main/application/META-INF/jboss-deployment-structure.xml
    A hawkular-alerts-engine/pom.xml
    A hawkular-alerts-engine/src/main/java/org/hawkular/alerts/engine/impl/BasicAlertsServiceImpl.java
    A hawkular-alerts-engine/src/main/java/org/hawkular/alerts/engine/impl/DroolsRulesEngineImpl.java
    A hawkular-alerts-engine/src/main/java/org/hawkular/alerts/engine/impl/MemDefinitionsServiceImpl.java
    A hawkular-alerts-engine/src/main/java/org/hawkular/alerts/engine/impl/MemNotificationsServiceImpl.java
    A hawkular-alerts-engine/src/main/java/org/hawkular/alerts/engine/rules/RulesEngine.java
    A hawkular-alerts-engine/src/main/resources/META-INF/kmodule.xml
    A hawkular-alerts-engine/src/main/resources/META-INF/maven/pom.properties
    A hawkular-alerts-engine/src/main/resources/hawkular-alerts/conditions.data
    A hawkular-alerts-engine/src/main/resources/hawkular-alerts/dampening.data
    A hawkular-alerts-engine/src/main/resources/hawkular-alerts/notifiers.data
    A hawkular-alerts-engine/src/main/resources/hawkular-alerts/triggers.data
    A hawkular-alerts-engine/src/main/resources/org/hawkular/alerts/engine/rules/ConditionMatch.drl
    A hawkular-alerts-engine/src/test/java/org/hawkular/alerts/engine/RulesEngineTest.java
    A hawkular-alerts-engine/src/test/resources/simplelogger.properties
    A hawkular-alerts-rest/pom.xml
    A hawkular-alerts-rest/src/main/java/org/hawkular/alerts/rest/AlertsHandler.java
    A hawkular-alerts-rest/src/main/java/org/hawkular/alerts/rest/HawkularAlertsApp.java
    A hawkular-alerts-rest/src/main/java/org/hawkular/alerts/rest/NotificationHandler.java
    A hawkular-alerts-rest/src/main/java/org/hawkular/alerts/rest/TriggersHandler.java
    A hawkular-alerts-rest/src/main/webapp/WEB-INF/beans.xml
    A hawkular-alerts-rest/src/main/webapp/WEB-INF/jboss-web.xml
    A hawkular-alerts-rest/src/main/webapp/WEB-INF/web.xml
    A hawkular-alerts-rest/src/main/webapp/index.jsp
    A hawkular-notifiers-api/pom.xml
    A hawkular-notifiers-api/src/main/java/org/hawkular/notifiers/api/model/NotificationMessage.java
    A hawkular-notifiers-api/src/main/java/org/hawkular/notifiers/api/model/NotifierRegistrationMessage.java
    A hawkular-notifiers-api/src/main/java/org/hawkular/notifiers/api/model/NotifierTypeRegistrationMessage.java
    A hawkular-notifiers-email/pom.xml
    A hawkular-notifiers-email/src/main/java/org/hawkular/notifiers/email/notifications/EmailListener.java
    A hawkular-notifiers-email/src/main/java/org/hawkular/notifiers/email/registration/RegisterListener.java
    A hawkular-notifiers-email/src/main/java/org/hawkular/notifiers/email/registration/RegistrationInit.java
    A hawkular-notifiers-email/src/main/webapp/WEB-INF/jboss-deployment-structure.xml
    A hawkular-notifiers-email/src/main/webapp/WEB-INF/jboss-web.xml
    A hawkular-notifiers-email/src/main/webapp/WEB-INF/web.xml
    A hawkular-notifiers-email/src/main/webapp/index.jsp
    A hawkular-notifiers-sms/pom.xml
    A hawkular-notifiers-sms/src/main/java/org/hawkular/notifiers/sms/notifications/SmsListener.java
    A hawkular-notifiers-sms/src/main/java/org/hawkular/notifiers/sms/registration/RegisterListener.java
    A hawkular-notifiers-sms/src/main/java/org/hawkular/notifiers/sms/registration/RegistrationInit.java
    A hawkular-notifiers-sms/src/main/webapp/WEB-INF/jboss-deployment-structure.xml
    A hawkular-notifiers-sms/src/main/webapp/WEB-INF/jboss-web.xml
    A hawkular-notifiers-sms/src/main/webapp/WEB-INF/web.xml
    A hawkular-notifiers-sms/src/main/webapp/index.jsp
    A hawkular-notifiers-snmp/pom.xml
    A hawkular-notifiers-snmp/src/main/java/org/hawkular/notifiers/snmp/notifications/SnmpListener.java
    A hawkular-notifiers-snmp/src/main/java/org/hawkular/notifiers/snmp/registration/RegisterListener.java
    A hawkular-notifiers-snmp/src/main/java/org/hawkular/notifiers/snmp/registration/RegistrationInit.java
    A hawkular-notifiers-snmp/src/main/webapp/WEB-INF/jboss-deployment-structure.xml
    A hawkular-notifiers-snmp/src/main/webapp/WEB-INF/jboss-web.xml
    A hawkular-notifiers-snmp/src/main/webapp/WEB-INF/web.xml
    A hawkular-notifiers-snmp/src/main/webapp/index.jsp
    A pom.xml

  Log Message:
  -----------
  Merge pull request #1 from lucasponce/Initial-Import

HWKALERTS-1 Prepare an initial version


Compare: https://github.com/hawkular/hawkular-alerts/compare/3436f14c5fe1...a0312d4026d9

From jpkroehling at redhat.com  Thu Jan 29 11:08:29 2015
From: jpkroehling at redhat.com (=?windows-1252?Q?Juraci_Paix=E3o_Kr=F6hling?=)
Date: Thu, 29 Jan 2015 17:08:29 +0100
Subject: [Hawkular-dev] Should Keycloak integration be optional?
In-Reply-To: <54CA1768.8050105@redhat.com>
References: <54C28AE2.3010509@redhat.com>	<54C601D9.9030102@redhat.com>	<54C75B94.8080103@redhat.com>	<54C79ECF.7020109@redhat.com>
	<54CA1768.8050105@redhat.com>
Message-ID: <54CA5AFD.5010102@redhat.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/29/2015 12:20 PM, Thomas Segismont wrote:
> My last point was "The PR makes it impossible to install a metrics
>  server without KC". I meant that if one needs to configure and run
> a KC server in order to run a metrics server, then many potential
> users will not even give it a try. Potential users here are admins
> and production-focused developers who are working with combos like
>  Grafana/Graphite/collectd

Sorry for cutting the whole message to just this point, but before
talking about the other points, I just want to clarify one thing: the
 admin does *not* need to deal with KC at all when trying things out.
To run a metrics server, one just runs the start.sh and Keycloak just
happens to be there as an implementation detail.

Once the admin is ready to bring things to production, then Keycloak
becomes a "concern", like any other backend would be (LDAP, SAML, ...).

Since the demo, I've been looking at how other projects are
integrating with Keycloak. The common scenario seems to be that their
Maven profiles build a "distribution" that is Wildfly + Keycloak +
WARs. So, the user just uncompresses this distribution package and has
everything ready (this is similar to what we had in GateIn).

Would this be a solution? I remember seeing somewhere that the goal is
not to be dependent on Wildfly[1], but not sure if this design goal is
still accurate.

[1] https://developer.jboss.org/wiki/HighLevelRequirements

- - Juca.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJUylr9AAoJECKM1e+fkPrXi+IH/1yx0shsoKHMDTuCXK5daemJ
riAofGmvrYelzfW7udiIuZXKMo4EtDge/Vocw296Uq1HibNb30x99WifwegCcLmv
10j8DdDc9ljupaS2Ej1D8RAGEOg6KdCrFj9V1tlhDbeAR9fXAeWqADZqH+5kjYbU
in7ayb0XvYJGYio8eLGdcMXt1vjy2fxArt1Y2u6AOdA8O2wyVMDkJ/Xs5tEPdkP0
BfRn8NOZdrlSDKd4qeG8qVtRQI006f/b+2hT6UnOM7gnc6QetYbBvVTHn0ODBwUA
mSj+HXrQJ6RR6MCUxkIr0Woii3SdA3ZsIDdZugAY0sGo8bgRgLVJ+zrpsgn23a8=
=Rcql
-----END PGP SIGNATURE-----

From hrupp at redhat.com  Thu Jan 29 11:12:56 2015
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Thu, 29 Jan 2015 17:12:56 +0100
Subject: [Hawkular-dev] Logging ...
In-Reply-To: <54CA449B.9030105@redhat.com>
References: <F23B80F3-E163-4A25-94FD-AAB67FA66648@redhat.com>
	<1401520273.2306861.1422446239726.JavaMail.zimbra@redhat.com>
	<E098DE23-987E-49F7-BB90-4B670D320D8B@redhat.com>
	<54CA37BA.4050202@redhat.com> <54CA449B.9030105@redhat.com>
Message-ID: <D890B1E7-300D-4DA9-8C44-300853EA26DC@redhat.com>


> Am 29.01.2015 um 15:32 schrieb Jay Shaughnessy <jshaughn at redhat.com>:
> 
> The thing that bothers me in this design is the log level annotation 
> being located with the message definition and not the logging command.  
> It's very convenient to scan code and see what is being logged at what 
> level.  You may all hate the idea, but I wonder if the message method 


I guess that is why they seem to often introduce multiple loggers

Foo.DEBUG_LOGGER...
Foo.WARN_LOGGER...

We can / should ask James Perkins what his thinking is here.




From hrupp at redhat.com  Thu Jan 29 11:35:31 2015
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Thu, 29 Jan 2015 17:35:31 +0100
Subject: [Hawkular-dev] Logging ...
In-Reply-To: <54CA5A13.3030804@redhat.com>
References: <F23B80F3-E163-4A25-94FD-AAB67FA66648@redhat.com>
	<1401520273.2306861.1422446239726.JavaMail.zimbra@redhat.com>
	<E098DE23-987E-49F7-BB90-4B670D320D8B@redhat.com>
	<54CA37BA.4050202@redhat.com> <54CA449B.9030105@redhat.com>
	<54CA5A13.3030804@redhat.com>
Message-ID: <036B16EE-4481-4F01-B350-EB5EC61693DD@redhat.com>


> Am 29.01.2015 um 17:04 schrieb Peter Palaga <ppalaga at redhat.com>:

>> Using prefixes of  't', 'd', 'i', 'w', 'e', 'f' may make the code-read
>> more obvious.  Just a thought.
> 
> +1 I find such prefixes handy.
> I'd even personaly vote for longer versions like 
> debugMessageReceived(String msg);

An alternative could be to gather all messages of a Level in their own
interface and then have WarnLogger.LOG.foo() and DebugLogger.LOG.bar() 
and so on.

Or we go A$ and so on :)
> LOG is a natural choice for a static final field, but it is not really a 
> constant.
> log is best, IMO.

+1

Actually I don't care about the name that much as far as we do not change
them on each commit 


From jpkroehling at redhat.com  Thu Jan 29 12:22:04 2015
From: jpkroehling at redhat.com (=?UTF-8?B?SnVyYWNpIFBhaXjDo28gS3LDtmhsaW5n?=)
Date: Thu, 29 Jan 2015 18:22:04 +0100
Subject: [Hawkular-dev] define: tenant
Message-ID: <54CA6C3C.9080808@redhat.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

After the demo, I was looking for ways to improve the "realm selection
modal", but I keep hitting a problem with the definition of a
tenant/realm.

Taking Keycloak out of the context for a while, I'd like to get *our*
definition of tenant to be made. After that, I can check if we can use
Keycloak as part of the authorization for this scenario (KC will
probably still be part of the authentication, though).

One possible solution is to have "users" and "organizations", a la
Github. Users can be part of zero or more organizations and
organizations have one or more members. Data (git repos or resources)
belongs to either an user or an organization.

For this solution, here's how I see it working on different scenarios:

- - standalone/hobby user: isn't a member of any organization, but have
a few resources to manage. A sample curl call:

- -> http://user:password at hawkular/metrics
   all metrics for all resources owned by the user's main account

- -> http://user:password at hawkular/resource/{resourceId}/metrics
   all metrics for this specific resource, which should belong to the
main account

- - user who creates/manages one or more organizations: can either have
resources on the main account (like standalone) or have resources
belonging to an organization. Sample curl call:

- -> http://user:password at hawkular/metrics
   all metrics for all resources owned by the user's main account *or*
owned by organizations where this user is a member of.

- -> http://user:password at hawkular/resource/{resourceId}/metrics
   all metrics for this specific resource, if the resource belongs to
the user or to an organization where the user is a member of

For this scenario, I think the UI could be built with a "context
switcher". This way, the user would have access to a dashboard with
resources from his main account and could switch to a dashboard with
resources from an organization. The backend, though, would not have
such a notion of "context". Either the user has access to the resource
or not (via the main account or via an organization).

Putting Keycloak back in context: for this kind of scenario, we would
have only one Keycloak realm, so, all users would be in one big realm.
All of the authorization would be made on our backend(s). Upon
registration (via Keycloak), an user doesn't belongs to any
organization. In the future, we can consume some extra LDAP data from
Keycloak, to auto assign users to some organizations, if desirable.

The main disadvantage of this is that we have to also care about the
authorization, as we cannot rely on permission data coming from Keycloak.

The main advantage is that we get a behavior that is custom tailored
to our use case.

Thoughts?

- - Juca.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJUymw8AAoJECKM1e+fkPrX9KQH/A2O1pcV+cO3mu7PPV5aWq/v
9Ke+xlm+2hutMVKned5RGld2JD47pqTqdj6WBsLqu04AcntUrc46Vt8gnHCGrst+
FlYPsvlhb/tkN3Ddg4UMfspn5uar7uaSg2namTtSz3A/DDjQkmxqBBCUqtLgFaAc
NDaV/XkDrPCBbbNOHN11GLBV8WpFM6g5JeiaPfHWROGTifQCJU52ZEgPj0pbtGL9
NqLjOF2ekrnhxVNH/PqP2akN0bzWK6Bo2i2SMgNILZEDVQyMlTA1w1hCEcn/35oG
wHCOsGFb2RUJyqGgWqyqoxqsKBgOErzfGUhwQ4VEpU15Cvoh3HyGrEtHQCqFWzI=
=IfUo
-----END PGP SIGNATURE-----

From mazz at redhat.com  Thu Jan 29 14:48:33 2015
From: mazz at redhat.com (John Mazzitelli)
Date: Thu, 29 Jan 2015 14:48:33 -0500 (EST)
Subject: [Hawkular-dev] Logging ...
In-Reply-To: <650169041.2530204.1422462378834.JavaMail.zimbra@redhat.com>
References: <F23B80F3-E163-4A25-94FD-AAB67FA66648@redhat.com>
	<1401520273.2306861.1422446239726.JavaMail.zimbra@redhat.com>
	<E098DE23-987E-49F7-BB90-4B670D320D8B@redhat.com>
	<706083138.2398975.1422451989074.JavaMail.zimbra@redhat.com>
	<650169041.2530204.1422462378834.JavaMail.zimbra@redhat.com>
Message-ID: <1007500673.3621205.1422560913395.JavaMail.zimbra@redhat.com>

Note that the annotation stuff has changed. All the annotations in org.jboss.logging has been deprecated. You need another dep called org.jboss.logging:jboss-logging-annotations - version 1.2.0.Final.

I believe it is not a runtime dependency - so I just put it in my parent pom with provided scope. All the annotations have a retention policy of CLASS, not RUNTIME, so I assume that means you don't need the annotations jar (and, in fact, the Wildfly 8.2 distro does not have it - the only thing in the org.jboss.logging module is the logging jar itself)

In addition, @MessageLogger requires you to specify "projectCode" attribute now. I'm sure there are other changes on the new annotations stuff. The example I found on the RH wiki is for the old annotations, I guess.

----- Original Message -----
> This page shows how you can put this in your pom.xml to process the message
> bundles:
> 
> https://developer.jboss.org/wiki/JBossLoggingTooling#jive_content_id_mavenprocessorplugin
> 
> And this is a good snippet that shows how org.jboss.logging is used:
> 
> @MessageLogger("JBREM")
> public interface MyLogger {
>    @Message(id = 1, value = "JBoss Remoting version %s")
>    @LogMessage(level = INFO)
>    void greet(String version);
>   
>    @Message(id = 2, value = "Error connecting from %s to %s: %s")
>    @LogMessage(level = ERROR)
>    void connectionError(SocketAddress src, SocketAddress dst, String reason);
>   
>    // trace stuff has different restrictions
>    @Message(value = "Connection established from %s to %s")
>    @LogMessage(level = TRACE)
>    void connectionEstablished(SocketAddress src, SocketAddress dst);
> 
>     // THIS SHOWS USING @Cause
>     @LogMessage(level = Level.ERROR)
>     @Message(id = 3, value = "Error Message: %s")
>     void errorWithCause(@Cause Throwable cause, String error);
> }
>   
> public class Foo
> {
>   MyLogger log;
>   
>   static
>   {
>    log = Logger.getMessageLogger(MyLogger.class, "org.jboss.remoting"); //
>    defaults to current locale
>    log.greet(getVersionString());
>    // etc.
>   }
> }
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> 

From mazz at redhat.com  Thu Jan 29 17:49:53 2015
From: mazz at redhat.com (John Mazzitelli)
Date: Thu, 29 Jan 2015 17:49:53 -0500 (EST)
Subject: [Hawkular-dev] Logging ...
In-Reply-To: <650169041.2530204.1422462378834.JavaMail.zimbra@redhat.com>
References: <F23B80F3-E163-4A25-94FD-AAB67FA66648@redhat.com>
	<1401520273.2306861.1422446239726.JavaMail.zimbra@redhat.com>
	<E098DE23-987E-49F7-BB90-4B670D320D8B@redhat.com>
	<706083138.2398975.1422451989074.JavaMail.zimbra@redhat.com>
	<650169041.2530204.1422462378834.JavaMail.zimbra@redhat.com>
Message-ID: <2067467692.3706569.1422571793152.JavaMail.zimbra@redhat.com>

OK, I got the logging stuff to work (with the new annotations stuff, and with the mvn processor plugin).

However, I can see this getting out of hand real quick if we aren't deliberate about assigning number ranges not just across major components but more importantly within components. Its easy to say "metrics, you have IDs between 1000-1999" but getting each individual subcomponents within metrics to block off their own (or at least making sure they don't step on each other) could be difficult to manage as the code base grows larger.

So I have three things:

1) We need to block off larger ranges than just 1000. By default, the message IDs are formatted to assume 6-characters in the ID. So that means we technically can go up to 999999 without having to do anything (we obviously can go with more, but we'd have to specify the length in our @MessageLogger annotations if we want the IDs to "look nice" when they are spit out in the log). But more importantly, it will be easier to block of ranges of numbers within a major component (for example, I can already see a need for me to block off numbers for my broker wildfly extension from the common bus API from the nest wildfly extension).

2) Does anyone know of anyone on the Wildfly team or anyone else that has used this logger annotation stuff for large projects? I'm curious to know what they do to make managing the blocking off and assigning these numbers easier. Is there anything the Java compiler can do to help? Anything tricks of laying out the message interfaces to make it easier?

3) I'm not assigning IDs and using these message interfaces/annotations for DEBUG or TRACE messages. That will just get out of hand real quick. But that means in my code, I'm actually created two loggers - one via Logger.getMessageLogger and one via Logger.getLogger. The former will use the message interface and will be for INFO/ERROR messages, the latter is for ad-hoc debug/trace messages.

From tsegismo at redhat.com  Fri Jan 30 04:58:39 2015
From: tsegismo at redhat.com (Thomas Segismont)
Date: Fri, 30 Jan 2015 10:58:39 +0100
Subject: [Hawkular-dev] Should Keycloak integration be optional?
In-Reply-To: <54CA5AFD.5010102@redhat.com>
References: <54C28AE2.3010509@redhat.com>	<54C601D9.9030102@redhat.com>	<54C75B94.8080103@redhat.com>	<54C79ECF.7020109@redhat.com>	<54CA1768.8050105@redhat.com>
	<54CA5AFD.5010102@redhat.com>
Message-ID: <54CB55CF.3040207@redhat.com>

Le 29/01/2015 17:08, Juraci Paix?o Kr?hling a ?crit :
> On 01/29/2015 12:20 PM, Thomas Segismont wrote:
>> >My last point was "The PR makes it impossible to install a metrics
>> >  server without KC". I meant that if one needs to configure and run
>> >a KC server in order to run a metrics server, then many potential
>> >users will not even give it a try. Potential users here are admins
>> >and production-focused developers who are working with combos like
>> >  Grafana/Graphite/collectd
> Sorry for cutting the whole message to just this point, but before
> talking about the other points, I just want to clarify one thing: the

That's ok, as long as we do talk about the other points ;)

>   admin does*not*  need to deal with KC at all when trying things out.
> To run a metrics server, one just runs the start.sh and Keycloak just
> happens to be there as an implementation detail.
>

I know that start.sh does everything so that you get a metrics + KC 
instance up and running. But that is not my point. My point is that many 
admins will not even try the start.sh way if they realize they will 
*have to* install an identity management server to use metrics in the 
long run.

> Once the admin is ready to bring things to production, then Keycloak
> becomes a "concern", like any other backend would be (LDAP, SAML, ...).
>

When you install InfluxDB, carbon/whisper, opentsdb, you don't need to 
install an identity management server, period.

And LDAP, RDBMS, properties file are identity management backends, KC is 
identity management itself.

> Since the demo, I've been looking at how other projects are
> integrating with Keycloak. The common scenario seems to be that their
> Maven profiles build a "distribution" that is Wildfly + Keycloak +
> WARs. So, the user just uncompresses this distribution package and has
> everything ready (this is similar to what we had in GateIn).
>
> Would this be a solution? I remember seeing somewhere that the goal is
> not to be dependent on Wildfly[1], but not sure if this design goal is
> still accurate.
>
> [1]https://developer.jboss.org/wiki/HighLevelRequirements

That would be nice for users who *want* KC.

I can understand that we make KC a runtime requirement for the full 
Hawkular monty, but I can't for metrics alone.

Regards,
Thomas

From theute at redhat.com  Fri Jan 30 06:22:12 2015
From: theute at redhat.com (Thomas Heute)
Date: Fri, 30 Jan 2015 12:22:12 +0100
Subject: [Hawkular-dev] Should Keycloak integration be optional?
In-Reply-To: <54CB55CF.3040207@redhat.com>
References: <54C28AE2.3010509@redhat.com>	<54C601D9.9030102@redhat.com>	<54C75B94.8080103@redhat.com>	<54C79ECF.7020109@redhat.com>	<54CA1768.8050105@redhat.com>	<54CA5AFD.5010102@redhat.com>
	<54CB55CF.3040207@redhat.com>
Message-ID: <54CB6964.10905@redhat.com>



On 01/30/2015 10:58 AM, Thomas Segismont wrote:
> Le 29/01/2015 17:08, Juraci Paix?o Kr?hling a ?crit :
>> On 01/29/2015 12:20 PM, Thomas Segismont wrote:
>>>> My last point was "The PR makes it impossible to install a metrics
>>>>   server without KC". I meant that if one needs to configure and run
>>>> a KC server in order to run a metrics server, then many potential
>>>> users will not even give it a try. Potential users here are admins
>>>> and production-focused developers who are working with combos like
>>>>   Grafana/Graphite/collectd
>> Sorry for cutting the whole message to just this point, but before
>> talking about the other points, I just want to clarify one thing: the
>
> That's ok, as long as we do talk about the other points ;)
>
>>    admin does*not*  need to deal with KC at all when trying things out.
>> To run a metrics server, one just runs the start.sh and Keycloak just
>> happens to be there as an implementation detail.
>>
>
> I know that start.sh does everything so that you get a metrics + KC
> instance up and running. But that is not my point. My point is that many
> admins will not even try the start.sh way if they realize they will
> *have to* install an identity management server to use metrics in the
> long run.
>
>> Once the admin is ready to bring things to production, then Keycloak
>> becomes a "concern", like any other backend would be (LDAP, SAML, ...).
>>
>
> When you install InfluxDB, carbon/whisper, opentsdb, you don't need to
> install an identity management server, period.

They are also not multi-tenant solutions AFAIK. I don't see Metrics 
competing with the solution mentioned, actually we looked into those to 
use as underlying solution.

That said I am fine not providing security within Metrics and have it 
part of Hawkular only if we can. I am much more hesitant providing 
multiple stacks for multiple purposes as it makes testing much more 
complicated.

Thomas

>
> And LDAP, RDBMS, properties file are identity management backends, KC is
> identity management itself.
>
>> Since the demo, I've been looking at how other projects are
>> integrating with Keycloak. The common scenario seems to be that their
>> Maven profiles build a "distribution" that is Wildfly + Keycloak +
>> WARs. So, the user just uncompresses this distribution package and has
>> everything ready (this is similar to what we had in GateIn).
>>
>> Would this be a solution? I remember seeing somewhere that the goal is
>> not to be dependent on Wildfly[1], but not sure if this design goal is
>> still accurate.
>>
>> [1]https://developer.jboss.org/wiki/HighLevelRequirements
>
> That would be nice for users who *want* KC.
>
> I can understand that we make KC a runtime requirement for the full
> Hawkular monty, but I can't for metrics alone.
>
> Regards,
> Thomas
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>

From jshaughn at redhat.com  Fri Jan 30 09:06:17 2015
From: jshaughn at redhat.com (Jay Shaughnessy)
Date: Fri, 30 Jan 2015 06:06:17 -0800
Subject: [Hawkular-dev] [hawkular/hawkular-alerts] 410f37: Add Eclipse files
	to .gitignore
Message-ID: <54cb8fd9597dd_22f23fde9accd2c04459d@hookshot-fe2-cp1-prd.iad.github.net.mail>

  Branch: refs/heads/master
  Home:   https://github.com/hawkular/hawkular-alerts
  Commit: 410f37ea90c645c321cd86904518826e0baaf194
      https://github.com/hawkular/hawkular-alerts/commit/410f37ea90c645c321cd86904518826e0baaf194
  Author: Peter Palaga <ppalaga at redhat.com>
  Date:   2015-01-30 (Fri, 30 Jan 2015)

  Changed paths:
    M .gitignore

  Log Message:
  -----------
  Add Eclipse files to .gitignore


  Commit: 2177599a58e09aff945f8a15d683ba375270b24d
      https://github.com/hawkular/hawkular-alerts/commit/2177599a58e09aff945f8a15d683ba375270b24d
  Author: Jay Shaughnessy <jshaughn at redhat.com>
  Date:   2015-01-30 (Fri, 30 Jan 2015)

  Changed paths:
    M .gitignore

  Log Message:
  -----------
  Merge pull request #2 from ppalaga/150130-ignore-eclipse

Add Eclipse files to .gitignore


Compare: https://github.com/hawkular/hawkular-alerts/compare/a0312d4026d9...2177599a58e0

From theute at redhat.com  Fri Jan 30 09:37:23 2015
From: theute at redhat.com (Thomas Heute)
Date: Fri, 30 Jan 2015 15:37:23 +0100
Subject: [Hawkular-dev] define: tenant
In-Reply-To: <54CA6C3C.9080808@redhat.com>
References: <54CA6C3C.9080808@redhat.com>
Message-ID: <54CB9723.1080706@redhat.com>

Tough subject and we can hardly predict what users will really need.

I hope we can keep it simple for now. We may have to revisit later.

Can we say that:
	Step 1: resources belong to a user and only him has access
	Step 2: resources can be shared with a group or a specific user by the 
owner (who can grant "write access" to the group or specific users)

IMO this is already quite flexible, simple from a user perspective but 
already complex enough to handle initially. (A user who have read access 
should still be able to create alerts for this resource...) We'll have 
to think about what happens to orphans resources (owner gets deleted) 
and likely other corner cases and optimizations (like the switcher you 
mentioned or like in Google drive, sharing with me doesn't mean it will 
mess with my documents unless I want to copy it over.)

I think it maps with what you described.

Thomas


On 01/29/2015 06:22 PM, Juraci Paix?o Kr?hling wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> After the demo, I was looking for ways to improve the "realm selection
> modal", but I keep hitting a problem with the definition of a
> tenant/realm.
>
> Taking Keycloak out of the context for a while, I'd like to get *our*
> definition of tenant to be made. After that, I can check if we can use
> Keycloak as part of the authorization for this scenario (KC will
> probably still be part of the authentication, though).
>
> One possible solution is to have "users" and "organizations", a la
> Github. Users can be part of zero or more organizations and
> organizations have one or more members. Data (git repos or resources)
> belongs to either an user or an organization.
>
> For this solution, here's how I see it working on different scenarios:
>
> - - standalone/hobby user: isn't a member of any organization, but have
> a few resources to manage. A sample curl call:
>
> - -> http://user:password at hawkular/metrics
>     all metrics for all resources owned by the user's main account
>
> - -> http://user:password at hawkular/resource/{resourceId}/metrics
>     all metrics for this specific resource, which should belong to the
> main account
>
> - - user who creates/manages one or more organizations: can either have
> resources on the main account (like standalone) or have resources
> belonging to an organization. Sample curl call:
>
> - -> http://user:password at hawkular/metrics
>     all metrics for all resources owned by the user's main account *or*
> owned by organizations where this user is a member of.
>
> - -> http://user:password at hawkular/resource/{resourceId}/metrics
>     all metrics for this specific resource, if the resource belongs to
> the user or to an organization where the user is a member of
>
> For this scenario, I think the UI could be built with a "context
> switcher". This way, the user would have access to a dashboard with
> resources from his main account and could switch to a dashboard with
> resources from an organization. The backend, though, would not have
> such a notion of "context". Either the user has access to the resource
> or not (via the main account or via an organization).
>
> Putting Keycloak back in context: for this kind of scenario, we would
> have only one Keycloak realm, so, all users would be in one big realm.
> All of the authorization would be made on our backend(s). Upon
> registration (via Keycloak), an user doesn't belongs to any
> organization. In the future, we can consume some extra LDAP data from
> Keycloak, to auto assign users to some organizations, if desirable.
>
> The main disadvantage of this is that we have to also care about the
> authorization, as we cannot rely on permission data coming from Keycloak.
>
> The main advantage is that we get a behavior that is custom tailored
> to our use case.
>
> Thoughts?
>
> - - Juca.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
>
> iQEcBAEBAgAGBQJUymw8AAoJECKM1e+fkPrX9KQH/A2O1pcV+cO3mu7PPV5aWq/v
> 9Ke+xlm+2hutMVKned5RGld2JD47pqTqdj6WBsLqu04AcntUrc46Vt8gnHCGrst+
> FlYPsvlhb/tkN3Ddg4UMfspn5uar7uaSg2namTtSz3A/DDjQkmxqBBCUqtLgFaAc
> NDaV/XkDrPCBbbNOHN11GLBV8WpFM6g5JeiaPfHWROGTifQCJU52ZEgPj0pbtGL9
> NqLjOF2ekrnhxVNH/PqP2akN0bzWK6Bo2i2SMgNILZEDVQyMlTA1w1hCEcn/35oG
> wHCOsGFb2RUJyqGgWqyqoxqsKBgOErzfGUhwQ4VEpU15Cvoh3HyGrEtHQCqFWzI=
> =IfUo
> -----END PGP SIGNATURE-----
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>

From jpkroehling at redhat.com  Fri Jan 30 10:55:00 2015
From: jpkroehling at redhat.com (=?windows-1252?Q?Juraci_Paix=E3o_Kr=F6hling?=)
Date: Fri, 30 Jan 2015 16:55:00 +0100
Subject: [Hawkular-dev] define: tenant
In-Reply-To: <54CB9723.1080706@redhat.com>
References: <54CA6C3C.9080808@redhat.com> <54CB9723.1080706@redhat.com>
Message-ID: <54CBA954.2060500@redhat.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/30/2015 03:37 PM, Thomas Heute wrote:
> I hope we can keep it simple for now. We may have to revisit
> later.
> 
> Can we say that: Step 1: resources belong to a user and only him
> has access Step 2: resources can be shared with a group or a
> specific user by the owner (who can grant "write access" to the
> group or specific users)
> 
> IMO this is already quite flexible, simple from a user perspective
> but already complex enough to handle initially. (A user who have
> read access should still be able to create alerts for this
> resource...) We'll have to think about what happens to orphans
> resources (owner gets deleted) and likely other corner cases and
> optimizations (like the switcher you mentioned or like in Google
> drive, sharing with me doesn't mean it will mess with my documents
> unless I want to copy it over.)

Alright, so, this means also that authentication is done by KC, and
authorization is done by the application. I think it's the safest
route for the beginning.

This effectively means that KC will have only one "hawkular" realm and
all users will be inside of it. The notion of "tenant" is then built
on our side. In the end, it's the simplest form of KC and it also
gives us self-registration for free.

Next step is, then, hawt.io with KC :-)

- - Juca.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJUy6lUAAoJECKM1e+fkPrX+qMH/ReUnlHY1l4OmvGn9yy4TVcw
gDpqj13OY4bAqdm/Nb6a3jVxs/GN/Bwpucrz/0NBd8FueexnNz162gjsoBiZCARF
5/hnKOpddqhCyhOm4N0s+UAE7xNXViesbbdcZsCh/LeSdROlpaAvKmkOpXvwr8Y/
ZwxyJkCFejpy77nrgTGfi2Aj6fK4XtNm57Ifm3V8JlX3XcP0vDKOv9BMpmkW04d9
sV6t2p98sGeFkO0zui4zuYSPO8DVtsHTID35m2THSlUiFnjj02GpXfnCNDNF3EMB
vae0wW5Z0jCJ6QTU/LprXwmNwq579bwUQvQvfipzNIX2OSlXJ6ytzhwEWREQvAc=
=Tha0
-----END PGP SIGNATURE-----

From jsanda at redhat.com  Fri Jan 30 10:57:24 2015
From: jsanda at redhat.com (John Sanda)
Date: Fri, 30 Jan 2015 10:57:24 -0500
Subject: [Hawkular-dev] [metrics] schema changes
Message-ID: <EAA13775-0354-44FD-A49C-68ACE7569D57@redhat.com>

I merged changes to master yesterday that include schema changes. You will need to drop your existing keyspaces in order to pick up the changes. You can do this in cqlsh, 

    DROP KEYSPACE rhqtest;

and if you are using ccm, you can start a cqlsh session with,
 
    ccm node1 cqlsh

I just added a property to the build that will do this for you during metrics-core integration tests.

    mvn test -Dresetdb


- John

From mithomps at redhat.com  Fri Jan 30 17:22:06 2015
From: mithomps at redhat.com (mike thompson)
Date: Fri, 30 Jan 2015 14:22:06 -0800
Subject: [Hawkular-dev] Does index.html page need License header
Message-ID: <D3F71A2D-F7AC-481E-B500-D294AD559D26@redhat.com>

Just curious if the actual index.html page needs a License header?

And after the ts/js/gwt app is minified does there need to be any licensing header in the minified code?

From mazz at redhat.com  Fri Jan 30 18:16:36 2015
From: mazz at redhat.com (John Mazzitelli)
Date: Fri, 30 Jan 2015 18:16:36 -0500 (EST)
Subject: [Hawkular-dev] checkstyle/enforcer
In-Reply-To: <962040120.4393334.1422659749469.JavaMail.zimbra@redhat.com>
Message-ID: <246466987.4393386.1422659796474.JavaMail.zimbra@redhat.com>

I just converted the bus code to use hawkular-parent which in turn brought checkstyle/enforcer into play.

I highly recommend everyone do this for your code as soon as you can - the earlier you integrate parent, and especially checkstyle/enforcer, the easier it will be on yourself. Lots of checkstyle and enforcer errors in my stuff that I had to go about fixing... you don't want to do this after you have lots of code that needs to be cleaned up.

From mazz at redhat.com  Fri Jan 30 18:32:48 2015
From: mazz at redhat.com (John Mazzitelli)
Date: Fri, 30 Jan 2015 18:32:48 -0500 (EST)
Subject: [Hawkular-dev] logging ID ranges
In-Reply-To: <1524234453.4393446.1422659897433.JavaMail.zimbra@redhat.com>
Message-ID: <1571754022.4394996.1422660768170.JavaMail.zimbra@redhat.com>

I would like to make a recommendation for logging range IDs for the different components.

Right now, the default width of IDs are 6 characters (they can be more or less, but that's the default). I'm assuming we all will use HAWK as the prefix (as opposed to HAWK vs. HAWKMETRICS vs. HAWKALERTS, etc).

Through my experience integrating this logging stuff the past few days in the bus modules, I've come to appreciate the fact that we should probably give more range than just 1000 IDs to a major component. I don't know exactly how to do it, but I found it easier to split the ranges up to my subcomponents when using the full 6-characters. This allows you to create multiple MessageLogger classes (one per maven module is what I think would be typical - especially if one module doesn't depend on others) and you can break your main range up into subranges, while still having enough IDs left for actual logs.

For example, suppose metrics has four subcomponents (and I'm just making this up) - metrics-aggregator, metrics-collector, metrics-ui, metrics-purge. Now, suppose metrics was given the range 1000-1999. Each subcomponent would only have 250 IDs each if you assign them their own subrange. If you don't, if you just give them all 1000 then you will probably only have a single MessageLogger for all 4, and that will get ugly (MessageLogger would live in one module, and they all would need to depend on it, and any new log message would require all modules to recompile, even if the other modules don't need that message).

So what I say is we give metrics the ID range (e.g.) HAWK-200000 to HAWK-299999. Each subcomponent could then be given:

metrics-aggregator = 200000-200999
metrics-collector  = 201000-201999
metrics-ui         = 202000-202999
metrics-purge      = 203000-203999

So you can see each still has room for 1,000 message IDs individually with room for 100 subcomponents (that's the first three digits of the ID - 200-299).

Alerts would then be given the range HAWK-300000 to HAWK-399999 and it does the same thing.

Obviously, this can be tweeked; you can say the first two digits are the component (20-29) giving you room for 10 subcomponents, with each subcomponent now able to have 10,000 messages (e.g. 200000-209999).

Or we can give each their own prefix (HAWK vs HAWKMETRICS) giving each the full 6-digit ID range all to themselves.

In any event, if you haven't tried coding up log messages with this Jboss logging message ID stuff, I suggest you do it, and see what kinds of issues you will see crop up (mainly it deals with what ranges of IDs get assigned to what MessageLoggers and how many MessageLoggers do you create and where).

We don't want to do this wrong - it will be headaches later on in the future when we realize we handed out the IDs ranges poorly or we created MessageLoggers in the wrong places.

I'm not advocating any specific approach, but we need to think about this - this isn't one of those things where everyone can go rogue. Unless we give everyone their own id prefix (HAWK vs. HAWKMETRICS, for example) in which case, go crazy :)

From mazz at redhat.com  Fri Jan 30 20:39:15 2015
From: mazz at redhat.com (John Mazzitelli)
Date: Fri, 30 Jan 2015 20:39:15 -0500 (EST)
Subject: [Hawkular-dev] jboss logging PR ready for merge to h-parent
In-Reply-To: <656074229.4404196.1422667767759.JavaMail.zimbra@redhat.com>
Message-ID: <1465239839.4406322.1422668355426.JavaMail.zimbra@redhat.com>

OK, I've got a PR into the hawkular-parent-pom repo - once someone reviews and merges that for me (*cough cough* *hint hint*), it means we have JBoss Logging processing enabled for Hawkular. Take a look here to see what had to get done (it just involved a maven plugin "org.bsc.maven:maven-processor-plugin")

https://github.com/hawkular/hawkular-parent-pom/pull/6

To use the jboss logging processor, your maven project's pom needs to have hawkular-parent as its root parent. Once you do that, you need two dependencies on your pom - jboss-logging itself (obviously) and the jboss-logging-annotations which gives you the logging annotations like @MessageLogger, @LogMessage, etc. These are the two you need:

<dependency>
  <groupId>org.jboss.logging</groupId>
  <artifactId>jboss-logging</artifactId>
</dependency>

<dependency>
  <groupId>org.jboss.logging</groupId>
  <artifactId>jboss-logging-annotations</artifactId>
  <scope>provided</scope>
</dependency>

Here's what a typical logging interface looks like - if interested. This is how you define the i18n messages with ID numbers:

https://github.com/hawkular/hawkular-bus/blob/master/hawkular-bus-common/src/main/java/org/hawkular/bus/common/log/MsgLogger.java

Notice I'm only assigning IDs to INFO through ERROR levels (not for DEBUG or TRACE).

Once hawkular-parent merges my PR, I'll merge my own PR I have waiting in hawkular-bus so it can just use hawkular-parent's jboss logging process stuff.

From hrupp at redhat.com  Sat Jan 31 12:09:53 2015
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Sat, 31 Jan 2015 18:09:53 +0100
Subject: [Hawkular-dev] checkstyle/enforcer
In-Reply-To: <246466987.4393386.1422659796474.JavaMail.zimbra@redhat.com>
References: <246466987.4393386.1422659796474.JavaMail.zimbra@redhat.com>
Message-ID: <57CDCF3D-DA5A-4678-A6A6-52C686D1BF25@redhat.com>


> Am 31.01.2015 um 00:16 schrieb John Mazzitelli <mazz at redhat.com>:
> 
> I just converted the bus code to use hawkular-parent which in turn brought checkstyle/enforcer into play.
> 
> I highly recommend everyone do this for your code as soon as you can - the earlier you integrate parent, and especially checkstyle/enforcer, the easier it will be on yourself. Lots of checkstyle and enforcer errors in my stuff that I had to go about fixing... you don't want to do this after you have lots of code that needs to be cleaned up.

I think those checks (while sometimes are annoying) are good.

Having said that, I'd like to see a way to apply them as pre-commit and not on each
mvn compile run. 
While devlopping in 

while (!working) {
    change_some_stuff();
    compile();
    deploy();
    test();
}

mode, being forced to fix import or line length issues is certainly reducing my productivity.

And to repeat: I am very much in favor of enforcing all those checks once the code has left the
above loop.




From hrupp at redhat.com  Sat Jan 31 16:08:49 2015
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Sat, 31 Jan 2015 22:08:49 +0100
Subject: [Hawkular-dev] logging ID ranges
In-Reply-To: <1571754022.4394996.1422660768170.JavaMail.zimbra@redhat.com>
References: <1571754022.4394996.1422660768170.JavaMail.zimbra@redhat.com>
Message-ID: <BDD29CF7-23B9-4F58-AA20-98E8355F3491@redhat.com>


> Am 31.01.2015 um 00:32 schrieb John Mazzitelli <mazz at redhat.com>:
> 
> I would like to make a recommendation for logging range IDs for the different components.
> 
> Right now, the default width of IDs are 6 characters (they can be more or less, but that's the default). I'm assuming we all will use HAWK as the prefix (as opposed to HAWK vs. HAWKMETRICS vs. HAWKALERTS, etc).

Didn't we agree on HAWK just a few days ago (incl. you and Jay?)

> 
> Through my experience integrating this logging stuff the past few days in the bus modules, I've come to appreciate the fact that we should probably give more range than just 1000 IDs to a major component. I don't know exactly how to do it, but I found it easier to 

When the first 1000 are used, they will get another block. Do you really expect that we will differentiate between 1000 
different warn / error messages per component?

-- 
Reg. Adresse: Red Hat GmbH, Technopark II, Haus C, 
Werner-von-Siemens-Ring 14, D-85630 Grasbrunn
Handelsregister: Amtsgericht M?nchen HRB 153243
Gesch?ftsf?hrer: Charles Cachera, Michael Cunningham, Paul Hickey, Charlie Peters



From mazz at redhat.com  Sat Jan 31 19:54:45 2015
From: mazz at redhat.com (John Mazzitelli)
Date: Sat, 31 Jan 2015 19:54:45 -0500 (EST)
Subject: [Hawkular-dev] logging ID ranges
In-Reply-To: <BDD29CF7-23B9-4F58-AA20-98E8355F3491@redhat.com>
References: <1571754022.4394996.1422660768170.JavaMail.zimbra@redhat.com>
	<BDD29CF7-23B9-4F58-AA20-98E8355F3491@redhat.com>
Message-ID: <1735725952.4491001.1422752085724.JavaMail.zimbra@redhat.com>

> > Am 31.01.2015 um 00:32 schrieb John Mazzitelli <mazz at redhat.com>:
> > 
> > I would like to make a recommendation for logging range IDs for the
> > different components.
> > 
> > Right now, the default width of IDs are 6 characters (they can be more or
> > less, but that's the default). I'm assuming we all will use HAWK as the
> > prefix (as opposed to HAWK vs. HAWKMETRICS vs. HAWKALERTS, etc).
> 
> Didn't we agree on HAWK just a few days ago (incl. you and Jay?)

Yes. Then I realized it might not be good to have the same prefix and everyone try to divy up the IDs within it. Might be easier to have each component with its own prefix, that way we don't have to worry about having all these ID ranges across multiple modules/components.

> > Through my experience integrating this logging stuff the past few days in
> > the bus modules, I've come to appreciate the fact that we should probably
> > give more range than just 1000 IDs to a major component. I don't know
> > exactly how to do it, but I found it easier to
> 
> When the first 1000 are used, they will get another block. Do you really
> expect that we will differentiate between 1000
> different warn / error messages per component?

I assumed we would want a contiguous range - rather than a component have, say, 1000-2000 and 4000-5000, but I see there is @ValidIdRanges; I didn't realize it supported that. So that's OK. But we would still have to make sure we don't step on each other ("you just took range 4000-5000, but I got that assigned last month"). I *think* the Jboss logging processor will catch that (I know it catches reusing the same ID within the same @MessageLogger interface, I'll assume it can catch it even across message loggers).

BTW: start coding with this stuff yourself, across multiple maven modules - and you'll see it does involve some thinking on our part on how to assign these numbers so no one steps on each other and how many @MessageLogger interfaces to have and what to name them.

From jsanda at redhat.com  Thu Jan 22 14:00:06 2015
From: jsanda at redhat.com (John Sanda)
Date: Thu, 22 Jan 2015 14:00:06 -0500
Subject: [Hawkular-dev] integration project
In-Reply-To: <165659311.7881078.1423231943618.JavaMail.zimbra@redhat.com>
References: <AA68ED56-1301-476F-8FD4-76FA2ADEF53B@redhat.com>
	<415096932.7531096.1423166525769.JavaMail.zimbra@redhat.com>
	<BAD9995D-288B-46A0-B672-CC979039D034@redhat.com>
	<1119863261.7549138.1423168481278.JavaMail.zimbra@redhat.com>
	<A5AC1495-B8A4-4598-A66B-D4447FC503F1@redhat.com>
	<165659311.7881078.1423231943618.JavaMail.zimbra@redhat.com>
Message-ID: <12A90508-BF38-4A7C-873A-0EEAF8201FB3@redhat.com>

wildfly-cassandra requires building upstream C* trunk branch which is currently targeted for 3.0. I have been developing/testing against 2.1.2.  It may work fine. I don?t know. I can test and let you know in about an hour or so whether or not there will be problems.

> On Feb 6, 2015, at 9:12 AM, John Mazzitelli <mazz at redhat.com> wrote:
> 
>>> Bad news - metrics is broken. When you start, you'll get an exception
>>> because it appears the embedded cassandra EAR initializes too late - after
>>> the metrics war tries to find C*. You'll get deployment errors due to
>>> this.
>> 
>> As said on the channel already the wildfly-cassandra extension from
>> 
>> https://github.com/hawkular/wildfly-cassandra
> 
> I talked to Stefan and John S. about that - unfortunately (and Stefan/John correct me if I'm wrong) we can't use that because h-metrics needs a later version of C* which wildfly-cassandra does not support.
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev