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 >> >>
