Up? Ps: here is a preview of the website http://rmannibucau.github.io/commons-monitoring-dev/ Le 10 août 2013 09:16, "Romain Manni-Bucau" <rmannibu...@gmail.com> a écrit :
> Hi > > How to go ahead with it? > Le 6 août 2013 04:07, "Romain Manni-Bucau" <rmannibu...@gmail.com> a > écrit : > >> I thought to "i see you" or "i watch you"..., the idea being to get i and >> y at the start and end to do "iwy" or "isy" which is a bit fun and could be >> represented by a small and funny animal. >> Le 6 août 2013 04:04, "Olivier Lamy" <ol...@apache.org> a écrit : >> >>> 2013/8/5 Romain Manni-Bucau <rmannibu...@gmail.com>: >>> > Hi guys, >>> > >>> > here where i am >>> > >>> > 1) we have a Repository class (more a singleton concept to get access >>> to >>> > next objects), it uses a DataStore to create/find/update two kind of >>> > measures: counters (value + stat, it manages concurrency info) and >>> gauge >>> > (history of values) >>> > 2) we have a Configuration class which handles the configuration which >>> > manages two things: configurations (key/value) and very very >>> lightweight >>> > kind of IoC (relying on key/values). It uses properties ATM but it can >>> > evolve. >>> > 3) to measure method duration we have several modules: spring (using >>> > aopalliance), aspectj, cdi, aop (manual using commons-proxy) >>> > 4) we have a jdbc module for jdbc interception. The more common way to >>> do >>> > so is to use org.apache.commons.monitoring.jdbc.MonitoringDriver and a >>> jdbc >>> > url: >>> jdbc:monitoring:hsqldb:mem:monitoring?delegateDriver=org.hsqldb.jdbcDriver >>> > 5) a light GUI. It is packages as a jar and war (without core and jdbc >>> > since these ones are often in the container). It uses a basic filter >>> then >>> > delegates to Handlers/Renderers. It includes the concept of Plugins >>> (all >>> > the GUI excepted the home page uses it. It has ATM a JVM (memory/cpu), >>> > Report (counters), JMX (mbeans) plugins. Plugin uses a ServiceLoader >>> SPI. >>> > 6) Gauges: Gauge is a SPI, the interface just defines how to measure >>> the >>> > value, what's the period and the role (name). Note: GaugeFactory is >>> another >>> > SPI to be able to get implementations of Gauge reusable so these gauges >>> > will not use the Gauge SPI. >>> > >>> > Todo / open questions: >>> > 1) move commons-monitoring to an incubator project? i think it doesn't >>> > really match commons anymore since there are several modules + it is a >>> bit >>> > complicated because of the reporting module/deployment + it can really >>> be >>> > enhanced to get some more important features (several DataStore >>> > implementations, aggregation...) >>> >>> Yup make sense to move that. >>> Maybe starting a discussion at incubator to find some other interested >>> folks? >>> >>> BTW we have to find an other name (check here >>> http:://monitoring.apache.org not sure infra folks will be happy to >>> change that :-) ) >>> >>> > 2) little bench to get an idea of the overhead >>> > 3) (i'll start tomorrow i think) rework the website to get something >>> up to >>> > date and usable >>> > >>> > *Romain Manni-Bucau* >>> > *Twitter: @rmannibucau <https://twitter.com/rmannibucau>* >>> > *Blog: **http://rmannibucau.wordpress.com/*< >>> http://rmannibucau.wordpress.com/> >>> > *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* >>> > *Github: https://github.com/rmannibucau* >>> > >>> > >>> > >>> > 2013/8/1 Olivier Lamy <ol...@apache.org> >>> > >>> >> +1 >>> >> >>> >> 2013/8/1 Romain Manni-Bucau <rmannibu...@gmail.com>: >>> >> > Do we want to keep cxf module? >>> >> > >>> >> > IMO it can be replaced by a monitoring filter (web module) >>> >> > >>> >> > wdyt? >>> >> > >>> >> > *Romain Manni-Bucau* >>> >> > *Twitter: @rmannibucau <https://twitter.com/rmannibucau>* >>> >> > *Blog: **http://rmannibucau.wordpress.com/*< >>> >> http://rmannibucau.wordpress.com/> >>> >> > *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* >>> >> > *Github: https://github.com/rmannibucau* >>> >> > >>> >> > >>> >> > >>> >> > 2013/7/31 Luc Maisonobe <luc.maison...@free.fr> >>> >> > >>> >> >> Le 28/07/2013 18:30, Mark Struberg a écrit : >>> >> >> > Hi folks! >>> >> >> > >>> >> >> > Romain is a great guy, I've now added him to commons-sandbox. >>> >> >> >>> >> >> Thanks Mark. >>> >> >> >>> >> >> I am really sorry for the delay. I have just read today the mail >>> >> >> Benedikt sent me 5 days ago :-( >>> >> >> >>> >> >> sorry >>> >> >> Luc >>> >> >> >>> >> >> > >>> >> >> > LieGrue, >>> >> >> > strub >>> >> >> > >>> >> >> > >>> >> >> > >>> >> >> > >>> >> >> > ----- Original Message ----- >>> >> >> > From: James Carman <ja...@carmanconsulting.com> >>> >> >> > To: Commons Developers List <dev@commons.apache.org> >>> >> >> > Cc: >>> >> >> > Sent: Saturday, 27 July 2013, 3:46 >>> >> >> > Subject: Re: commons-monitoring? >>> >> >> > >>> >> >> > On Fri, Jul 26, 2013 at 9:36 PM, Romain Manni-Bucau >>> >> >> > <rmannibu...@gmail.com> wrote: >>> >> >> >> Well we can discuss it in another thread but basically commons >>> spirit >>> >> >> for >>> >> >> >> me is more basic and shouldn't be a facade (excepted logging). >>> So i'd >>> >> >> >> rather see proxy as an implementation of proxying using asm >>> >> efficiently. >>> >> >> >> The issue with proxying is not its lifecycle or API in general >>> but >>> >> its >>> >> >> >> specificities (cache, proxy names, handlers...). The best >>> solution >>> >> IMO >>> >> >> is >>> >> >> >> to propose a unified solution which could be a facade but facade >>> >> means >>> >> >> all >>> >> >> >> impl specificities in its API which makes it harder or specific >>> (in >>> >> v1 >>> >> >> >> instantiating the factory was a pain IMO since it is specific). >>> ATM >>> >> the >>> >> >> >> question for me is always which one do i import depending my >>> >> container, >>> >> >> do >>> >> >> >> i test against all proxies impl? Etc... it makes libs hard to >>> write >>> >> and >>> >> >> >> maintain >>> >> >> > >>> >> >> > Great feedback! Please start another thread so we can discuss. >>> >> >> > >>> >> >> > >>> --------------------------------------------------------------------- >>> >> >> > 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 >>> >> >> > >>> >> >> > >>> >> >> >>> >> >> >>> >> >> >>> --------------------------------------------------------------------- >>> >> >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>> >> >> For additional commands, e-mail: dev-h...@commons.apache.org >>> >> >> >>> >> >> >>> >> >>> >> >>> >> >>> >> -- >>> >> Olivier Lamy >>> >> Ecetera: http://ecetera.com.au >>> >> http://twitter.com/olamy | http://linkedin.com/in/olamy >>> >> >>> >> --------------------------------------------------------------------- >>> >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>> >> For additional commands, e-mail: dev-h...@commons.apache.org >>> >> >>> >> >>> >>> >>> >>> -- >>> Olivier Lamy >>> Ecetera: http://ecetera.com.au >>> http://twitter.com/olamy | http://linkedin.com/in/olamy >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >>>
