Emmanuel Lécharny wrote:
> The way it was done in MINA was awfull : the log level ws always set
> to debug, and we overriden this level with our own level :
>
> if ( requestedLevel == DEBUG ) { Log.debug( blah ); }
Looking at LoggingFilter [1] and IOFilter [2], it looks like you have
found a work
I would agree with Niklas that LoggingFilter is quite useful in
FTPServer but of course there are other ways to do it.
I didn't follow your discussion too closely so excuse me if I'm wrong.
Do you mean that instead of logging e.g, only after the second
ProtocolCodecFilter you would log in all the
On Sun, Jan 10, 2010 at 7:52 PM, Emmanuel LŽcharny wrote:
>> Yes, I agree that it is unfortunate that slf4j do not provide a
>> generic log(Level, String) method in the same way as log4j. Given
>> Ceki's great knowledge in this area, I presume it's for good reasons.
>> However, another solution wo
Niklas Gustavsson a écrit :
On Sun, Jan 10, 2010 at 6:42 PM, Emmanuel Lecharny wrote:
That raise a slight issue here : with slf4j, we have no way to tell the
underlying framework that it should switch to some specific level, for
instance. Quite a dead end, so far :/
As mentioned, I do
On Sun, Jan 10, 2010 at 6:42 PM, Emmanuel Lecharny wrote:
> That raise a slight issue here : with slf4j, we have no way to tell the
> underlying framework that it should switch to some specific level, for
> instance. Quite a dead end, so far :/
As mentioned, I don't think this is in scope for MIN
Niklas Gustavsson a écrit :
- we would probably prefer to be able to activate those logs dynamicaly
I presume you mean in runtime (using JMX or whatever)?
yep.
If so, then
this sounds like something that should be delegated to the logging
framework the user chooses the use (log4j, logba
On Sun, Jan 10, 2010 at 6:17 PM, Niklas Gustavsson wrote:
> On Sun, Jan 10, 2010 at 5:26 PM, Emmanuel LŽcharny
> wrote:
>> At this point, regardless we need it or not, we should try to think about
>> what we want to do when logging :
>> - first, probably log only one single session, or at least
On Sun, Jan 10, 2010 at 5:26 PM, Emmanuel LŽcharny wrote:
> At this point, regardless we need it or not, we should try to think about
> what we want to do when logging :
> - first, probably log only one single session, or at least a selected number
> of session versus blindly log every sessions
>
I renamed this thread in order to be able to track it later.
Niklas Gustavsson a écrit :
On Sun, Jan 10, 2010 at 2:48 PM, Alan D. Cabrera wrote:
As for the fact that there are two ProtocolCodecFilters, that's not a
problem since you will be printing out the thread id in your log.
Yes
On Sun, Jan 10, 2010 at 2:48 PM, Alan D. Cabrera wrote:
> As for the fact that there are two ProtocolCodecFilters, that's not a
> problem since you will be printing out the thread id in your log.
Yes, but under heavy load you only want to log the very minimum you
can while still tracking down you
On Jan 9, 2010, at 11:54 AM, Emmanuel Lecharny wrote:
Niklas Gustavsson a écrit :
On Fri, Jan 8, 2010 at 5:25 PM, Emmanuel LŽcharny > wrote:
I was also thinking we should add some more filters like :
- a XML filter
- a JSON filter
- a HTTP Filter
Don't think these should belong in MINA Co
Alan D. Cabrera a écrit :
On Jan 9, 2010, at 11:54 AM, Emmanuel Lecharny wrote:
Alan D. Cabrera a écrit :
On Jan 8, 2010, at 6:03 AM, Emmanuel Lecharny wrote:
o SslFilter : I really think it shuld not be a filter, but a part
of the network layer. You negociate SSL first, then you accept
i
On Jan 9, 2010, at 11:54 AM, Emmanuel Lecharny wrote:
Alan D. Cabrera a écrit :
On Jan 8, 2010, at 6:03 AM, Emmanuel Lecharny wrote:
o SslFilter : I really think it shuld not be a filter, but a part
of the network layer. You negociate SSL first, then you accept
incoming messages.
I kno
On Jan 10, 2010, at 1:59 AM, Julien Vermillard wrote:
Le Sat, 9 Jan 2010 06:52:28 -0800,
"Alan D. Cabrera" a écrit :
If it could not be done any other way I would agree with you but I
think that we all agree that the premise to using it at all is that
someone else poorly instrumented his cod
On Jan 9, 2010, at 11:07 AM, Niklas Gustavsson wrote:
On Sat, Jan 9, 2010 at 3:46 PM, Alan D. Cabrera
wrote:
On Jan 9, 2010, at 6:31 AM, Niklas Gustavsson wrote:
In my case it been mostly ProtocolCodecFilter with TextLineDecoder
and
as a way of dumping the data before it reaches any decod
Julien Vermillard a écrit :
Le Sat, 9 Jan 2010 06:52:28 -0800,
"Alan D. Cabrera" a écrit :
If it could not be done any other way I would agree with you but I
think that we all agree that the premise to using it at all is that
someone else poorly instrumented his code. Plus it dilutes th
Le Sat, 9 Jan 2010 06:52:28 -0800,
"Alan D. Cabrera" a écrit :
> If it could not be done any other way I would agree with you but I
> think that we all agree that the premise to using it at all is that
> someone else poorly instrumented his code. Plus it dilutes the
> "regular" logging pat
Alan D. Cabrera a écrit :
On Jan 9, 2010, at 6:46 AM, Ashish wrote:
Seems like a good point. What out of the box filter was there that
you
could not fix it's poor logging?
In my case it been mostly ProtocolCodecFilter with TextLineDecoder and
as a way of dumping the data before it reaches
Niklas Gustavsson a écrit :
On Fri, Jan 8, 2010 at 5:25 PM, Emmanuel LŽcharny wrote:
I was also thinking we should add some more filters like :
- a XML filter
- a JSON filter
- a HTTP Filter
Don't think these should belong in MINA Core (but that probably not
what you are proposing eit
Alan D. Cabrera a écrit :
On Jan 8, 2010, at 6:03 AM, Emmanuel Lecharny wrote:
o SslFilter : I really think it shuld not be a filter, but a part of
the network layer. You negociate SSL first, then you accept incoming
messages.
I know that I am interested in receiving events such as SSL hand
On Sat, Jan 9, 2010 at 3:46 PM, Alan D. Cabrera wrote:
> On Jan 9, 2010, at 6:31 AM, Niklas Gustavsson wrote:
>> In my case it been mostly ProtocolCodecFilter with TextLineDecoder and
>> as a way of dumping the data before it reaches any decoder (for
>> example as a way of debugging charset issues
On Jan 9, 2010, at 6:46 AM, Ashish wrote:
Seems like a good point. What out of the box filter was there
that you
could not fix it's poor logging?
In my case it been mostly ProtocolCodecFilter with TextLineDecoder
and
as a way of dumping the data before it reaches any decoder (for
exampl
On Jan 9, 2010, at 6:31 AM, Niklas Gustavsson wrote:
On Sat, Jan 9, 2010 at 3:15 PM, Alan D. Cabrera
wrote:
Seems like a good point. What out of the box filter was there that
you
could not fix it's poor logging?
In my case it been mostly ProtocolCodecFilter with TextLineDecoder and
as a
>> Seems like a good point. What out of the box filter was there that you
>> could not fix it's poor logging?
>
> In my case it been mostly ProtocolCodecFilter with TextLineDecoder and
> as a way of dumping the data before it reaches any decoder (for
> example as a way of debugging charset issues)
On Sat, Jan 9, 2010 at 3:15 PM, Alan D. Cabrera wrote:
> Seems like a good point. What out of the box filter was there that you
> could not fix it's poor logging?
In my case it been mostly ProtocolCodecFilter with TextLineDecoder and
as a way of dumping the data before it reaches any decoder (fo
On Jan 9, 2010, at 6:11 AM, Niklas Gustavsson wrote:
On Sat, Jan 9, 2010 at 2:52 PM, Alan D. Cabrera
wrote:
Just curious. If one has properly instrumented one's code w/
logging, where
would this filter be useful?
As a way of logging whatever is sent over the wire, for example when
using
On Sat, Jan 9, 2010 at 2:52 PM, Alan D. Cabrera wrote:
> Just curious. If one has properly instrumented one's code w/ logging, where
> would this filter be useful?
As a way of logging whatever is sent over the wire, for example when
using a out-of-the-box filter. I've found it very valuable on m
On Jan 9, 2010, at 5:57 AM, Ashish wrote:
+1 on keeping LoggingFilter.
Just curious. If one has properly instrumented one's code w/
logging, where
would this filter be useful?
For dumping what we receive/send raw in each call. I found is useful
while debugging the XML codec code.
If th
>> +1 on keeping LoggingFilter.
>
> Just curious. If one has properly instrumented one's code w/ logging, where
> would this filter be useful?
For dumping what we receive/send raw in each call. I found is useful
while debugging the XML codec code.
If the code is well instrumented for these situa
On Jan 9, 2010, at 5:44 AM, Niklas Gustavsson wrote:
On Fri, Jan 8, 2010 at 4:27 PM, Ashish
wrote:
Though I think LoggingFilter is still useful. Its
easy to implement one, but we have something available, it can be
used
out of the box.
+1 on keeping LoggingFilter.
Just curious. If on
On Fri, Jan 8, 2010 at 4:27 PM, Ashish wrote:
> Though I think LoggingFilter is still useful. Its
> easy to implement one, but we have something available, it can be used
> out of the box.
+1 on keeping LoggingFilter.
/niklas
On Fri, Jan 8, 2010 at 5:25 PM, Emmanuel LŽcharny wrote:
> I was also thinking we should add some more filters like :
> - a XML filter
> - a JSON filter
> - a HTTP Filter
Don't think these should belong in MINA Core (but that probably not
what you are proposing either). But, they would be useful
On Jan 8, 2010, at 6:03 AM, Emmanuel Lecharny wrote:
o SslFilter : I really think it shuld not be a filter, but a part of
the network layer. You negociate SSL first, then you accept incoming
messages.
I know that I am interested in receiving events such as SSL handshake
started, complete
I was also thinking we should add some more filters like :
- a XML filter
- a JSON filter
- a HTTP Filter
assuming that there is no reason to consider them as just protocol
codec. We could implement them as simple filters, without the whole
ProtocolCodec mechanism callback et all)
Ashish a é
On Fri, Jan 8, 2010 at 7:33 PM, Emmanuel Lecharny wrote:
> Hi guys,
>
> in MINA 2, we have many different filters, and I'm not sure we need all of
> hem. Here is the list :
>
> o NoopFilter : probably useless...
> o ReferenceCountingFilter : Used to count the number of FilterChain we have
> (ie, t
Hi guys,
in MINA 2, we have many different filters, and I'm not sure we need all
of hem. Here is the list :
o NoopFilter : probably useless...
o ReferenceCountingFilter : Used to count the number of FilterChain we
have (ie, the number of session, somehow). Does not seems to be usefull...
o Se
36 matches
Mail list logo
