Re: Got some error when compiling SSHd

2009-05-12 Thread Bernd Fondermann
On Tue, May 12, 2009 at 05:16, Emmanuel Lecharny  wrote:
> Guillaume Nodet wrote:
>>
>> It works for me too.  Please post some details.
>>
>> On Thu, May 7, 2009 at 12:20, Bernd Fondermann 
>> wrote:
>>
>>>
>>> Emmanuel Lecharny wrote:
>>>

 Hi guys,

 just before leaving for a long week-end, I tried to build all the MINA
 code. I get some error when compiling sshd.

 Can someone check ?

 Thanks !

>>>
>>> mvn install works fine for me.
>>>
>
> Works now on linux... Strange :/

No, not at all. Linux has no file lock as Windows has, so the problem
should not appear there.

  Bernd


[jira] Commented: (DIRMINA-687) 2.0.0-M5 REGRESSION: sessionClosed called before doDecode completes

2009-05-12 Thread Emmanuel Lecharny (JIRA)

[ 
https://issues.apache.org/jira/browse/DIRMINA-687?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12708383#action_12708383
 ] 

Emmanuel Lecharny commented on DIRMINA-687:
---

Got it !

The previous trace is just confusing. The MinaThread is not sleeping _and_ 
executing some other task at the same time. It's just that the executor is 
processing incoming events using a pool of threads (called 'workers'), but 
rename those workers using the main thread name (ie, 'MinaThread'). This is 
very bad ...

However, this does not solve the problem : why do we have a session event being 
processed while another event is already beoing processed ? This is not what we 
expect for an OrderThreadPoolExecutor...

Here is the trace :

