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 <liviu.tu...@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-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org