[functor] New summarize component

[Liviu Tudor <li...@gmail.com>]

Hi everyone, 

I'm sending this message as I was suggested to do so following this issue
https://issues.apache.org/jira/browse/SANDBOX-340 opened in JIRA. I have
basically submitted this initially to Commons Lang but that wasn't the right
place for it and it was suggested instead I use this channel to find out
where to position this component best.
Initial issue description below to save you having to log into JIRA:


----
Hi, I'm creating this as a patch request but I guess really initially I
wanted to verify with everyone that commons lang is the place for this class
hierarchy I'm proposing - and if not please suggest whether it would be more
appropriate to submit this to collections or one of the other Commons
projects. (Or I accept as well the fact that it might not be good enough for
any of the commons projects in which case please just let me know so I won't
try to create new issues around this in the future.)
Basically I've come across a pattern I find myself using a lot in my
applications where I want a quick (and not so dirty) way of monitoring
certain things in the application - for instance, I want as a quick
healthcheck a page to tell me how many requests we process over a 1 minute
interval or so. While one can implement complex monitoring systems to
achieve the same, a lot of the times, simply the fact that the number of
successful transactions per minute goes down to 50% (after an application
upgrade for instance) is a clear indicator to me that something isn't right
so I can start investigating straight away and not wait for our monitoring
systems to kick in one hour later or so and alert us of this. As such I have
developed this component which I have called "Summarizer" (purely as my
initial request was just to sum up some numbers over a period of time and
reset it regularly - but as my javadoc comments state, of course this
doesn't have to be a simple arithmetic sum and can be extended to other
operations). The diff I'm proposing here contains the base class and an
example of the class using integers which just sums them up - which is as I
said the kind of implementation that I have found myself implementing a lot
in my apps. I appreciate that the classes are not completely finished and
there are no unit tests yet - and that is because as I said at this stage I
am trying to figure out whether this component would fit into the Commons
Lang component or it would be more appropriate to commit this somewhere
else.
I would appreciate your input/comments on this so I know whether i'm on the
right track on committing this here or should I move it elsewhere; I accept
that perhaps the package names and the class names are not the best, and am
willing to discuss with your main committers around this - if this proves to
be a valid component for commons.
If you decide this is a good idea to proceed with then I can start adding
unit tests and more comments/javadocs around it to make this into a usable
class hierarchy.
As suggested by your FAQ's I've created a diff from the root of the folder -
if it helps more if I just provide the 2 classes I can do so too - just let
me know and I can send you a zip with the 2 classes alone or so.
---------------

The diff I'm attaching is still against commons lang -- or I can send just
the zip with the source code if that makes it easier to evaluate this?
Looking forward to your comments on this,


Liviu Tudor
 

Re: [functor] New summarize component

[Simone Tripodi <si...@apache.org>]

Hi Liviu!
nice to hear news for [functor] and thanks for the reminder; no needs
to copy'n'paste the jira log since, given the issue id, everybody is
able to load the related page and read the original message ;)

The right way to proceed is
 * checkin out the [functor] code[1];
 * import your adds;
 * create a patch[2];
 * attach the patch to the jira issue.

that's all!!! looking forward to read more from you, don't hesitate
asking if more help is needed!!!
All the best, have a nice day,
Simo

[1] https://svn.apache.org/repos/asf/commons/sandbox/functor/trunk
[2] http://commons.apache.org/patches.html

http://people.apache.org/~simonetripodi/
http://www.99soft.org/



On Mon, Aug 29, 2011 at 8:51 PM, Liviu Tudor <li...@gmail.com> wrote:
> Hi everyone,
>
> I'm sending this message as I was suggested to do so following this issue
> https://issues.apache.org/jira/browse/SANDBOX-340 opened in JIRA. I have
> basically submitted this initially to Commons Lang but that wasn't the right
> place for it and it was suggested instead I use this channel to find out
> where to position this component best.
> Initial issue description below to save you having to log into JIRA:
>
>
> ----
> Hi, I'm creating this as a patch request but I guess really initially I
> wanted to verify with everyone that commons lang is the place for this class
> hierarchy I'm proposing - and if not please suggest whether it would be more
> appropriate to submit this to collections or one of the other Commons
> projects. (Or I accept as well the fact that it might not be good enough for
> any of the commons projects in which case please just let me know so I won't
> try to create new issues around this in the future.)
> Basically I've come across a pattern I find myself using a lot in my
> applications where I want a quick (and not so dirty) way of monitoring
> certain things in the application - for instance, I want as a quick
> healthcheck a page to tell me how many requests we process over a 1 minute
> interval or so. While one can implement complex monitoring systems to
> achieve the same, a lot of the times, simply the fact that the number of
> successful transactions per minute goes down to 50% (after an application
> upgrade for instance) is a clear indicator to me that something isn't right
> so I can start investigating straight away and not wait for our monitoring
> systems to kick in one hour later or so and alert us of this. As such I have
> developed this component which I have called "Summarizer" (purely as my
> initial request was just to sum up some numbers over a period of time and
> reset it regularly - but as my javadoc comments state, of course this
> doesn't have to be a simple arithmetic sum and can be extended to other
> operations). The diff I'm proposing here contains the base class and an
> example of the class using integers which just sums them up - which is as I
> said the kind of implementation that I have found myself implementing a lot
> in my apps. I appreciate that the classes are not completely finished and
> there are no unit tests yet - and that is because as I said at this stage I
> am trying to figure out whether this component would fit into the Commons
> Lang component or it would be more appropriate to commit this somewhere
> else.
> I would appreciate your input/comments on this so I know whether i'm on the
> right track on committing this here or should I move it elsewhere; I accept
> that perhaps the package names and the class names are not the best, and am
> willing to discuss with your main committers around this - if this proves to
> be a valid component for commons.
> If you decide this is a good idea to proceed with then I can start adding
> unit tests and more comments/javadocs around it to make this into a usable
> class hierarchy.
> As suggested by your FAQ's I've created a diff from the root of the folder -
> if it helps more if I just provide the 2 classes I can do so too - just let
> me know and I can send you a zip with the 2 classes alone or so.
> ---------------
>
> The diff I'm attaching is still against commons lang -- or I can send just
> the zip with the source code if that makes it easier to evaluate this?
> Looking forward to your comments on this,
>
>
> Liviu Tudor
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org