[0]-main INFO [testcase.MinaRegressionTest] - START
...
[145]-NioProcessor-3 INFO [testcase.MyIoHandler] - Creation of session 5
[145]-NioProcessor-3 INFO 
[org.apache.mina.filter.executor.OrderedThreadPoolExecutor] - Adding event 
SESSION_OPENED to session 5
Queue : [SESSION_OPENED, ]
...
[148]-MinaThread DEBUG 
[org.apache.mina.filter.executor.OrderedThreadPoolExecutor] - 
[worker-1]Processing task SESSION_OPENEDfor session 5
[148]-MinaThread DEBUG [org.apache.mina.core.filterchain.IoFilterEvent] - 
Firing a SESSION_OPENED event for session 5
[148]-MinaThread INFO [testcase.MyIoHandler] - Session 5 is opened
[148]-MinaThread DEBUG [org.apache.mina.core.filterchain.IoFilterEvent] - Event 
SESSION_OPENED has been fired for session 5
...
[153]-NioProcessor-3 INFO 
[org.apache.mina.filter.executor.OrderedThreadPoolExecutor] - Adding event 
MESSAGE_RECEIVED to session 5
Queue : [MESSAGE_RECEIVED, ]
[153]-MinaThread DEBUG 
[org.apache.mina.filter.executor.OrderedThreadPoolExecutor] - 
[worker-1]Processing task MESSAGE_RECEIVEDfor session 5
[153]-MinaThread DEBUG [org.apache.mina.core.filterchain.IoFilterEvent] - 
Firing a MESSAGE_RECEIVED event for session 5
[153]-MinaThread INFO [org.apache.mina.filter.codec.ProtocolCodecFilter] - 
Processing a MESSAGE_RECEIVED for session 5
[153]-MinaThread DEBUG [testcase.MyRequestDecoder] - Sleep for 1000 ms for 
session 5
[153]-Thread-1 DEBUG [testcase.MyRequestDecoder] - Sleep for 500 ms for session 
5
...
[158]-NioProcessor-3 INFO 
[org.apache.mina.filter.executor.OrderedThreadPoolExecutor] - Adding event 
MESSAGE_RECEIVED to session 5
Queue : [MESSAGE_RECEIVED, ]
...
[161]-MinaThread DEBUG 
[org.apache.mina.filter.executor.OrderedThreadPoolExecutor] - 
[worker-6]Processing task MESSAGE_RECEIVEDfor session 5
[161]-MinaThread DEBUG [org.apache.mina.core.filterchain.IoFilterEvent] - 
Firing a MESSAGE_RECEIVED event for session 5
[161]-MinaThread INFO [org.apache.mina.filter.codec.ProtocolCodecFilter] - 
Processing a MESSAGE_RECEIVED for session 5
...
[654]-Thread-1 DEBUG [testcase.MyRequestDecoder] - Wake up now from a 500 ms 
sleep for session 5
[656]-NioProcessor-3 INFO 
[org.apache.mina.filter.executor.OrderedThreadPoolExecutor] - Adding event 
SESSION_CLOSED to session 5
Queue : [SESSION_CLOSED, ]
...
[663]-MinaThread DEBUG 
[org.apache.mina.filter.executor.OrderedThreadPoolExecutor] - 
[worker-9]Processing task SESSION_CLOSEDfor session 5
...
[665]-MinaThread DEBUG [org.apache.mina.core.filterchain.IoFilterEvent] - 
Firing a SESSION_CLOSED event for session 5
[665]-MinaThread INFO [testcase.MyIoHandler] - 5> Session closed
[665]-MinaThread DEBUG [org.apache.mina.core.filterchain.IoFilterEvent] - Event 
SESSION_CLOSED has been fired for session 5
...
[1153]-MinaThread DEBUG [testcase.MyRequestDecoder] - Wake up now from a 1000 
ms sleep for session 5
[1154]-MinaThread ERROR [testcase.MyRequestDecoder] - !session 5 closed before 
decoding completes!
[1154]-MinaThread DEBUG [org.apache.mina.core.filterchain.IoFilterEvent] - 
Event MESSAGE_RECEIVED has been fired for session 5
[1154]-MinaThread ERROR [testcase.MyRequestDecoder] - !decoding for closed 
session 5
[1155]-MinaThread DEBUG [testcase.MyRequestDecoder] - Sleep for 1000 ms for 
session 5
[1155]-Thread-11 DEBUG [testcase.MyRequestDecoder] - Sleep for 500 ms for 
session 5
...
[1655]-Thread-11 DEBUG [testcase.MyRequestDecoder] - Wake up now from a 500 ms 
sleep for session 5
...
[2155]-MinaThread DEBUG [testcase.MyRequestDecoder] - Wake up now from a 1000 
ms sleep for session 5
[2155]-MinaThread ERROR [testcase.MyRequestDecoder] - !session 5 closed before 
decoding completes!
[2156]-MinaThread INFO [testcase.MyRequestDecoder] - Done decoding for session 5
[2156]-MinaThread DEBUG [org.apache.mina.core.filterchain.IoFilterEvent] - 
Event MESSAGE_RECEIVED has been fired for session 5
...
[2686]-main INFO [testcase.MinaRegressionTest] - Received: 0
[2686]-main INFO [testcase.MinaRegressionTest] - Sent: 10
[2686]-main INFO [testcase.MinaRegressionTest] - FINISH


> 2.0.0-M5 REGRESSION: sessionClosed called before doDecode completes
> ---
>
>

Re: Header stuff

2009-05-12 Thread Emmanuel Lecharny

Niklas Gustavsson wrote:

On Tue, May 12, 2009 at 10:57 AM, Emmanuel Lecharny
 wrote:
  

Np. FYI, I did it by hand (not using a script with sed) because it allowed
me to have a look at each header, and allowed me to see that some Javadoc
was needed, and such other omisions. Not sure it worth the pain in your
case.



It's probably what I'll do as well .-)
  
It's not _that_ painfull... Around one hour. There are 300 @version tags 
in ftpserver, so it's a @revision removal every 12 seconds ;)

/niklas

  



--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org




Re: Header stuff

2009-05-12 Thread Niklas Gustavsson
On Tue, May 12, 2009 at 10:57 AM, Emmanuel Lecharny
 wrote:
