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