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