+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
