This stuff looks great, Romain! I do note the repeated misspelling of the
word "mechanism" ('h' omitted), but I'm quite impressed both with the site
as well as the work it is documenting.
Matt
On Mon, Aug 19, 2013 at 4:29 PM, Romain Manni-Bucau
<rmannibu...@gmail.com>wrote:
> 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
> >>>
> >>>
>
