commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Liviu Tudor (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (LANG-702) New component for lang -- summarizer
Date Mon, 30 May 2011 11:24:47 GMT

    [ 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

Mime
View raw message