> Np. FYI, I did it by hand (not using a script with sed) because it allowed
> me to have a look at each header, and allowed me to see that some Javadoc
> was needed, and such other omisions. Not sure it worth the pain in your
> case.

It's probably what I'll do as well .-)

/niklas


Re: Header stuff

2009-05-12 Thread Emmanuel Lecharny

Niklas Gustavsson wrote:

On Tue, May 12, 2009 at 5:23 AM, Emmanuel Lecharny  wrote:
  

Still have to remove those from FtpServer.



I'll take care of them if you like.
  
Np. FYI, I did it by hand (not using a script with sed) because it 
allowed me to have a look at each header, and allowed me to see that 
some Javadoc was needed, and such other omisions. Not sure it worth the 
pain in your case.

/niklas

  



--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org




Re: Header stuff

2009-05-12 Thread Niklas Gustavsson
On Tue, May 12, 2009 at 5:23 AM, Emmanuel Lecharny  wrote:
> Still have to remove those from FtpServer.

I'll take care of them if you like.

/niklas


Re: Header stuff

2009-05-12 Thread Emmanuel Lecharny

Hi,


Bernd Fondermann wrote:



I'd propose something like this:

@author http://mina.apache.org";>Apache MINA Project

At the homepage is everything one could possibly need (source,
documentation, and contact information). I don't know if it's better
to point to the subproject or not, though.



Maybe there have already been extensive discussions about this in the
past, but we should give that a second thought. The website will stay,
while mailing lists for projects (sometimes) change, as projects grow
and MLs are forked.

Essentially, I am fine with both approaches.
  


@author tags may be removed, but I find it convenient to have a tag 
pointing to the original project (be it the ML or the web page). As 
project might move - for instance, MINA was a part of Directory before 
being a TLP, Vysper was a part of labs before being a MINA sub-project, 
and may be one day a TLP...-


We just have, as a project, to decide what to do. I like the proposal to 
use the http link to the project web site, instead of the dev mailing list.


--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org




Re: Header stuff

2009-05-12 Thread Bernd Fondermann
Michael Jakl wrote:
> Hi!
> 
> On Tue, May 12, 2009 at 08:54, Bernd Fondermann  wrote:
>> Emmanuel Lecharny wrote:
>>> Note : We also have to use the same @author tags everywhere.
>>> SSHd uses :
>>> @author mailto:dev@mina.apache.org";>Apache MINA SSHD Project
>>>
>>> FtpServer uses :
>>> @author The Apache MINA Project (dev@mina.apache.org)
>>>
>>> MINA uses :
>>> @author The Apache MINA Project (dev@mina.apache.org)
>>>
>>> AsyncWeb still have personal author's tags like :
>>> @author mailto:adr...@ephox.com";>Adrian Sutton
>>>
>>> In this case, we have to do three things :
>>> 1) check that those authors are Apache committers
>>> 2) check that the code was either committed as a part of the project or
>>> as a part of an ASL 2.0 compliant project
>>> 3) if they are external (ie, ASL 2.0 compliant license project), then we
>>> have to check that the notice.txt contains the correct attribution
>> For 2) and 3), where the origin of the code is not at the ASF covered by
>> and *CLA, my understanding is that there should be either an IP grant on
>> file or a corresponding JIRA with a checked ASF-license box.
>>
>> Nevertheless, the author tags could be removed altogether, because they
>> are not a copyright (the original author retains copyright anyway, it is
>> irrevokable AFAIK) or a licensing statement.
> 
> I was to support your suggestion, but after a second thought the
> author tag might have a benefit. Since everybody has the right to copy
> and use the code, it could be all over the internet, with the author
> tag it's clear where the code comes from (even if Google points to
> some class deep down the hierachy).

Actually, it already _is_ all over the internet (at least for the MINA
case :-). I intended to refer to _individual_ author tags, not the ML
author tag, which I think is should stay.

