Side note: geronimo just started to implement Microprofile metrics which is a kind of copy of the dropwizard/codehale API, maybe it can be a place to host this kind of thing too. [1] is quite close I think
[1] https://gitbox.apache.org/repos/asf?p=geronimo-metrics.git;a=blob;f=src/main/java/org/apache/geronimo/microprofile/metrics/impl/TimerImpl.java;h=d8ac05ecef4aea726fe8d8b948e0d067ad35f455;hb=HEAD Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance> Le lun. 11 juin 2018 à 20:35, Otto Fowler <ottobackwa...@gmail.com> a écrit : > Thanks to everyone who took that time to review. > > Although my preference was to contribute this utility back to commons, it > seems like it has kind > of spiraled into something much more, and there doesn’t seem to be a clear > consensus. > > So if you think it was useful : > you grab it now from > https://bintray.com/palindromicity/stackwatch/stackwatch/0.0.1 > https://github.com/palindromicity/stackwatch > > > > On April 23, 2018 at 08:16:46, Gilles (gil...@harfang.homelinux.org) > wrote: > > On Mon, 23 Apr 2018 04:54:21 -0700, Otto Fowler wrote: > > Bump > > More than a vote, you need someone to take on the tasks to > create the new component. > > I feel that no argument were made against bringing ex-Sirona > back to "Commons" (or contributing your code to Romain's > Sirona fork), and I'm afraid that nothing else will be > added to that component (or: where is the plan?). > > Best, > Gilles > > > On April 9, 2018 at 08:53:13, Otto Fowler (ottobackwa...@gmail.com) > > wrote: > > > > There has been no comment, do we need an explicit vote? > > > > > > On April 3, 2018 at 09:27:56, Otto Fowler (ottobackwa...@gmail.com) > > wrote: > > > > So do we need a vote? What is next to move this forward? > > > > > > On March 28, 2018 at 14:51:55, Otto Fowler (ottobackwa...@gmail.com) > > wrote: > > > > OK, sounds fine to me. Hopefully we’ll get some buy in and can move > > forward. > > I’m not sure what is next though ;) > > > > > > > > On March 28, 2018 at 13:17:22, Gary Gregory (garydgreg...@gmail.com) > > wrote: > > > > On Wed, Mar 28, 2018 at 11:14 AM, Otto Fowler > > <ottobackwa...@gmail.com> > > wrote: > > > >> How about commons-timing, having StopWatch, StackWatch and other > >> classes > >> that > >> we can find? > >> > > > > I think we start small with only what we need and have today, namely > > these > > two classes. > > > > Gary > > > > > >> > >> > >> > >> On March 20, 2018 at 18:40:05, Romain Manni-Bucau > >> (rmannibu...@gmail.com) > >> wrote: > >> > >> I would be happy to revive sirona @asf but dont think [monitoring] > >> as just > >> a few classes would bring enough value compare to a lambda not > >> worthing > > any > >> lib/dep in apps - just my opinion indeed. > >> > >> For circuit breaker: geronimo safeguard can be interested in hosting > >> that > >> utility part and drop failsafe dependency. Maybe something to > >> discuss in > >> another thread. > >> > >> Le 20 mars 2018 23:27, "Otto Fowler" <ottobackwa...@gmail.com> a > >> écrit : > >> > >> > Sirona is gone, it is a closed incubator project. Romain has > >> forked it > > to > >> > his own repo. > >> > > >> > > >> > > >> > On March 20, 2018 at 18:24:06, Gilles > >> (gil...@harfang.homelinux.org) > >> > wrote: > >> > > >> > On Tue, 20 Mar 2018 15:00:41 -0700, Otto Fowler wrote: > >> > > If monitoring was started a new, and not re-viving the old > >> > > monitoring? > >> > > >> > Can the feature be contributed to "Sirona"? Otto, are you > >> > interested in this? > >> > Does it make sense to have "Commons Monitoring" revived based > >> > on part/all of "Sirona"? > >> > Romain, are you interested in this? > >> > What would be the scope/description of "Commons Monitoring"? > >> > > >> > Noting Romain's experience that the original "Commons" project > >> > evolved into "Sirona", it would be strange to start from scratch > >> > without a plan to not follow the same route again... > >> > > >> > Gilles > >> > > >> > > On March 20, 2018 at 17:56:44, Bruno P. Kinoshita ( > >> > > brunodepau...@yahoo.com.br.invalid) wrote: > >> > > > >> > > I think StopWatch and CircuitBreakers could be moved together to > >> the > >> > > same > >> > > component. However, a circuit breaker can be time-related, or > >> not > >> > > (e.g. a > >> > > circuit breaker for memory size). So probably commons-timing > >> could be > >> > > a > >> > > good place for StopWatch, but maybe not for circuit-breaker. But > >> I > >> > > think > >> > > both could be under commons-monitoring perhaps? > >> > > > >> > > From: Otto Fowler <ottobackwa...@gmail.com> > >> > > To: Romain Manni-Bucau <rmannibu...@gmail.com>; Commons > >> Developers > >> > > List < > >> > > dev@commons.apache.org> > >> > > Sent: Wednesday, 21 March 2018 10:30 AM > >> > > Subject: Re: [DISCUSS] new component for timing? > >> > > > >> > > I would love to get this on track. I apologize if I have made it > >> > > more > >> > > confusing than it needs to be, > >> > > I’m trying to be open to all the suggestions. > >> > > > >> > > If we assume that stack watch is worth ‘having’, then the > >> question is > >> > > where > >> > > to put it. > >> > > commons-monitoring / sirota seems to me to be a ‘complete’ > >> solution > >> > > as > >> > > opposed to > >> > > a set of or collection of like classes. > >> > > > >> > > Setting the community support / project aspect of sirota aside, > >> it > >> > > seems > >> > > strange to put > >> > > a separate class into a more complete and uniform system. Unless > >> > > there is > >> > > some generically > >> > > useful set of timing utility classes that could be taken out of > >> > > sirota to > >> > > go into commons-????, > >> > > along with things identified ( StopWatch?) out of commons lang > >> and > >> > > possibly > >> > > other commons projects. > >> > > > >> > > commons-timing seems reasonable. Thoughts? > >> > > > >> > > > >> > > > >> > > On March 17, 2018 at 11:24:32, Romain Manni-Bucau > >> > > (rmannibu...@gmail.com) > >> > > wrote: > >> > > > >> > > Yes but consequence was a lack of community increase which is a > >> > > killer for > >> > > an incubator project on the long run. > >> > > > >> > > Le 17 mars 2018 15:19, "Gilles" <gil...@harfang.homelinux.org> a > >> > > écrit : > >> > > > >> > >> On Sat, 17 Mar 2018 12:47:40 +0100, Romain Manni-Bucau wrote: > >> > >> > >> > >>> Le 17 mars 2018 11:49, "Gilles" <gil...@harfang.homelinux.org> > >> a > >> > >>> écrit : > >> > >>> > >> > >>> On Thu, 15 Mar 2018 15:13:39 +0100, Romain Manni-Bucau wrote: > >> > >>> > >> > >>> 2018-03-15 14:36 GMT+01:00 Otto Fowler > >> <ottobackwa...@gmail.com>: > >> > >>>> > >> > >>>> If we can come to consensus on the way forward, I’ll be happy > >> to > >> > >>>> do the > >> > >>>> > >> > >>>>> work ( although I’ll need help of course ). > >> > >>>>> I guess I’m the straw that broke the camel’s back then? ;) > >> > >>>>> > >> > >>>>> > >> > >>>>> > >> > >>>>> > >> > >>>>> On March 15, 2018 at 08:09:45, Gilles > >> > >>>>> (gil...@harfang.homelinux.org) > >> > >>>>> wrote: > >> > >>>>> > >> > >>>>> Hi. > >> > >>>>> > >> > >>>>> On Thu, 15 Mar 2018 03:52:58 -0700, Otto Fowler wrote: > >> > >>>>> > I think bringing back commons-monitoring/sirota would only > >> be > >> > >>>>> > possible if > >> > >>>>> > it were to be modular enough that you could bring in the > >> ‘core’ > >> > >>>>> > classes > >> > >>>>> > without needing to bring in all of what sirota ended up > >> being, > >> > >>>>> which > >> > >>>>> > was an > >> > >>>>> > end to end solution. > >> > >>>>> > >> > >>>>> Isn't it possible? [I didn't look; Romain should tell > >> whether he > >> > >>>>> would be interested in taking that route.] > >> > >>>>> > >> > >>>>> > >> > >>>>> Sirona was done modular, just the API, the in memory part, > >> etc... > >> > >>>> But this kind of impl needs way more just after so not sure > >> it > >> > >>>> does > >> > > worth > >> > >>>> splitting it to put it back altogether after. > >> > >>>> > >> > >>>> What is the rational to try to push a very small part > >> @commons > >> > >>>> instead > >> > > of > >> > >>>> creating a community @incubator with an E2E solution? This is > >> what > >> > >>>> I > >> > > fail > >> > >>>> to see. > >> > >>>> My experience - coming exactly from here - tends to make me > >> think > >> > > commons > >> > >>>> will not fit very long or will not bring enough value pretty > >> > >>>> quickly > >> > > but > >> > >>>> that's just my opinion. > >> > >>>> > >> > >>>> > >> > >>> Not "just" an opinion since you evoke Sirona's precursor as > >> being > >> > >>> the kind of component we'd reinstate. Unless we learn > >> > >>> 1. why the precursor needed to become TLP, and > >> > >>> 2. why the TLP didn't succeed, > >> > >>> we'd go in circles. > >> > >>> > >> > >>> > >> > >>> We failed at community@asf and pby communication/promotion > >> levels I > >> > >>> think. > >> > >>> Other parts were successful (prod etc). > >> > >>> > >> > >>> > >> > >> [It seems that part of your message went missing.] > >> > >> > >> > >> Lack of marketing skills should not entail failure, especially > >> > >> not since communication is a transverse concern. > >> > >> > >> > >> Gilles > >> > >> > >> > >> Would it make sense that Sirona becomes (again?) "Commons > >> > >> Monitoring"? > >> > >>> Does the "StackWatck" (Otto's contribution that started this > >> > >>> discussion) > >> > >>> already exist in a Sirona module? If not, can it be done, so > >> that > >> > >>> usage > >> > >>> is similar to what Otto had in mind? > >> > >>> > >> > >>> Regards, > >> > >>> Gilles > >> > >>> > >> > >>> > >> > >>> commons-monitoring or commons-timing seem to be the correct > >> thing > >> > >>>> > >> > >>>>> > however, > >> > >>>>> > but I would like to think that there would be more impetus > >> > >>>>> > >> > >>>>> I'm afraid that it's rather the lack of manpower. > >> > >>>>> [And my inner conviction is that that state of things often > >> > >>>>> led to rush to cramming more code into existing components, > >> > >>>>> rather than "distribute" more uniformly according to subject > >> > >>>>> matters. When scarce human resources ("community") > >> disappear, > >> > >>>>> cruft accumulates, sometimes up to stifle clean-up, > >> maintenance, > >> > >>>>> improvement, and even development.] > >> > >>>>> > >> > >>>>> > to do this than > >> > >>>>> > thinking StackWatch is ‘too big’ for lang.time. > >> > >>>>> > >> > >>>>> It isn't any more than many other functionalities that were > >> > >>>>> introduced but shouldn't have been. > >> > >>>>> Depending on what the "Commons" PMC wants to favour ("code" > >> > >>>>> *or* "community"?), the choice is between continuing with > >> the > >> > >>>>> accumulation, or back-pedaling through the creation of as > >> > >>>>> many *real* components as they are developers willing to > >> > >>>>> maintain them. > >> > >>>>> > >> > >>>>> > It really isn’t that complicated a thing. > >> > >>>>> > >> > >>>>> Sure. > >> > >>>>> The issue is somewhere else. > >> > >>>>> Note that, personally, I hadn't imagined that there would > >> > >>>>> be an issue for regular developers of [Lang] (or I wouldn't > >> > >>>>> have spent time reviewing the "details" ;-). > >> > >>>>> But I of course agree that the question should be asked; the > >> > >>>>> more so that, with [Math], we've a striking example of what > >> > >>>>> awaits a library that lacks boundary checks and explicit > >> > >>>>> road map. > >> > >>>>> > >> > >>>>> Regards, > >> > >>>>> Gilles > >> > >>>>> > >> > >>>>> > On March 8, 2018 at 11:50:17, Gilles > >> > >>>>> (gil...@harfang.homelinux.org) > >> > >>>>> > wrote: > >> > >>>>> > > >> > >>>>> > On Thu, 08 Mar 2018 16:03:24 +0000, Gary Gregory wrote: > >> > >>>>> >> -1 to "commons-misc". It feels to me like a copout and > >> > >>>>> unfocused > >> > >>>>> >> like > >> > >>>>> >> SomethingUtils. > >> > >>>>> >> We need a proper home. > >> > >>>>> > > >> > >>>>> > +1 > >> > >>>>> > > >> > >>>>> >> How about the idea of commons-measure. > >> > >>>>> > > >> > >>>>> > Just because the first feature would happen to be a timer? > >> > >>>>> > What other content do you foresee? > >> > >>>>> > > >> > >>>>> >> Then there > >> > >>>>> >> still the idea of resurrecting other Apache projects. > >> Kind of > >> > >>>>> going > >> > >>>>> >> in > >> > >>>>> >> circles... > >> > >>>>> > > >> > >>>>> > Indeed, IIRC the questions were asked (whether the feature > >> > >>>>> could > >> > >>>>> > be contributed to ex-Sirona and whether that project would > >> be > >> > >>>>> > repatriated to "Commons") but not answered (unless I'm > >> > >>>>> mistaken)... > >> > >>>>> > > >> > >>>>> > Best, > >> > >>>>> > Gilles > >> > >>>>> > > >> > >>>>> > > >> > >>>>> >> Gary > >> > >>>>> >> > >> > >>>>> >> On Mar 8, 2018 08:58, "Otto Fowler" > >> <ottobackwa...@gmail.com> > >> > > wrote: > >> > >>>>> >> > >> > >>>>> >> So, could think about commons-misc or something? > >> > >>>>> >> I don’t think we are going to come up with a perfect > >> module > >> > >>>>> for > >> > >>>>> >> these > >> > >>>>> >> things. > >> > >>>>> >> > >> > >>>>> >> Maybe the way it can work is: > >> > >>>>> >> > >> > >>>>> >> commons-misc exists. > >> > >>>>> >> > >> > >>>>> >> It is the landing place for things that seem to be > >> outside the > >> > > scope > >> > >>>>> >> of > >> > >>>>> >> commons-xxxx, but don’t justify > >> > >>>>> >> a new module or sandbox effort. > >> > >>>>> >> > >> > >>>>> >> Things in misc can be reevaluated for inclusion in new > >> modules > >> > >>>>> at > >> > >>>>> >> things > >> > >>>>> >> go, and at that point @Depricated > >> > >>>>> >> out of misc. > >> > >>>>> >> > >> > >>>>> >> ? > >> > >>>>> >> > >> > >>>>> >> > >> > >>>>> >> > >> > >>>>> >> On March 3, 2018 at 00:42:12, Matt Sicker > >> (boa...@gmail.com) > >> > >>>>> wrote: > >> > >>>>> >> > >> > >>>>> >> On 2 March 2018 at 13:31, Oliver Heger > >> > >>>>> >> <oliver.he...@oliver-heger.de> > >> > >>>>> >> wrote: > >> > >>>>> >>> > >> > >>>>> >>> One other suggestion: It was stated in the past that the > >> > > concurrent > >> > >>>>> >>> classes are also a bit out of scope for [lang], > >> especially > >> > >>>>> the > >> > >>>>> >>> circuit > >> > >>>>> >>> breaker implementations. Would it make sense to move > >> those > >> > >>>>> into a > >> > >>>>> >>> new > >> > >>>>> >>> module, and could this be a home for the watch classes, > >> too? > >> > >>>>> >>> > >> > >>>>> >> > >> > >>>>> >> Considering the amount of retry libraries there are out > >> there, > >> > >>>>> I > >> > >>>>> >> think it > >> > >>>>> >> makes perfect sense for circuit breaker libraries to be > >> their > >> > >>>>> own > >> > >>>>> >> thing, > >> > >>>>> >> too. See Hysterix for example. > >> > >>>>> >> > >> > >>>>> >> -- > >> > >>>>> >> Matt Sicker <boa...@gmail.com> > >> > >>>>> > >> > >>>>> > >> > > >> > > >> > > >> --------------------------------------------------------------------- > >> > 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 > >
