commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Romain Manni-Bucau <rmannibu...@gmail.com>
Subject Re: commons-monitoring?
Date Thu, 01 Aug 2013 09:35:31 GMT
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.Maisonobe@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 <james@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
> > <rmannibucau@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-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message