[
https://issues.apache.org/jira/browse/LANG-702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13041089#comment-13041089
]
Liviu Tudor commented on LANG-702:
----------------------------------
@Matt This is a first draft based on the rather specific implementations that
as I said I have found myself using in the past -- as such I agree that the
class could do with some refactoring, and your idea to have callbacks for flush
and move the 'summation' outside in its own interface makes sense for a more
extensible framework. Really, as I said, the diff submitted was just to get
some opinion first of whether this component would fit in (if anywhere!) -- my
initial thought was that once that is decided we could look at how we can make
it more robust and extensible.
@Stephen Appreciate the feedback -- I wasn't sure if this was suitable for
[lang] or not either -- hence my initial question. If it is the case that this
doesn't fit in here, what other component would you think this is more suitable
for? My initial thought was to submit this to [collections], however, on the
basis that this only stores one "number" I thought again and tried [lang] --
that isn't to say this was a good decision though :)
So, to sum it up I guess, the first question is whether this fits in [lang] or
is there a better place for it? I don't want to commit the same diff to every
project in commons until one team says "yes this makes sense here" (or is this
the way to do it? not sure, sorry if I sound so "green"). Also, from what Matt
was saying there is a component in the pipeline that potentially already
implements some of this functionality? (in which case it doesn't make sense to
commit this as well) My trail of thought was that once there is a place decided
for the component I can liaise with the main committers and decide on changes
to the implementation and hierarchy -- but perhaps this doesn't fit with the
standard way of operating in Apache, in which case I would appreciate some
pointers as to what is the standard procedure. (Your FAQ's talk about how to
commit patches and where and don't mention the design iterations a team goes
through for a component -- unless it's buried somewhere in one of the links
that I've missed?)
Regards,
Liv
> New component for lang -- summarizer
> ------------------------------------
>
> Key: LANG-702
> URL: https://issues.apache.org/jira/browse/LANG-702
> Project: Commons Lang
> Issue Type: New Feature
> Components: General
> Affects Versions: 3.0
> Reporter: Liviu Tudor
> Priority: Minor
> Labels: features, newbie
> Fix For: 3.x
>
> Attachments: patch_summarizer.diff
>
>
> 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.
> Looking forward to your comments on this,
> Liv
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
