Hi, thanks Mark but i still get issues:
โ( rmannibucau @ ubuntu )โ( 1.7.0 -:- 3.1.0 ) โ( /opt/dev/tomee/commons-monitoring )ยท> svn ci -m "removing gauge which weren't really gauge, replacing it by a counter in counters, adding basic config, splitting in several modules, adding some js sorting/filtering in html format" Sending PROPOSAL.html Adding aop svn: E195023: Commit failed (details follow): svn: E195023: Changing directory '/opt/dev/tomee/commons-monitoring/aop' is forbidden by the server svn: E175013: Access to '/repos/asf/!svn/rvr/1506987/commons/sandbox/monitoring/trunk/instrumentation' forbidden btw here is a patch with a little html with js sorting/filtering https://gist.github.com/rmannibucau/738df316addfe0f14974 i used tablesorter plugin for jquery, both are under MIT license so it should be fine (please correct me if not). About it i wonder if we should paginate or not the rendering (i started with but it can be done using http://mottie.github.io/tablesorter/docs/example-pager-ajax.html - ATM i'm not sure it would be useful) + which techno to use to build the website associated to the reporting module (ATM the whole HTML is generated by HTML format/MonitoringServlet but there is a single page ;) *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/28 Mark Struberg <strub...@yahoo.de> > Hi folks! > > Romain is a great guy, I've now added him to commons-sandbox. > > 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 > >
