[
https://issues.apache.org/jira/browse/PROTOCOLS-76?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13175810#comment-13175810
]
Norman Maurer commented on PROTOCOLS-76:
I know this section but I don't agree ;
[
https://issues.apache.org/jira/browse/PROTOCOLS-76?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13175784#comment-13175784
]
Ceki Gulcu commented on PROTOCOLS-76:
-
You might reconsider your decision after read
Author: norman
Date: Sat Dec 24 22:37:17 2011
New Revision: 1223033
URL: http://svn.apache.org/viewvc?rev=1223033&view=rev
Log:
Remove dependency on slf4j. See PROTOCOLS-76
Added:
james/protocols/trunk/api/src/main/java/org/apache/james/protocols/api/Logger.java
(with props)
james/pr
[
https://issues.apache.org/jira/browse/PROTOCOLS-76?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Norman Maurer resolved PROTOCOLS-76.
Resolution: Fixed
done
> Remove dependency on slf4j
> --
Modified:
james/protocols/trunk/smtp/src/main/java/org/apache/james/protocols/smtp/core/esmtp/StartTlsCmdHandler.java
URL:
http://svn.apache.org/viewvc/james/protocols/trunk/smtp/src/main/java/org/apache/james/protocols/smtp/core/esmtp/StartTlsCmdHandler.java?rev=1223019&r1=1223018&r2=1223019&vie
[
https://issues.apache.org/jira/browse/PROTOCOLS-74?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Norman Maurer resolved PROTOCOLS-74.
Resolution: Fixed
done
> Minimize Response creation
> --
Hi there,
The VOTE passed...
+1 Felix, Stefano, Manuel, Norman,Steve
+0 Ioan, Eric
Thanks for Voting. I will publish the artifacts to Maven Central and the
mirrors.
@eric:
I will let you know once we can update the Website...
Bye
Norman
Am Mittwoch, 21. Dezember 2011 schrieb Norman Maurer :
Hi there,
And again See inside,,
Am Samstag, 24. Dezember 2011 schrieb Eric Charles :
> Hi Norman,
> Thx for inputs. comment/confirmation inside.
> Eric
>
> On 24/12/11 11:53, Norman Maurer wrote:
>>
>> Hi Eric,
>>
>> comments inside
>>
>> Am 24.12.2011 um 10:05 schrieb Eric Charles:
>>
>>> H
Hi Eric,
Its Stefano not Stephano ;)
Comments inside...
Am Samstag, 24. Dezember 2011 schrieb Eric Charles :
> Hi Stephano, Thx for the inputs. I'm fine to have volatile fields and to
use them is synchronized blocks when needed, and out-of synchronized blocks
when possible.
>
> I still have to f
2011/12/24 Eric Charles :
> Maybe you can give me a hint about about the 2 user threads?
The main thread is the one that write new "reponses". It is the
protocol thread and calls the writeResponse method each time a new
reponse is available.
If the response is a FutureResponse then the whole thing
Hi Stephano, Thx for the inputs. I'm fine to have volatile fields and to
use them is synchronized blocks when needed, and out-of synchronized
blocks when possible.
I still have to find the few hours to better understand the usage and
context.
Maybe you can give me a hint about about the 2 us
Hi Norman,
Thx for inputs. comment/confirmation inside.
Eric
On 24/12/11 11:53, Norman Maurer wrote:
Hi Eric,
comments inside
Am 24.12.2011 um 10:05 schrieb Eric Charles:
Hi Stephano,
Opening the discussion to learn more :)
- Why are you considering that 2 threads is a criteria to use
Ok, I see why there's RC1 in the last vote.
Should we wait on 1.6.0 final before announcing on website...?
Thx,
Eric
On 24/12/11 11:23, Norman Maurer wrote:
Because I wamt to push 1.6.0 as soon as possible. When I now start to work on
imap in trunk we have some half done work again which will
Remove dependency on slf4j
--
Key: PROTOCOLS-76
URL: https://issues.apache.org/jira/browse/PROTOCOLS-76
Project: JAMES Protocols
Issue Type: Task
Components: api
Affects Versions: 1.6.0-RC1
R
2011/12/24 Eric Charles :
> Hi Stephano,
>
> Opening the discussion to learn more :)
>
> - Why are you considering that 2 threads is a criteria to use standard
> synchronization rather than some atomic fields.
It is a criteria to not use the ConcurrentLinkedQueue that is a
structure thought to han
Move ProtocolSession.newFatalErrorResponse() and
ProtocolSession.newLineToLongResponse() to an extra interface
--
Key: PROTOCOLS-75
URL: https://issues.apa
Hi Eric,
comments inside
Am 24.12.2011 um 10:05 schrieb Eric Charles :
> Hi Stephano,
>
> Opening the discussion to learn more :)
>
> - Why are you considering that 2 threads is a criteria to use standard
> synchronization rather than some atomic fields.
>
If you only have a small count
Minimize Response creation
--
Key: PROTOCOLS-74
URL: https://issues.apache.org/jira/browse/PROTOCOLS-74
Project: JAMES Protocols
Issue Type: Improvement
Components: api, lmtp, pop3, sieve
Affects Version
[
https://issues.apache.org/jira/browse/PROTOCOLS-73?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Norman Maurer updated PROTOCOLS-73:
---
Affects Version/s: 1.6.0-RC1
Fix Version/s: 2.0.0
> Move imap code into protoco
Because I wamt to push 1.6.0 as soon as possible. When I now start to work on
imap in trunk we have some half done work again which will just block the
release...
bye,
norman
Von meinem iPad gesendet
Am 24.12.2011 um 09:55 schrieb Eric Charles :
> +1, IMAP's home is Protocols.
>
> Why not di
[x] +0 No time to review :/
I will update the news (home page) + protocols web site when released.
Thx,
Eric
On 21/12/11 21:01, Norman Maurer wrote:
Hi there,
over the last few weeks I worked on improving the Apache James Protocols code.
I think after fixing the last outstanding bug today (
Hi Stephano,
Opening the discussion to learn more :)
- Why are you considering that 2 threads is a criteria to use standard
synchronization rather than some atomic fields.
- I can understand you replace a concurrent by a non-concurrent queue.
However, you now have a blocking queue. Is there
+1, IMAP's home is Protocols.
Why not directly move IMAP in Protocols' trunk and let it evolve at its
own pace? Close integration can take time, but at least it will be at
its place.
Eric
On 23/12/11 09:14, Stefano Bagnara wrote:
2011/12/23 Norman Maurer:
Hi there,
as I have some spare ti
23 matches
Mail list logo
