You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mina.apache.org by Emmanuel Lecharny <el...@gmail.com> on 2010/01/08 15:03:59 UTC
[MINA 3.0] Which filters should we keep ?
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 SessionAttributeInitializingFilter : Used to inject some default
attributes in the session when it's created. Same : probably superfluous
o FileRegionWriteFilter : Converts FileRegion to IoBuffer. Not convinced
about the interest of such a filter ...
o StreamWriteFilter : I do think that it's not the Filter purpose to
handle the messages that are to be written. We should instead define an
interface for messages that allow the system to write them, whatever the
container used.
o ProfilerTimerFilter : Shouldn't it be a part of the core system, in
coordination with JMX ? When using a filter to do some timing, we lose a
part of the action, as we have some processing bing done before the
filter is called...
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.
o RequestResponseFilter : Due to the total lack of doco ( cf "TODO Add
documentation"), it's difficult to say anything about this Filte. Maybe
by reading http://issues.apache.org/jira/browse/DIRMINA-92?
o BlacklistFilter : Supposely block IPs. Uses a List internally, most
certinly suboptimal. Probably useful to have.
o BufferedWriteFilter : Useful ? Not sure... probably better to disable
Naggle Algorithm and let the underlying network layer dealing with this.
Not sure...
o MdcInjectionFilter : Useful, definitively
o ConnectionThrottleFilter : Useful.
o ErrorGeneratingFilter : Was supposed to be designed for tests. Not
sure it's useful.
o ExecutorFilter : Mandatory.
o KeepAliveFilter : Never used it, but I think it can be useful.
o LoggingFilter : I'm really not convinced it's a good to have filter.
People can define such a Filter using their prefered logging system so
easily, I don't see the intrest to have such a filter in core...
o ProtocolCodecFilter : Must have, but needs a lot of refactoring.
o ProxyFilter : Let's keep it. I don't like its name, because I'm not
sure it's explaining exactly what his filter is doing, but I'm also
probably not smart enough :)
o CompressionFilter : Must have !
o WriteRequestFilter : I don't really understand the need fo such a
filter... But I have not analyzed it in detail. Waiting for insights
That pretty much it for MINA 2. So far, I think we can restreint the
list of usful filters to :
- BlacklistFilter
- MdcInjectionFilter
- ConnectionThrottleFilter
- ExecutorFilter
- KeepAliveFilter
- ProtocolCodecFilter
- ProxyFilter
- CompressionFilter
wdyt ?
--
Regards,
Cordialement,
Emmanuel Lécharny
www.nextury.com
Re: [MINA 3.0] Which filters should we keep ?
Posted by Emmanuel Lcharny <el...@gmail.com>.
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
>>>> incoming messages.
>>>
>>> I know that I am interested in receiving events such as SSL
>>> handshake started, completed, renegotiation, etc. Why do you think
>>> that it needs to be part of the network layer?
>> Being able to receive such notification is not related to the fact
>> that the SSL handling is done in Filters. To me, SSL handshaking on
>> NIO should have been a part of NIO, as it was a part of the standard
>> IO API. I don't see the rational behind this choice, but I see no
>> reason to inflict our users with such a problem like what they get if
>> they put the SSLFilter at the wrong place in the chain.
>
> Filters convert messages as they pass up and down the stack. SSL is
> no different. I don't think that it's an undue burden to expect a
> certain level of competency so as to require that they know where to
> place filters in their stacks.
>
> To my mind, SSL is a filter just as much as anything else, e.g.
> POJO<->JSON filter. It seems to be that we arbitrarily culling out
> SSL and thereby loosing the consistency in our filter classifications.
>
> IMO, Mina suffers from this problem and the number of different kinds
> of classes demonstrates it.
I'm plain wrong here. I realized that it's not because the SslFilter is
conveying encrypted data that you won't do anything *before*. For
instance, one may perfectly want to inject an Executor filter to spread
the wrap/unwrap load onto many threads. In this case, having the
SslFilter is a good thing.
Forget about my suggestion, it was illy.
>
>> Now, when it comes to the cases where you want to be informed about
>> renegotiation, or simply that you are on a secured connection, I must
>> say that I overlooked this point when I posted my other mail about
>> the message I want to remove : the "SECURED" one. We can't remove
>> this message from MINA 2.0, as it will negatively impact our users
>> who has based their handlers or codec on the assomption that the very
>> first received message will be this one.
>>
>> For MINA 3.0, I think we should get rid of it. Either we implement a
>> notification mechanism (à la Servlet), or - better IMHO - we can also
>> add a new event like notificationReceived() for such a use case.
>> Notification could cover all the SSL things, or any other we can
>> think about.
>
> I assume that you are speaking of notification via listener
> interfaces. I like that. I hope that we don't end up with a swiss
> army knife of a listener; not that I hear that on this list but just
> expressing a general concern.
More or less. We can discuss this aspect on another thread, for clarity.
Re: [MINA 3.0] Which filters should we keep ?
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
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 know that I am interested in receiving events such as SSL
>> handshake started, completed, renegotiation, etc. Why do you think
>> that it needs to be part of the network layer?
> Being able to receive such notification is not related to the fact
> that the SSL handling is done in Filters. To me, SSL handshaking on
> NIO should have been a part of NIO, as it was a part of the standard
> IO API. I don't see the rational behind this choice, but I see no
> reason to inflict our users with such a problem like what they get
> if they put the SSLFilter at the wrong place in the chain.
Filters convert messages as they pass up and down the stack. SSL is
no different. I don't think that it's an undue burden to expect a
certain level of competency so as to require that they know where to
place filters in their stacks.
To my mind, SSL is a filter just as much as anything else, e.g. POJO<-
>JSON filter. It seems to be that we arbitrarily culling out SSL and
thereby loosing the consistency in our filter classifications.
IMO, Mina suffers from this problem and the number of different kinds
of classes demonstrates it.
> Now, when it comes to the cases where you want to be informed about
> renegotiation, or simply that you are on a secured connection, I
> must say that I overlooked this point when I posted my other mail
> about the message I want to remove : the "SECURED" one. We can't
> remove this message from MINA 2.0, as it will negatively impact our
> users who has based their handlers or codec on the assomption that
> the very first received message will be this one.
>
> For MINA 3.0, I think we should get rid of it. Either we implement a
> notification mechanism (à la Servlet), or - better IMHO - we can
> also add a new event like notificationReceived() for such a use
> case. Notification could cover all the SSL things, or any other we
> can think about.
I assume that you are speaking of notification via listener
interfaces. I like that. I hope that we don't end up with a swiss
army knife of a listener; not that I hear that on this list but just
expressing a general concern.
Regards,
Alan
Re: [MINA 3.0] Which filters should we keep ?
Posted by Emmanuel Lecharny <el...@gmail.com>.
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 handshake
> started, completed, renegotiation, etc. Why do you think that it
> needs to be part of the network layer?
Being able to receive such notification is not related to the fact that
the SSL handling is done in Filters. To me, SSL handshaking on NIO
should have been a part of NIO, as it was a part of the standard IO API.
I don't see the rational behind this choice, but I see no reason to
inflict our users with such a problem like what they get if they put the
SSLFilter at the wrong place in the chain.
Now, when it comes to the cases where you want to be informed about
renegotiation, or simply that you are on a secured connection, I must
say that I overlooked this point when I posted my other mail about the
message I want to remove : the "SECURED" one. We can't remove this
message from MINA 2.0, as it will negatively impact our users who has
based their handlers or codec on the assomption that the very first
received message will be this one.
For MINA 3.0, I think we should get rid of it. Either we implement a
notification mechanism (à la Servlet), or - better IMHO - we can also
add a new event like notificationReceived() for such a use case.
Notification could cover all the SSL things, or any other we can think
about.
>
>
> Regards,
> Alan
>
>
--
Regards,
Cordialement,
Emmanuel Lécharny
www.nextury.com
Re: [MINA 3.0] Which filters should we keep ?
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
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, completed, renegotiation, etc. Why do you think that it
needs to be part of the network layer?
Regards,
Alan
Re: [MINA 3.0] Which filters should we keep ?
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
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 the code is well instrumented for these situations, the filter
> doesn't may not be needed :-)
I think that we should not provide extra code to support bad
habits. :)
Regards,
Alan
Re: [MINA 3.0] Which filters should we keep ?
Posted by Ashish <pa...@gmail.com>.
>> +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 situations, the filter
doesn't may not be needed :-)
--
thanks
ashish
Blog: http://www.ashishpaliwal.com/blog
My Photo Galleries: http://www.pbase.com/ashishpaliwal
Re: [MINA 3.0] Logging filter was Re: [MINA 3.0] Which filters should
we keep ?
Posted by Niklas Gustavsson <ni...@protocol7.com>.
On Sun, Jan 10, 2010 at 7:52 PM, Emmanuel LŽcharny <el...@gmail.com> 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 would be to allow the user to inject his own
>> logger into the logging filter.
>>
>
> I think that CLog does not support level setting, it's probably why SLF4J
> does not allow such an operation.
slf4j could have done a switch statement to handle that. I suspect the
reason being Ceki's bad experience (as far as I understand) with
people expectations on making up their own custom levels in log4j.
> We can also provide a Log4jLoggingFilter and a LogBackLogging Filter too...
I think giving power users to option to inject a slf4j logger is the
best solution to the problem anyways.
/niklas
Re: [MINA 3.0] Logging filter was Re: [MINA 3.0] Which filters should
we keep ?
Posted by Niklas Gustavsson <ni...@protocol7.com>.
On Sun, Jan 10, 2010 at 6:17 PM, Niklas Gustavsson <ni...@protocol7.com> wrote:
> On Sun, Jan 10, 2010 at 5:26 PM, Emmanuel LŽcharny <el...@gmail.com> 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
>> - we would also like to be able to log at some specific point in the chain,
>> or even better at different points in the chain
>> - we may want to log only some specific events (Read, Session created, ...)
>> - we may also like to define a log level for each of those logs
>
> All these sound reasonable?
Should have been without the question mark :-)
/niklas
Re: [MINA 3.0] Logging filter was Re: [MINA 3.0] Which filters should
we keep ?
Posted by Emmanuel Lcharny <el...@gmail.com>.
Niklas Gustavsson a écrit :
> On Sun, Jan 10, 2010 at 6:42 PM, Emmanuel Lecharny <el...@gmail.com> 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 MINA. If the user,
> for example has chosen to use log4j, he would do this using the log4j
> API (in which slf4j will create a logger). We do not need to care.
>
right.
>
>> 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 );
>> }
>>
>
> 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 would be to allow the user to inject his own
> logger into the logging filter.
>
I think that CLog does not support level setting, it's probably why
SLF4J does not allow such an operation.
We can also provide a Log4jLoggingFilter and a LogBackLogging Filter too...
> /niklas
>
>
Re: [MINA 3.0] Logging filter was Re: [MINA 3.0] Which filters should
we keep ?
Posted by Niklas Gustavsson <ni...@protocol7.com>.
On Sun, Jan 10, 2010 at 6:42 PM, Emmanuel Lecharny <el...@gmail.com> 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 MINA. If the user,
for example has chosen to use log4j, he would do this using the log4j
API (in which slf4j will create a logger). We do not need to care.
> 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 );
> }
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 would be to allow the user to inject his own
logger into the logging filter.
/niklas
Re: [MINA 3.0] Logging filter was Re: [MINA 3.0] Which filters should
we keep ?
Posted by Emmanuel Lecharny <el...@gmail.com>.
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, logback, OSGi logging and
> so on).
>
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 :/
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 );
}
This make it very difficult to provide a LoggingFilter covering all the
previous features, specifically the last two points (defining a log
level for each event) (dynamically active logs).
--
Regards,
Cordialement,
Emmanuel Lécharny
www.nextury.com
Re: [MINA 3.0] Logging filter was Re: [MINA 3.0] Which filters should
we keep ?
Posted by Niklas Gustavsson <ni...@protocol7.com>.
On Sun, Jan 10, 2010 at 5:26 PM, Emmanuel LŽcharny <el...@gmail.com> 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
> - we would also like to be able to log at some specific point in the chain,
> or even better at different points in the chain
> - we may want to log only some specific events (Read, Session created, ...)
> - we may also like to define a log level for each of those logs
All these sound reasonable?
> - we would probably prefer to be able to activate those logs dynamicaly
I presume you mean in runtime (using JMX or whatever)? If so, then
this sounds like something that should be delegated to the logging
framework the user chooses the use (log4j, logback, OSGi logging and
so on).
/niklas
[MINA 3.0] Logging filter was Re: [MINA 3.0] Which filters should
we keep ?
Posted by Emmanuel Lcharny <el...@gmail.com>.
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 <li...@toolazydogs.com> 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 your problem, therefore you need to be
> able to switch on logging at a very specific point in the filter
> chain.
>
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
- we would also like to be able to log at some specific point in the
chain, or even better at different points in the chain
- we may want to log only some specific events (Read, Session created, ...)
- we may also like to define a log level for each of those logs
- we would probably prefer to be able to activate those logs dynamicaly
Is there anything I miss ?
>>> Besides, I'll bet LoggingFilter is, with ProtocolCodecFilter and maybe
>>> ExecutorFilter, by far the most used filters by our users.
>>>
>> Just because it's a widespread bad habit.. ;)
>>
>
> Tastes differ I presume :-)
>
Especially bad tastes ;) However, some are generally really widely
spread ! (note that I don't blame anyone to have different bad tastes
than mine
Re: [MINA 3.0] Which filters should we keep ?
Posted by David Latorre <dv...@gmail.com>.
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 filters all the time?
so now, let's say we have 4 filters in our ,i don't know, Mina-based
FPClient. Instead of having a filter logging the commands sent (as
FTPServer currently does, which is SO useful to track a connection -
maybe it's only our customers, but I have to monitor their connections
quite often to explain what they did wrong), we would have 4 filters
logging probably at the same level so the log file would be cluttered
( or we wouldn't have any logs whatsoever) unless the programmers
using MINA logged the communication themselves, is that what you are
suggesting?
2010/1/10 Niklas Gustavsson <ni...@protocol7.com>:
> On Sun, Jan 10, 2010 at 2:48 PM, Alan D. Cabrera <li...@toolazydogs.com> 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 your problem, therefore you need to be
> able to switch on logging at a very specific point in the filter
> chain.
>
>>> Besides, I'll bet LoggingFilter is, with ProtocolCodecFilter and maybe
>>> ExecutorFilter, by far the most used filters by our users.
>>
>> Just because it's a widespread bad habit.. ;)
>
> Tastes differ I presume :-)
>
> /niklas
>
Re: [MINA 3.0] Which filters should we keep ?
Posted by Niklas Gustavsson <ni...@protocol7.com>.
On Sun, Jan 10, 2010 at 2:48 PM, Alan D. Cabrera <li...@toolazydogs.com> 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 your problem, therefore you need to be
able to switch on logging at a very specific point in the filter
chain.
>> Besides, I'll bet LoggingFilter is, with ProtocolCodecFilter and maybe
>> ExecutorFilter, by far the most used filters by our users.
>
> Just because it's a widespread bad habit.. ;)
Tastes differ I presume :-)
/niklas
Re: [MINA 3.0] Which filters should we keep ?
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
On Jan 9, 2010, at 11:07 AM, Niklas Gustavsson wrote:
> On Sat, Jan 9, 2010 at 3:46 PM, Alan D. Cabrera
> <li...@toolazydogs.com> 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). Of course, in the
>>> case
>>> of ProtocolCodecFilter we could add logging before and after
>>> invoking
>>> the decoder, but I find a filter to be way clean-cut way of doing
>>> it.
>>
>> Aren't these filters in Mina? I guess I still think that it's a
>> crutch for
>> poor logging practices and removes the impetus for the community to
>> go back
>> and improve the code.
>
> Yes, they are in MINA, but I probably did not make my point as clear
> as I've could. Logging could clearly be implemented in several ways as
> you note. In my view, I think LoggingFilter is a very clean way of
> performing logging from the filter chain (or similar replacements).
> I'll try to better illustrate why I think so. Let's say we got a
> simple filter chain with two ProtocolCodecFilters. Now, to provide
> configurable logging from this chain, we would need to come up with a
> naming convention for the loggers to be able to provide logging from
> the three points where logging could be of interest (before the first
> filter, after the first decoding, after the second decoding) so that
> users could active debug logging at any of these points. In my view, I
> providing a logging filter that is possible to insert in any of these
> places is not only the simplest and cleanest solution, but also the
> best. Besides, is provides a standard way of providing logging from
> the filter chain, not having to figure out each filters (shipped with
> MINA or not) way of logging. So, I do not view this as a hack around
> bad logging practice.
If you're debugging a filter then wouldn't you have to have a modicum
of understanding of how it works? I think attaching a sensor to the
end and watching what comes out is a bad practice, not when one can
turn on the logging for the filters themselves. Also, the
intermediate filters should be logging what they are receiving.
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.
> Besides, I'll bet LoggingFilter is, with ProtocolCodecFilter and maybe
> ExecutorFilter, by far the most used filters by our users.
Just because it's a widespread bad habit.. ;)
I'm not adamantly against this filter. Just trying to review each one
with a critical eye and I still don't see the need because I still
think that it's a crutch for a poor practice. If it does stay I would
prefer that it goes into a toolbox jar and not the core jar.
Regards,
Alan
Re: [MINA 3.0] Which filters should we keep ?
Posted by Niklas Gustavsson <ni...@protocol7.com>.
On Sat, Jan 9, 2010 at 3:46 PM, Alan D. Cabrera <li...@toolazydogs.com> 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). Of course, in the case
>> of ProtocolCodecFilter we could add logging before and after invoking
>> the decoder, but I find a filter to be way clean-cut way of doing it.
>
> Aren't these filters in Mina? I guess I still think that it's a crutch for
> poor logging practices and removes the impetus for the community to go back
> and improve the code.
Yes, they are in MINA, but I probably did not make my point as clear
as I've could. Logging could clearly be implemented in several ways as
you note. In my view, I think LoggingFilter is a very clean way of
performing logging from the filter chain (or similar replacements).
I'll try to better illustrate why I think so. Let's say we got a
simple filter chain with two ProtocolCodecFilters. Now, to provide
configurable logging from this chain, we would need to come up with a
naming convention for the loggers to be able to provide logging from
the three points where logging could be of interest (before the first
filter, after the first decoding, after the second decoding) so that
users could active debug logging at any of these points. In my view, I
providing a logging filter that is possible to insert in any of these
places is not only the simplest and cleanest solution, but also the
best. Besides, is provides a standard way of providing logging from
the filter chain, not having to figure out each filters (shipped with
MINA or not) way of logging. So, I do not view this as a hack around
bad logging practice.
Besides, I'll bet LoggingFilter is, with ProtocolCodecFilter and maybe
ExecutorFilter, by far the most used filters by our users.
/niklas
Re: [MINA 3.0] Which filters should we keep ?
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
On Jan 9, 2010, at 6:31 AM, Niklas Gustavsson wrote:
> On Sat, Jan 9, 2010 at 3:15 PM, Alan D. Cabrera
> <li...@toolazydogs.com> 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
> example as a way of debugging charset issues). Of course, in the case
> of ProtocolCodecFilter we could add logging before and after invoking
> the decoder, but I find a filter to be way clean-cut way of doing it.
Aren't these filters in Mina? I guess I still think that it's a
crutch for poor logging practices and removes the impetus for the
community to go back and improve the code.
Regards,
Alan
Re: [MINA 3.0] Which filters should we keep ?
Posted by Emmanuel Lecharny <el...@gmail.com>.
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 any decoder (for
>>> example as a way of debugging charset issues). Of course, in the case
>>> of ProtocolCodecFilter we could add logging before and after invoking
>>> the decoder, but I find a filter to be way clean-cut way of doing it.
>>
>> I think I agree with Niklas. Using Logging filter is much more
>> cleaner :-)
>
>
> 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 pattern that's already in use in most projects.
>
> That's one of the problems with the Mina code base and accounts for a
> significant amount of code bloat, that being everyone tacking on
> orthogonal bits.
>
> Maybe a debugger's toolbox that would go in a separate jar would be a
> good compromise. Though I'm still of t he opinion that it's a crutch
> for poor logging practices and removes the impetus for the community
> to go back and improve the code.
I'm totally in line with Alan's vision. It's not because you only have a
hammer that you should not complain about the lack of a saw in the
toolbax when you need to cut a piece of wood. It's really more difficult
to cut it in to with a hammer, trust me on that, I already tried :)
More seriously, I don't like AOP, but here, I think this is a case where
the idea behind AOP is sane : you don't want to bloat your code with
extra filters just because you want to understand what's going on. Also
I find it painfull to have to add this filter maybe at different places
in the chain just to get a clue about what's wrong.
Why not simply configure Log4J/Logback/clog/whatever to get thos
meessages ? Why not also ask the filter manager to produce those logs,
without having to add a filter ? It should be just a matter of adding
extra log traces in the existing code (which really suffer from a total
lack of logs anyway - people complain about the lack of doco, but lacks
of logs and lack of tests are also deadly ...-
Let keep it simple, and let's try to do things at the level where they
should be done...
>
>
> Regards,
> Alan
>
>
>
--
Regards,
Cordialement,
Emmanuel Lécharny
www.nextury.com
Re: [MINA 3.0] Which filters should we keep ?
Posted by Emmanuel Lecharny <el...@gmail.com>.
Julien Vermillard a écrit :
> Le Sat, 9 Jan 2010 06:52:28 -0800,
> "Alan D. Cabrera" <li...@toolazydogs.com> 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 pattern that's already in use in most projects.
>>
>> That's one of the problems with the Mina code base and accounts for
>> a significant amount of code bloat, that being everyone tacking on
>> orthogonal bits.
>>
>
> +1
>
> For me a DEBUG statement in and out of each transformation filter killed
> the use of LoggingFilter.
>
> But if the LoggingFilter is useful for some use, I don't mind if we
> keep it, it's a very thin bloat ;)
>
If it were correctly implemented, I would also say 'keep it'. The
problem is that the current implement simply sucks ice (I know what I'm
talking about : I have tried to fix it months ago, and I don't think
it's possible to reach a stable state where it's convenient *and*
powerfull).
What sucks here is that you can't define a log level for each message
and get it logged unless you setup your underlying log system correctly
at the same time. There is nothing we can do about that since we use
Slf4j which is a facade, which forbid us to tell the underlying logger
to switch to another level programatically.
Now, there are three things we have to consider :
- if the user does not implement logs in his filter, this can be usefull
to offer a basic logger
- the current logger does not car about the type of message, it just
call its toString() method. For IoBuffer, you'll get the 16 first bytes
only. Not necessarily usefull...
- OTOH, if the user didn't implemented a toString() method for his
Message, then he will get a very explicit @ddress... How usefull !
Should we offer a substitute for user lazyness ? I mean, logs are as
important as javadoc, tests and exception handling in a program, why
should we just give the impression to a user that by using this weak
logger he can spare us stupid questions about what's going on in his
buggy code ? I'm not talking about power users here, I'm talking about
those who won't do the effort to understand what's going on in *their*
code before asking on the user's ML when the LoggingFilter will just
dump a useless piece of information...
Don't get me wrong : all our users are not lazzy, nor stupid. Most of
them are probably smarter than we can be. It's just that we may induce
some false confidence by providing some weak tooling. I really think
that the LoggingFilter is one of the worst substitute for decent user's
logging...
Btw, one last point : we *have* to provide decent logging in *our*
filters too. The reason people might want to use this LoggingFilter is
that we don't logs in the filters. This is *our* fault, and it has to be
fixed.
I know I'm pretty vocal about this thing, and I may prefectly be wrong,
or at least I may be isolated with this opinion, so I think that if we
can't reach a conclusion, then a vote would be a valuable action. It's
not the heart of the system, and I don't think it worths fighting for
days about it, so if the majority thinks that we must keep this logger,
I would bend and accept the vote without a glitch. I consider that
beside the discutable interest of such a filter, it's a totally harmless
piece of coe.
--
Regards,
Cordialement,
Emmanuel Lécharny
www.nextury.com
Re: [MINA 3.0] Which filters should we keep ?
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
On Jan 10, 2010, at 1:59 AM, Julien Vermillard wrote:
> Le Sat, 9 Jan 2010 06:52:28 -0800,
> "Alan D. Cabrera" <li...@toolazydogs.com> 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 pattern that's already in use in most projects.
>>
>> That's one of the problems with the Mina code base and accounts for
>> a significant amount of code bloat, that being everyone tacking on
>> orthogonal bits.
>
> +1
>
> For me a DEBUG statement in and out of each transformation filter
> killed
> the use of LoggingFilter.
>
> But if the LoggingFilter is useful for some use, I don't mind if we
> keep it, it's a very thin bloat ;)
Apply "it's a very thin bloat" over and over and you end up w/ ...
Part of the discipline of library design is to remove possibly
seemingly innocuous features that are used to promote bad practices.
Regards,
Alan
Re: [MINA 3.0] Which filters should we keep ?
Posted by Julien Vermillard <jv...@archean.fr>.
Le Sat, 9 Jan 2010 06:52:28 -0800,
"Alan D. Cabrera" <li...@toolazydogs.com> 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 pattern that's already in use in most projects.
>
> That's one of the problems with the Mina code base and accounts for
> a significant amount of code bloat, that being everyone tacking on
> orthogonal bits.
+1
For me a DEBUG statement in and out of each transformation filter killed
the use of LoggingFilter.
But if the LoggingFilter is useful for some use, I don't mind if we
keep it, it's a very thin bloat ;)
Julien
--
Julien Vermillard
Archean Technologies
http://www.archean.fr
Re: [MINA 3.0] Which filters should we keep ?
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
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
>> example as a way of debugging charset issues). Of course, in the case
>> of ProtocolCodecFilter we could add logging before and after invoking
>> the decoder, but I find a filter to be way clean-cut way of doing it.
>
> I think I agree with Niklas. Using Logging filter is much more
> cleaner :-)
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 pattern that's already in use in most projects.
That's one of the problems with the Mina code base and accounts for a
significant amount of code bloat, that being everyone tacking on
orthogonal bits.
Maybe a debugger's toolbox that would go in a separate jar would be a
good compromise. Though I'm still of t he opinion that it's a crutch
for poor logging practices and removes the impetus for the community
to go back and improve the code.
Regards,
Alan
Re: [MINA 3.0] Which filters should we keep ?
Posted by Ashish <pa...@gmail.com>.
>> 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). Of course, in the case
> of ProtocolCodecFilter we could add logging before and after invoking
> the decoder, but I find a filter to be way clean-cut way of doing it.
I think I agree with Niklas. Using Logging filter is much more cleaner :-)
--
thanks
ashish
Blog: http://www.ashishpaliwal.com/blog
My Photo Galleries: http://www.pbase.com/ashishpaliwal
Re: [MINA 3.0] Which filters should we keep ?
Posted by Niklas Gustavsson <ni...@protocol7.com>.
On Sat, Jan 9, 2010 at 3:15 PM, Alan D. Cabrera <li...@toolazydogs.com> 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
example as a way of debugging charset issues). Of course, in the case
of ProtocolCodecFilter we could add logging before and after invoking
the decoder, but I find a filter to be way clean-cut way of doing it.
/niklas
Re: [MINA 3.0] Which filters should we keep ?
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
On Jan 9, 2010, at 6:11 AM, Niklas Gustavsson wrote:
> On Sat, Jan 9, 2010 at 2:52 PM, Alan D. Cabrera
> <li...@toolazydogs.com> 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 many
> occasions, especially in combination with MDC.
>
> /niklas
Seems like a good point. What out of the box filter was there that
you could not fix it's poor logging?
Regards,
Alan
Re: [MINA 3.0] Which filters should we keep ?
Posted by Niklas Gustavsson <ni...@protocol7.com>.
On Sat, Jan 9, 2010 at 2:52 PM, Alan D. Cabrera <li...@toolazydogs.com> 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 many
occasions, especially in combination with MDC.
/niklas
Re: [MINA 3.0] Which filters should we keep ?
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
On Jan 9, 2010, at 5:44 AM, Niklas Gustavsson wrote:
> On Fri, Jan 8, 2010 at 4:27 PM, Ashish <pa...@gmail.com>
> 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 one has properly instrumented one's code w/ logging,
where would this filter be useful?
Regards,
Alan
Re: [MINA 3.0] Which filters should we keep ?
Posted by Niklas Gustavsson <ni...@protocol7.com>.
On Fri, Jan 8, 2010 at 4:27 PM, Ashish <pa...@gmail.com> 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
Re: [MINA 3.0] Standard Codec was Re: [MINA 3.0] Which filters should we keep ?
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
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 <elecharny@gmail.com
>> > 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 as some
>> kind
>> of subproject/part of subproject (like the HTTP filter being part of
>> AsyncWeb). As for the XML filter, we now got a reusable, non blocking
>> XML parser/renderer in Vysper (still in a branch, but soon ready for
>> getting into trunk). It still needs work, especially for support full
>> XML (currently lacks support for PIs, doctype declarations).
>>
> We discussed a while back about the idea to offer a set of standard
> codec for many protocols. I think it's a better idea to follow
> Niklas' suggestion, and to cover this point in a different thread.
>
> There is also a distinction we should make between protocol codecs
> (Http, Ntp, Ldap, ...) and message codecs (XML, Json, ...). The
> second kind of codec does not necessarily covers a protocol, it's
> just a support, a bit like the TextLineDecoder is not a protocol. I
> don't know if I'm clear enough, so I hope you were able to get the
> message I wanted to transmit without the need for me to put it in a
> XML formet :)
I never thought of HTTP as a filter but it's intriguing. I had always
thought that it was more application like.
Regards,
Alan
[MINA 3.0] Standard Codec was Re: [MINA 3.0] Which filters should
we keep ?
Posted by Emmanuel Lecharny <el...@gmail.com>.
Niklas Gustavsson a écrit :
> On Fri, Jan 8, 2010 at 5:25 PM, Emmanuel LŽcharny <el...@gmail.com> 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 as some kind
> of subproject/part of subproject (like the HTTP filter being part of
> AsyncWeb). As for the XML filter, we now got a reusable, non blocking
> XML parser/renderer in Vysper (still in a branch, but soon ready for
> getting into trunk). It still needs work, especially for support full
> XML (currently lacks support for PIs, doctype declarations).
>
We discussed a while back about the idea to offer a set of standard
codec for many protocols. I think it's a better idea to follow Niklas'
suggestion, and to cover this point in a different thread.
There is also a distinction we should make between protocol codecs
(Http, Ntp, Ldap, ...) and message codecs (XML, Json, ...). The second
kind of codec does not necessarily covers a protocol, it's just a
support, a bit like the TextLineDecoder is not a protocol. I don't know
if I'm clear enough, so I hope you were able to get the message I wanted
to transmit without the need for me to put it in a XML formet :)
--
Regards,
Cordialement,
Emmanuel Lécharny
www.nextury.com
Re: [MINA 3.0] Which filters should we keep ?
Posted by Niklas Gustavsson <ni...@protocol7.com>.
On Fri, Jan 8, 2010 at 5:25 PM, Emmanuel LŽcharny <el...@gmail.com> 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 as some kind
of subproject/part of subproject (like the HTTP filter being part of
AsyncWeb). As for the XML filter, we now got a reusable, non blocking
XML parser/renderer in Vysper (still in a branch, but soon ready for
getting into trunk). It still needs work, especially for support full
XML (currently lacks support for PIs, doctype declarations).
/niklas
Re: [MINA 3.0] Which filters should we keep ?
Posted by Emmanuel Lcharny <el...@gmail.com>.
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 écrit :
> On Fri, Jan 8, 2010 at 7:33 PM, Emmanuel Lecharny <el...@gmail.com> 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, the number of session, somehow). Does not seems to be usefull...
>> o SessionAttributeInitializingFilter : Used to inject some default
>> attributes in the session when it's created. Same : probably superfluous
>> o FileRegionWriteFilter : Converts FileRegion to IoBuffer. Not convinced
>> about the interest of such a filter ...
>> o StreamWriteFilter : I do think that it's not the Filter purpose to handle
>> the messages that are to be written. We should instead define an interface
>> for messages that allow the system to write them, whatever the container
>> used.
>> o ProfilerTimerFilter : Shouldn't it be a part of the core system, in
>> coordination with JMX ? When using a filter to do some timing, we lose a
>> part of the action, as we have some processing bing done before the filter
>> is called...
>> 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.
>> o RequestResponseFilter : Due to the total lack of doco ( cf "TODO Add
>> documentation"), it's difficult to say anything about this Filte. Maybe by
>> reading http://issues.apache.org/jira/browse/DIRMINA-92?
>> o BlacklistFilter : Supposely block IPs. Uses a List internally, most
>> certinly suboptimal. Probably useful to have.
>> o BufferedWriteFilter : Useful ? Not sure... probably better to disable
>> Naggle Algorithm and let the underlying network layer dealing with this. Not
>> sure...
>> o MdcInjectionFilter : Useful, definitively
>> o ConnectionThrottleFilter : Useful.
>> o ErrorGeneratingFilter : Was supposed to be designed for tests. Not sure
>> it's useful.
>> o ExecutorFilter : Mandatory.
>> o KeepAliveFilter : Never used it, but I think it can be useful.
>> o LoggingFilter : I'm really not convinced it's a good to have filter.
>> People can define such a Filter using their prefered logging system so
>> easily, I don't see the intrest to have such a filter in core...
>> o ProtocolCodecFilter : Must have, but needs a lot of refactoring.
>> o ProxyFilter : Let's keep it. I don't like its name, because I'm not sure
>> it's explaining exactly what his filter is doing, but I'm also probably not
>> smart enough :)
>> o CompressionFilter : Must have !
>> o WriteRequestFilter : I don't really understand the need fo such a
>> filter... But I have not analyzed it in detail. Waiting for insights
>>
>> That pretty much it for MINA 2. So far, I think we can restreint the list of
>> usful filters to :
>> - BlacklistFilter
>> - MdcInjectionFilter
>> - ConnectionThrottleFilter
>> - ExecutorFilter
>> - KeepAliveFilter
>> - ProtocolCodecFilter
>> - ProxyFilter
>> - CompressionFilter
>>
>> wdyt ?
>>
>
> Agree on the list. 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.
>
> I did some POC related to RequestResponse filter, but didn't made much
> of a progress. I think the functionality can be achieved in a simpler
> way. Will give another shot at trying to get the crux out of it.
>
> Lets keep the list simple, and we can add to it later :-)
>
>
>> --
>> Regards,
>> Cordialement,
>> Emmanuel Lécharny
>> www.nextury.com
>>
>>
>>
>>
>
>
>
>
Re: [MINA 3.0] Which filters should we keep ?
Posted by Ashish <pa...@gmail.com>.
On Fri, Jan 8, 2010 at 7:33 PM, Emmanuel Lecharny <el...@gmail.com> 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, the number of session, somehow). Does not seems to be usefull...
> o SessionAttributeInitializingFilter : Used to inject some default
> attributes in the session when it's created. Same : probably superfluous
> o FileRegionWriteFilter : Converts FileRegion to IoBuffer. Not convinced
> about the interest of such a filter ...
> o StreamWriteFilter : I do think that it's not the Filter purpose to handle
> the messages that are to be written. We should instead define an interface
> for messages that allow the system to write them, whatever the container
> used.
> o ProfilerTimerFilter : Shouldn't it be a part of the core system, in
> coordination with JMX ? When using a filter to do some timing, we lose a
> part of the action, as we have some processing bing done before the filter
> is called...
> 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.
> o RequestResponseFilter : Due to the total lack of doco ( cf "TODO Add
> documentation"), it's difficult to say anything about this Filte. Maybe by
> reading http://issues.apache.org/jira/browse/DIRMINA-92?
> o BlacklistFilter : Supposely block IPs. Uses a List internally, most
> certinly suboptimal. Probably useful to have.
> o BufferedWriteFilter : Useful ? Not sure... probably better to disable
> Naggle Algorithm and let the underlying network layer dealing with this. Not
> sure...
> o MdcInjectionFilter : Useful, definitively
> o ConnectionThrottleFilter : Useful.
> o ErrorGeneratingFilter : Was supposed to be designed for tests. Not sure
> it's useful.
> o ExecutorFilter : Mandatory.
> o KeepAliveFilter : Never used it, but I think it can be useful.
> o LoggingFilter : I'm really not convinced it's a good to have filter.
> People can define such a Filter using their prefered logging system so
> easily, I don't see the intrest to have such a filter in core...
> o ProtocolCodecFilter : Must have, but needs a lot of refactoring.
> o ProxyFilter : Let's keep it. I don't like its name, because I'm not sure
> it's explaining exactly what his filter is doing, but I'm also probably not
> smart enough :)
> o CompressionFilter : Must have !
> o WriteRequestFilter : I don't really understand the need fo such a
> filter... But I have not analyzed it in detail. Waiting for insights
>
> That pretty much it for MINA 2. So far, I think we can restreint the list of
> usful filters to :
> - BlacklistFilter
> - MdcInjectionFilter
> - ConnectionThrottleFilter
> - ExecutorFilter
> - KeepAliveFilter
> - ProtocolCodecFilter
> - ProxyFilter
> - CompressionFilter
>
> wdyt ?
Agree on the list. 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.
I did some POC related to RequestResponse filter, but didn't made much
of a progress. I think the functionality can be achieved in a simpler
way. Will give another shot at trying to get the crux out of it.
Lets keep the list simple, and we can add to it later :-)
>
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.nextury.com
>
>
>
--
thanks
ashish
Blog: http://www.ashishpaliwal.com/blog
My Photo Galleries: http://www.pbase.com/ashishpaliwal