> On the other hand, removing redundancies (since it's the same
> information everywhere) is also a good thing.
> 
>>> In any case, we should use the same tag formet (SSHd format ios probably
>>> more convenient, if we consider Javadoc).
>> +1
> 
> dev@mina.apache.org is a mailinglist, so it *might* not be the best
> address to add without further notice (how to subscribe to it for
> example). It isn't possible to send a mail to dev@mina.apache.org
> without subscribing, is it?

It is possible, but the posting won't go through directly, it is subject
to moderation. That's how most m...@asf work.

> I'd propose something like this:
> 
> @author http://mina.apache.org";>Apache MINA Project
> 
> At the homepage is everything one could possibly need (source,
> documentation, and contact information). I don't know if it's better
> to point to the subproject or not, though.

Maybe there have already been extensive discussions about this in the
past, but we should give that a second thought. The website will stay,
while mailing lists for projects (sometimes) change, as projects grow
and MLs are forked.

Essentially, I am fine with both approaches.

  Bernd


[jira] Created: (FTPSERVER-297) Data connection not closed on filter chain exception

2009-05-12 Thread Niklas Gustavsson (JIRA)
Data connection not closed on filter chain exception


 Key: FTPSERVER-297
 URL: https://issues.apache.org/jira/browse/FTPSERVER-297
 Project: FtpServer
  Issue Type: Bug
  Components: Core
Affects Versions: 1.0.0
Reporter: Niklas Gustavsson
Assignee: Niklas Gustavsson
 Fix For: 1.0.1, 1.1


When an exception happens in the filter chain (e.g a decoding problem), the 
session is closed but any open data connection is not closed. We should ensure 
that the data connectioon is closed whenever the session is closed.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



Re: Header stuff

2009-05-12 Thread Michael Jakl
Hi!

On Tue, May 12, 2009 at 08:54, Bernd Fondermann  wrote:
> Emmanuel Lecharny wrote:
>> Note : We also have to use the same @author tags everywhere.
>> SSHd uses :
>> @author mailto:dev@mina.apache.org";>Apache MINA SSHD Project
>>
>> FtpServer uses :
>> @author The Apache MINA Project (dev@mina.apache.org)
>>
>> MINA uses :
>> @author The Apache MINA Project (dev@mina.apache.org)
>>
>> AsyncWeb still have personal author's tags like :
>> @author mailto:adr...@ephox.com";>Adrian Sutton
>>
>> In this case, we have to do three things :
>> 1) check that those authors are Apache committers
>> 2) check that the code was either committed as a part of the project or
>> as a part of an ASL 2.0 compliant project
>> 3) if they are external (ie, ASL 2.0 compliant license project), then we
>> have to check that the notice.txt contains the correct attribution
>
> For 2) and 3), where the origin of the code is not at the ASF covered by
> and *CLA, my understanding is that there should be either an IP grant on
> file or a corresponding JIRA with a checked ASF-license box.
>
> Nevertheless, the author tags could be removed altogether, because they
> are not a copyright (the original author retains copyright anyway, it is
> irrevokable AFAIK) or a licensing statement.

I was to support your suggestion, but after a second thought the
author tag might have a benefit. Since everybody has the right to copy
and use the code, it could be all over the internet, with the author
tag it's clear where the code comes from (even if Google points to
some class deep down the hierachy).

On the other hand, removing redundancies (since it's the same
information everywhere) is also a good thing.

>> In any case, we should use the same tag formet (SSHd format ios probably
>> more convenient, if we consider Javadoc).
>
> +1

dev@mina.apache.org is a mailinglist, so it *might* not be the best
address to add without further notice (how to subscribe to it for
example). It isn't possible to send a mail to dev@mina.apache.org
without subscribing, is it?

I'd propose something like this:

@author http://mina.apache.org";>Apache MINA Project

At the homepage is everything one could possibly need (source,
documentation, and contact information). I don't know if it's better
to point to the subproject or not, though.

Cheers,
Michael