[jira] [Commented] (JAMES-3140) Provide a CachedDumbBlobStore

[Matthieu Baechler (Jira)]

[ 
https://issues.apache.org/jira/browse/JAMES-3140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17077068#comment-17077068
 ] 

Matthieu Baechler commented on JAMES-3140:
--

The real question is "does it happen 1% of the time or 90%"? Because we can 
very well have typical sequence of events that trigger this bad behavior.

> Provide a CachedDumbBlobStore
> -
>
> Key: JAMES-3140
> URL: https://issues.apache.org/jira/browse/JAMES-3140
> Project: James Server
>  Issue Type: Improvement
>Reporter: René Cordier
>Priority: Major
>
> {{This DumbBlobStore wraps another dumbBlobStore and compose it with a 
> Cache.}}
> Blobs are cached upon writes
> Only blobs of the default bucket are cached.
> Upon reads:
>  * the cache is queried
>  * if the cache is empty then load it's value from the blobStore
>  * and populate the cache
> Provide guice bindings in james-distributed guice product:
>  * configure CassandraBlobStoreCache
>  * enable caching if {{blobStore.cache.enabled=true}}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

[jira] [Commented] (JAMES-2208) upgrade netty to netty-all

[Matthieu Baechler (Jira)]

[ 
https://issues.apache.org/jira/browse/JAMES-2208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17079142#comment-17079142
 ] 

Matthieu Baechler commented on JAMES-2208:
--

I read the report and the 4 vulnerabilities are related to HTTP.
We don't use netty 3 for HTTP so we are safe.

Still, if you want to contribute the upgrade to Netty 4, we can offer some help.

> upgrade netty to netty-all
> --
>
> Key: JAMES-2208
> URL: https://issues.apache.org/jira/browse/JAMES-2208
> Project: James Server
>  Issue Type: Improvement
>  Components: James Core
>Affects Versions: 3.0.0
>Reporter: Randymo
>Priority: Major
> Attachments: dependency-check-report.html
>
>
> James is currently using the netty dependency 
> 
> io.netty
> netty
> 3.10.6.Final
> 
> I think we should upgrade to the newer artifact
> 
> io.netty
> netty-all
> 4.1.16.Final
> 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

[jira] [Created] (JAMES-3145) Make it poosible to log metrics

[Matthieu Baechler (Jira)]

Matthieu Baechler created JAMES-3145:


 Summary: Make it poosible to log metrics
 Key: JAMES-3145
 URL: https://issues.apache.org/jira/browse/JAMES-3145
 Project: James Server
  Issue Type: Improvement
  Components: Metrics
Reporter: Matthieu Baechler


James is currently able to publish metrics in an elasticsearch database.
Once configured correctly, it allows to have nice dashboard giving insights 
about a lot of processes happening in the server.

However, output to elasticsearch is not always what users want.

We should be able to publish these metrics to various systems.

This issue is about adding the capability to publish metrics to the log 
framework and that we can enable with some logger configuration.





--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

[jira] [Created] (JAMES-3153) Upgrade reactor to make use of retryWhen and RetrySpec

[Matthieu Baechler (Jira)]

Matthieu Baechler created JAMES-3153:


 Summary: Upgrade reactor to make use of retryWhen and RetrySpec
 Key: JAMES-3153
 URL: https://issues.apache.org/jira/browse/JAMES-3153
 Project: James Server
  Issue Type: Improvement
Reporter: Matthieu Baechler


Latest reactor version include some new features regarding retry backoff (see 
https://github.com/reactor/reactor-core/pull/1979 )

As we were limited by the previous API, we did copy some code from reactor to 
workaround the limitations.

Now that they implement a RetrySpec, we should be able to get rid of this code 
duplication and rely on their well-tested feature.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

[jira] [Closed] (JAMES-3145) Make it poosible to log metrics

[Matthieu Baechler (Jira)]

 [ 
https://issues.apache.org/jira/browse/JAMES-3145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Matthieu Baechler closed JAMES-3145.

Fix Version/s: 3.6.0
   Resolution: Fixed

Merged 

> Make it poosible to log metrics
> ---
>
> Key: JAMES-3145
> URL: https://issues.apache.org/jira/browse/JAMES-3145
> Project: James Server
>  Issue Type: Improvement
>  Components: Metrics
>Reporter: Matthieu Baechler
>Priority: Major
> Fix For: 3.6.0
>
>
> James is currently able to publish metrics in an elasticsearch database.
> Once configured correctly, it allows to have nice dashboard giving insights 
> about a lot of processes happening in the server.
> However, output to elasticsearch is not always what users want.
> We should be able to publish these metrics to various systems.
> This issue is about adding the capability to publish metrics to the log 
> framework and that we can enable with some logger configuration.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

[jira] [Updated] (JAMES-3153) Upgrade reactor to make use of retryWhen and RetrySpec

[Matthieu Baechler (Jira)]

 [ 
https://issues.apache.org/jira/browse/JAMES-3153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Matthieu Baechler updated JAMES-3153:
-
Description: 
Latest reactor version include some new features regarding retry backoff (see 
https://github.com/reactor/reactor-core/pull/1979 )

As we were limited by the previous API, we did copy some code from reactor to 
workaround the limitations.

Now that they implement a RetrySpec, we should be able to get rid of this code 
duplication and rely on their well-tested feature.

h2. Definition of done:

* All reactive code should still work as before
* The code should use RetryWhen with RetrySpec instead of previous solutions


  was:
Latest reactor version include some new features regarding retry backoff (see 
https://github.com/reactor/reactor-core/pull/1979 )

As we were limited by the previous API, we did copy some code from reactor to 
workaround the limitations.

Now that they implement a RetrySpec, we should be able to get rid of this code 
duplication and rely on their well-tested feature.


> Upgrade reactor to make use of retryWhen and RetrySpec
> --
>
> Key: JAMES-3153
> URL: https://issues.apache.org/jira/browse/JAMES-3153
> Project: James Server
>  Issue Type: Improvement
>Reporter: Matthieu Baechler
>Priority: Major
>
> Latest reactor version include some new features regarding retry backoff (see 
> https://github.com/reactor/reactor-core/pull/1979 )
> As we were limited by the previous API, we did copy some code from reactor to 
> workaround the limitations.
> Now that they implement a RetrySpec, we should be able to get rid of this 
> code duplication and rely on their well-tested feature.
> h2. Definition of done:
> * All reactive code should still work as before
> * The code should use RetryWhen with RetrySpec instead of previous solutions



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

[jira] [Closed] (JAMES-3153) Upgrade reactor to make use of retryWhen and RetrySpec

[Matthieu Baechler (Jira)]

 [ 
https://issues.apache.org/jira/browse/JAMES-3153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Matthieu Baechler closed JAMES-3153.

Fix Version/s: 3.6.0
   Resolution: Fixed

> Upgrade reactor to make use of retryWhen and RetrySpec
> --
>
> Key: JAMES-3153
> URL: https://issues.apache.org/jira/browse/JAMES-3153
> Project: James Server
>  Issue Type: Improvement
>Reporter: Matthieu Baechler
>Priority: Major
> Fix For: 3.6.0
>
>
> Latest reactor version include some new features regarding retry backoff (see 
> https://github.com/reactor/reactor-core/pull/1979 )
> As we were limited by the previous API, we did copy some code from reactor to 
> workaround the limitations.
> Now that they implement a RetrySpec, we should be able to get rid of this 
> code duplication and rely on their well-tested feature.
> h2. Definition of done:
> * All reactive code should still work as before
> * The code should use RetryWhen with RetrySpec instead of previous solutions



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

[jira] [Commented] (JAMES-3140) Provide a CachedDumbBlobStore

[Matthieu Baechler (Jira)]

[ 
https://issues.apache.org/jira/browse/JAMES-3140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17096280#comment-17096280
 ] 

Matthieu Baechler commented on JAMES-3140:
--

https://github.com/linagora/james-project/pull/3320 contributes to this

> Provide a CachedDumbBlobStore
> -
>
> Key: JAMES-3140
> URL: https://issues.apache.org/jira/browse/JAMES-3140
> Project: James Server
>  Issue Type: Improvement
>Reporter: René Cordier
>Priority: Major
>
> {{This DumbBlobStore wraps another dumbBlobStore and compose it with a 
> Cache.}}
> Blobs are cached upon writes
> Only blobs of the default bucket are cached.
> Upon reads:
>  * the cache is queried
>  * if the cache is empty then load it's value from the blobStore
>  * and populate the cache
> Provide guice bindings in james-distributed guice product:
>  * configure CassandraBlobStoreCache
>  * enable caching if {{blobStore.cache.enabled=true}}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

[jira] [Created] (JAMES-3183) Implement a matcher to match X-Originating-IP

[Matthieu Baechler (Jira)]

Matthieu Baechler created JAMES-3183:


 Summary: Implement a matcher to match X-Originating-IP
 Key: JAMES-3183
 URL: https://issues.apache.org/jira/browse/JAMES-3183
 Project: James Server
  Issue Type: Improvement
  Components: Matchers/Mailets (bundled)
Reporter: Matthieu Baechler


We could provide a matcher to do some matching on X-Originating-IP header in 
the same way as RemoteAddrInNetwork.

It allows to do the same kind of check in cases there's a reverse-proxy in 
front of James.

It is best used in combination with RemoteAddrInNetwork to check that both 
X-Originating-IP and remoteAddr are in known networks. This will prevent 
relaying messages with forged X-Originating-IP.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

[jira] [Closed] (JAMES-3183) Implement a matcher to match X-Originating-IP

[Matthieu Baechler (Jira)]

 [ 
https://issues.apache.org/jira/browse/JAMES-3183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Matthieu Baechler closed JAMES-3183.

Resolution: Fixed

merged  https://github.com/linagora/james-project/pull/3365

> Implement a matcher to match X-Originating-IP
> -
>
> Key: JAMES-3183
> URL: https://issues.apache.org/jira/browse/JAMES-3183
> Project: James Server
>  Issue Type: Improvement
>  Components: Matchers/Mailets (bundled)
>Reporter: Matthieu Baechler
>Priority: Major
>
> We could provide a matcher to do some matching on X-Originating-IP header in 
> the same way as RemoteAddrInNetwork.
> It allows to do the same kind of check in cases there's a reverse-proxy in 
> front of James.
> It is best used in combination with RemoteAddrInNetwork to check that both 
> X-Originating-IP and remoteAddr are in known networks. This will prevent 
> relaying messages with forged X-Originating-IP.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

[jira] [Reopened] (JAMES-3176) MDN parser instantiation via parboiled fails

[Matthieu Baechler (Jira)]

 [ 
https://issues.apache.org/jira/browse/JAMES-3176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Matthieu Baechler reopened JAMES-3176:
--

We didn't resolved the problem yet

> MDN parser instantiation via parboiled fails
> 
>
> Key: JAMES-3176
> URL: https://issues.apache.org/jira/browse/JAMES-3176
> Project: James Server
>  Issue Type: Improvement
>  Components: Mailet Contributions, mdn
>Affects Versions: 3.5.0
>Reporter: Benoit Tellier
>Priority: Major
>  Labels: bug
> Fix For: 3.6.0
>
>
> Upon execution of ExtractMDNOriginalJMAPMessageId & Vacation mailet we 
> encounter the following exceptions:
> {code:java}
> java.lang.RuntimeException: Error creating extended parser class: null
>   at org.parboiled.Parboiled.createParser(Parboiled.java:58)
>   at org.apache.james.mdn.MDNReportParser.parse(MDNReportParser.java:57)
>   at org.apache.james.mdn.MDNReportParser.parse(MDNReportParser.java:53)
>   at 
> org.apache.james.jmap.mailet.ExtractMDNOriginalJMAPMessageId.parseReport(ExtractMDNOriginalJMAPMessageId.java:120)
> [...]
> Caused by: java.lang.IllegalArgumentException: null
>   at org.objectweb.asm.ClassVisitor.(Unknown Source)
>   at org.objectweb.asm.ClassVisitor.(Unknown Source)
>   at org.objectweb.asm.tree.ClassNode.(Unknown Source)
>   at 
> org.parboiled.transform.ParserClassNode.(ParserClassNode.java:43)
>   at 
> org.parboiled.transform.ParserTransformer.extendParserClass(ParserTransformer.java:43)
>   at 
> org.parboiled.transform.ParserTransformer.transformParser(ParserTransformer.java:39)
>   at org.parboiled.Parboiled.createParser(Parboiled.java:54)
> {code}
> Code inspection did not allow me to identify the route cause of the failure 
> due to some heavy reflection dark magic taking place.
> However instantiation of the parser was performed via reflection upon each MDN
> parsing.
> Given that a parser only defines a set of rules, and is thus immutable, 
> we can turn it into a constant, effectively solving our problem ?



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

[jira] [Commented] (JAMES-3191) Key registration is slow

[Matthieu Baechler (Jira)]

[ 
https://issues.apache.org/jira/browse/JAMES-3191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17111845#comment-17111845
 ] 

Matthieu Baechler commented on JAMES-3191:
--

Did you run a profiler or use glowroot APM to have some insights on where the 
time is spent exactly ?

I have serious doubt that raising channel number from 3 to 10 will change 
latency from several minutes to some milliseconds

> Key registration is slow
> 
>
> Key: JAMES-3191
> URL: https://issues.apache.org/jira/browse/JAMES-3191
> Project: James Server
>  Issue Type: Improvement
>  Components: eventbus, IMAPServer
>Affects Versions: master
>Reporter: Benoit Tellier
>Priority: Major
>  Labels: perf
>
> We noticed that on *master* SELECT IMAP command is significatively slow 
> (several minutes) on top of the distributed profile. (See attached 
> instrumentation average time and percentiles)
> A quick performance review links this to listener registration (by key).
> A code review leads to:
>  - The low channel number (3) maybe this count can be safely raised to a 
> higher number? Like 10? Maybe even configurable?
>  - EventBus::Register operation is handling IO but is synchronous. The 
> reactor scheduler backing it up is unspecifed (thus is likely the parrallel 
> one). We should let the caller specify the scheduler he whishes to run.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

[jira] [Commented] (JAMES-2208) upgrade netty to netty-all

[Matthieu Baechler (Jira)]

[ 
https://issues.apache.org/jira/browse/JAMES-2208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17128118#comment-17128118
 ] 

Matthieu Baechler commented on JAMES-2208:
--

> Is there any progress on upgrade to Netty 4?

No as far as I know. Feel free to takeover that topic.

> upgrade netty to netty-all
> --
>
> Key: JAMES-2208
> URL: https://issues.apache.org/jira/browse/JAMES-2208
> Project: James Server
>  Issue Type: Improvement
>  Components: James Core
>Affects Versions: 3.0.0
>Reporter: Randymo
>Priority: Major
> Attachments: dependency-check-report.html
>
>
> James is currently using the netty dependency 
> 
> io.netty
> netty
> 3.10.6.Final
> 
> I think we should upgrade to the newer artifact
> 
> io.netty
> netty-all
> 4.1.16.Final
> 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

[jira] [Commented] (JAMES-3211) Generalize EventBus

[Matthieu Baechler (Jira)]

[ 
https://issues.apache.org/jira/browse/JAMES-3211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17133265#comment-17133265
 ] 

Matthieu Baechler commented on JAMES-3211:
--

> However, this is not the case due to the quotas are currently being 
> initialize only after an user receive the first email.

I guess you mean that the "quota search" code is never called because it's only 
notified on messages?

> We need an event-driven system to initialize the quotas after an user has 
> been created successfully. The EventBus in mailbox-api could be generalized 
> so we can implement it to solve this problem without having to depend on this 
> module.

I don't see the causal link between the definition of the problem and this 
solution.
We should put some effort to demonstrate how a given solution solves the 
problem and let other solutions emerge by not "requiring this solution" but 
proposing it and let people analyze if it seems fit.

>  The EventBus in mailbox-api could be generalized so we can implement it to 
> solve this problem without having to depend on this module.

I don't really understand what it means: does it contribute to solve the 
problem explain in the first two lines?

> Generalize EventBus
> ---
>
> Key: JAMES-3211
> URL: https://issues.apache.org/jira/browse/JAMES-3211
> Project: James Server
>  Issue Type: Improvement
>Reporter: Lan Khuat
>Priority: Major
>
> When searching for users by quota ratio if we set the value of the parameters 
> to 0, the search feature is supposed to return newly created users who have 
> not receive any email yet at that point.
> However, this is not the case due to the quotas are currently being 
> initialize only after an user receive the first email.
> We need an event-driven system to initialize the quotas after an user has 
> been created successfully. The EventBus in mailbox-api could be generalized 
> so we can implement it to solve this problem without having to depend on this 
> module.
>  
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

[jira] [Commented] (JAMES-3211) Generalize EventBus

[Matthieu Baechler (Jira)]

[ 
https://issues.apache.org/jira/browse/JAMES-3211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17133278#comment-17133278
 ] 

Matthieu Baechler commented on JAMES-3211:
--

The aforementioned ADR has the same problems than this issue.

> Generalize EventBus
> ---
>
> Key: JAMES-3211
> URL: https://issues.apache.org/jira/browse/JAMES-3211
> Project: James Server
>  Issue Type: Improvement
>Reporter: Lan Khuat
>Priority: Major
>
> When searching for users by quota ratio if we set the value of the parameters 
> to 0, the search feature is supposed to return newly created users who have 
> not receive any email yet at that point.
> However, this is not the case due to the quotas are currently being 
> initialize only after an user receive the first email.
> We need an event-driven system to initialize the quotas after an user has 
> been created successfully. The EventBus in mailbox-api could be generalized 
> so we can implement it to solve this problem without having to depend on this 
> module.
>  
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

[jira] [Commented] (JAMES-3215) Remove SSL support in James

[Matthieu Baechler (Jira)]

[ 
https://issues.apache.org/jira/browse/JAMES-3215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17135505#comment-17135505
 ] 

Matthieu Baechler commented on JAMES-3215:
--

I don't like the idea of having to setup another component to handle what 
should be mandatory for any service in 2020: having encryption over TCP session.

I may be wrong but I suspect all others mail servers handle TLS by themselves. 
(and having encryption termination is not enough because you need to support 
STARTTLS)

Also, I don't agree with this claim.

>  It causes the inclusion of various libraries, and Java suucks for SSL 
> support.

We depend on Java integrated support for encryption that is far from sucking 
AFAIK and bouncycastle that is also quite good. Not really a lot of dependencies

I would rather open a ticket about support certificates without keystores 
and/or implement letsencrypt protocol

> Remove SSL support in James
> ---
>
> Key: JAMES-3215
> URL: https://issues.apache.org/jira/browse/JAMES-3215
> Project: James Server
>  Issue Type: Improvement
>Reporter: David Leangen
>Priority: Major
>
> SSL support is not working [1], and it complicates the installation process. 
> It causes the inclusion of various libraries, and Java suucks for SSL 
> support.
> It would make James a lot simpler to remove SSL support and make SSL 
> termination somebody else's problem. These days it should be easy to use a 
> proxy (like nginx) or an ingress (for example in Kubernetes) to perform SSL 
> termination.
> It would be one less thing to maintain in James, one less thing that can go 
> wrong, one less step to take just to get a James server working, and a step 
> closer to providing good user support.
> {quote}[1] I define "working" by meaning that as a user, I follow the 
> instructions but it still does not work as intended.
> {quote}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

[jira] [Commented] (JAMES-3217) Describe how to include dependencies for the James Local Server

[Matthieu Baechler (Jira)]

[ 
https://issues.apache.org/jira/browse/JAMES-3217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17135514#comment-17135514
 ] 

Matthieu Baechler commented on JAMES-3217:
--

> I think we should remove glowroot from this version. The "entry" level server 
> should be as simple as possible. Not quite a James "Hello World", but as 
> close as we can get while still having something useful in a production 
> setting.

Does glowroot make anything harder to setup?

> Describe how to include dependencies for the James Local Server
> ---
>
> Key: JAMES-3217
> URL: https://issues.apache.org/jira/browse/JAMES-3217
> Project: James Server
>  Issue Type: Sub-task
>Reporter: David Leangen
>Priority: Major
>
> A working server requires the correct dependencies.
> It should be easy for users to gather the right dependencies to set up the 
> James Local Server.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

[jira] [Commented] (JAMES-3215) Remove SSL support in James

[Matthieu Baechler (Jira)]

[ 
https://issues.apache.org/jira/browse/JAMES-3215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17135560#comment-17135560
 ] 

Matthieu Baechler commented on JAMES-3215:
--

> Personally, I would recommend anyone starting and email server to use 
> configure James to use encrypted ports and not use STARTTLS / un-encrypted 
> ports. 

Even for SMTP? I would have think it's required for communication with other 
servers but I may be wrong.

> Remove SSL support in James
> ---
>
> Key: JAMES-3215
> URL: https://issues.apache.org/jira/browse/JAMES-3215
> Project: James Server
>  Issue Type: Improvement
>Reporter: David Leangen
>Assignee: Ioan Eugen Stan
>Priority: Major
>
> SSL support is not working [1], and it complicates the installation process. 
> It causes the inclusion of various libraries, and Java suucks for SSL 
> support.
> It would make James a lot simpler to remove SSL support and make SSL 
> termination somebody else's problem. These days it should be easy to use a 
> proxy (like nginx) or an ingress (for example in Kubernetes) to perform SSL 
> termination.
> It would be one less thing to maintain in James, one less thing that can go 
> wrong, one less step to take just to get a James server working, and a step 
> closer to providing good user support.
> {quote}[1] I define "working" by meaning that as a user, I follow the 
> instructions but it still does not work as intended.
> {quote}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

[jira] [Commented] (JAMES-3215) Remove SSL support in James

[Matthieu Baechler (Jira)]

[ 
https://issues.apache.org/jira/browse/JAMES-3215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17135563#comment-17135563
 ] 

Matthieu Baechler commented on JAMES-3215:
--

Also, Eugen, I don't think you should have close that ticket without David 
opinion: as a member of the community I would find that a bit rude.

> Remove SSL support in James
> ---
>
> Key: JAMES-3215
> URL: https://issues.apache.org/jira/browse/JAMES-3215
> Project: James Server
>  Issue Type: Improvement
>Reporter: David Leangen
>Assignee: Ioan Eugen Stan
>Priority: Major
>
> SSL support is not working [1], and it complicates the installation process. 
> It causes the inclusion of various libraries, and Java suucks for SSL 
> support.
> It would make James a lot simpler to remove SSL support and make SSL 
> termination somebody else's problem. These days it should be easy to use a 
> proxy (like nginx) or an ingress (for example in Kubernetes) to perform SSL 
> termination.
> It would be one less thing to maintain in James, one less thing that can go 
> wrong, one less step to take just to get a James server working, and a step 
> closer to providing good user support.
> {quote}[1] I define "working" by meaning that as a user, I follow the 
> instructions but it still does not work as intended.
> {quote}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

[jira] [Commented] (JAMES-3217) Describe how to include dependencies for the James Local Server

[Matthieu Baechler (Jira)]

[ 
https://issues.apache.org/jira/browse/JAMES-3217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17135720#comment-17135720
 ] 

Matthieu Baechler commented on JAMES-3217:
--

> So the direct answer to your question is "no". However, when I look at the 
> file, I wonder WTF is that? And it creates an incremental cognitive load and 
> perhaps for some a small increment of additional and unnecessary stress.

I agree with what you said about not adding anything that is not necessary.

You mentioned support to the community: glowroot is a tool that helps diagnose 
problems at runtime, I think it makes sense to include it has it will actually 
ease some support cases as well as helping people answer the question: "why it 
is so slow" when it's asked.



> Describe how to include dependencies for the James Local Server
> ---
>
> Key: JAMES-3217
> URL: https://issues.apache.org/jira/browse/JAMES-3217
> Project: James Server
>  Issue Type: Sub-task
>Reporter: David Leangen
>Priority: Major
>
> A working server requires the correct dependencies.
> It should be easy for users to gather the right dependencies to set up the 
> James Local Server.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

[jira] [Commented] (JAMES-3217) Describe how to include dependencies for the James Local Server

[Matthieu Baechler (Jira)]

[ 
https://issues.apache.org/jira/browse/JAMES-3217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17135721#comment-17135721
 ] 

Matthieu Baechler commented on JAMES-3217:
--

> You mean to the James lib, and not the CLI lib? I tried adding it to the CLI 
> lib (where it made sense to me), but that did not help.

Please open an issue about that, we should fix it independently of this issue.

> Describe how to include dependencies for the James Local Server
> ---
>
> Key: JAMES-3217
> URL: https://issues.apache.org/jira/browse/JAMES-3217
> Project: James Server
>  Issue Type: Sub-task
>Reporter: David Leangen
>Priority: Major
>
> A working server requires the correct dependencies.
> It should be easy for users to gather the right dependencies to set up the 
> James Local Server.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

[jira] [Commented] (JAMES-3215) Remove SSL support in James

[Matthieu Baechler (Jira)]

[ 
https://issues.apache.org/jira/browse/JAMES-3215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17135724#comment-17135724
 ] 

Matthieu Baechler commented on JAMES-3215:
--

If I have to define what a mail server should include regarding features, 
encryption (and security and privacy) would be on top of the list. So I would 
rather argue it should be built-in.

Regarding STARTTLS, I agree it's not relevant anymore when you can control the 
other side of the channel. However, as discussed with Eugen, port 25 is 
probably mandatory for communication with servers on the internet.

Finally, regarding letsencrypt support (and maybe remove keystore usage), I 
don't think anybody is actually willing to work on the subject for now.


> Remove SSL support in James
> ---
>
> Key: JAMES-3215
> URL: https://issues.apache.org/jira/browse/JAMES-3215
> Project: James Server
>  Issue Type: Improvement
>Reporter: David Leangen
>Assignee: Ioan Eugen Stan
>Priority: Major
>
> SSL support is not working [1], and it complicates the installation process. 
> It causes the inclusion of various libraries, and Java suucks for SSL 
> support.
> It would make James a lot simpler to remove SSL support and make SSL 
> termination somebody else's problem. These days it should be easy to use a 
> proxy (like nginx) or an ingress (for example in Kubernetes) to perform SSL 
> termination.
> It would be one less thing to maintain in James, one less thing that can go 
> wrong, one less step to take just to get a James server working, and a step 
> closer to providing good user support.
> {quote}[1] I define "working" by meaning that as a user, I follow the 
> instructions but it still does not work as intended.
> {quote}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

[jira] [Commented] (JAMES-3224) Make Cassandra Consistency levels configurable

[Matthieu Baechler (Jira)]

[ 
https://issues.apache.org/jira/browse/JAMES-3224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17136785#comment-17136785
 ] 

Matthieu Baechler commented on JAMES-3224:
--

I feel it's quite dangerous to do that: the application knows better than the 
user which consistency level to use for things.
What we can do is allow to switch QUORUM-style queries to EACH_QUORUM or 
LOCAL_QUORUM but it would not make sense to allow for ONE for example
BTW, we also have, in the codebase, some ONE on specific uses: we can't have a 
single level of configuration as it uses ONE for good reasons.

> Make Cassandra Consistency levels configurable
> --
>
> Key: JAMES-3224
> URL: https://issues.apache.org/jira/browse/JAMES-3224
> Project: James Server
>  Issue Type: Improvement
>  Components: cassandra
>Reporter: Gautier DI FOLCO
>Priority: Minor
>
> Consistency level in Cassandra queries is set explicitly to QUORUM in some 
> cases, and to SERIAL in some other cases (lightweight transactions).
> The goal is to make these queries globally configurable.
> In the {{cassandra.properties}} file, I propose we add two configuration 
> properties:
>  * {{cassandra.consistency_level.regular}} (default to QUORUM to avoid 
> breaking changes)
>  * {{cassandra.consistency_level.lightweight_transaction}} (default to SERIAL)



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

[jira] [Commented] (JAMES-3224) Make Cassandra Consistency levels configurable

[Matthieu Baechler (Jira)]

[ 
https://issues.apache.org/jira/browse/JAMES-3224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17138255#comment-17138255
 ] 

Matthieu Baechler commented on JAMES-3224:
--

Not exactly. I propose:

cassandra.consistency_level.quorum with possible values EACH_QUORUM, QUORUM, 
LOCAL_QUORUM
cassandra.consistency_level.lightweight_transaction with possible values 
SERIAL, LOCAL_SERIAL

the second can be dropped if you want but then we have to decide for each 
quorum type which LWT type we want. Not sure it's a good idea to do that choice 
implicitly.


> Make Cassandra Consistency levels configurable
> --
>
> Key: JAMES-3224
> URL: https://issues.apache.org/jira/browse/JAMES-3224
> Project: James Server
>  Issue Type: Improvement
>  Components: cassandra
>Reporter: Gautier DI FOLCO
>Priority: Minor
>
> Consistency level in Cassandra queries is set explicitly to QUORUM in some 
> cases, and to SERIAL in some other cases (lightweight transactions).
> The goal is to make these queries globally configurable.
> In the {{cassandra.properties}} file, I propose we add two configuration 
> properties:
>  * {{cassandra.consistency_level.regular}} (default to QUORUM to avoid 
> breaking changes)
>  * {{cassandra.consistency_level.lightweight_transaction}} (default to SERIAL)



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

[jira] [Created] (JAMES-2897) Cassandra Lightweight Transaction requires specific consistency level

[Matthieu Baechler (Jira)]

Matthieu Baechler created JAMES-2897:


 Summary: Cassandra Lightweight Transaction requires specific 
consistency level
 Key: JAMES-2897
 URL: https://issues.apache.org/jira/browse/JAMES-2897
 Project: James Server
  Issue Type: Bug
  Components: cassandra
Reporter: Matthieu Baechler


After reading 
https://docs.datastax.com/en/ddac/doc/datastax_enterprise/dbInternals/dbIntLtwtTransactions.html
 , 
https://docs.datastax.com/en/ddaccql/doc/cql/cql_reference/cqlsh_commands/cqlshConsistency.html
 and 
https://docs.datastax.com/en/ddaccql/doc/cql/cql_reference/cqlsh_commands/cqlshSerialConsistency.html
 It looks like we should be more careful about consistency when reading tables 
that use LWT.

Basically, to ensure we always read the last value, we must read with SERIAL 
consistency.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

[jira] [Closed] (JAMES-2897) Cassandra Lightweight Transaction requires specific consistency level

[Matthieu Baechler (Jira)]

 [ 
https://issues.apache.org/jira/browse/JAMES-2897?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Matthieu Baechler closed JAMES-2897.

Resolution: Fixed

merged

> Cassandra Lightweight Transaction requires specific consistency level
> -
>
> Key: JAMES-2897
> URL: https://issues.apache.org/jira/browse/JAMES-2897
> Project: James Server
>  Issue Type: Bug
>  Components: cassandra
>Reporter: Matthieu Baechler
>Priority: Major
>
> After reading 
> https://docs.datastax.com/en/ddac/doc/datastax_enterprise/dbInternals/dbIntLtwtTransactions.html
>  , 
> https://docs.datastax.com/en/ddaccql/doc/cql/cql_reference/cqlsh_commands/cqlshConsistency.html
>  and 
> https://docs.datastax.com/en/ddaccql/doc/cql/cql_reference/cqlsh_commands/cqlshSerialConsistency.html
>  It looks like we should be more careful about consistency when reading 
> tables that use LWT.
> Basically, to ensure we always read the last value, we must read with SERIAL 
> consistency.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

[jira] [Created] (JAMES-2907) InVMEventBus and RabbitMQEventBus do not agree on redelivery

[Matthieu Baechler (Jira)]

Matthieu Baechler created JAMES-2907:


 Summary: InVMEventBus and RabbitMQEventBus do not agree on 
redelivery
 Key: JAMES-2907
 URL: https://issues.apache.org/jira/browse/JAMES-2907
 Project: James Server
  Issue Type: Bug
  Components: eventbus
Reporter: Matthieu Baechler


InVMEventBus attempts several retries on redeliver while RabbitMQEventBus only 
try once.





--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

[jira] [Created] (JAMES-2908) Use cassandra-rabbitmq in webadmin integration tests

[Matthieu Baechler (Jira)]

Matthieu Baechler created JAMES-2908:


 Summary: Use cassandra-rabbitmq in webadmin integration tests
 Key: JAMES-2908
 URL: https://issues.apache.org/jira/browse/JAMES-2908
 Project: James Server
  Issue Type: Task
  Components: tests
Reporter: Matthieu Baechler


webadmin integration tests are not run on all products because it's a bit slow 
to run.
As cassandra-rabbitmq product is now the preferred  distributed implementation, 
we should make webadmin integration tests to run on this product.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

[jira] [Closed] (JAMES-2824) Users should be able to build James with Java 11

[Matthieu Baechler (Jira)]

 [ 
https://issues.apache.org/jira/browse/JAMES-2824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Matthieu Baechler closed JAMES-2824.

Resolution: Fixed

merged for a month or two

> Users should be able to build James with Java 11
> 
>
> Key: JAMES-2824
> URL: https://issues.apache.org/jira/browse/JAMES-2824
> Project: James Server
>  Issue Type: Improvement
>Reporter: Matthieu Baechler
>Priority: Major
>
> Java 11 is the only "Long Term Support" java release right now so more and 
> more people will use it exclusively.
> As a first step towards Java 11 support for James, we should make it possible 
> to build it with a Java 11 compiler (with a "-release 8" javac flag for now).



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

[jira] [Created] (JAMES-2932) Upgrade runtime to Java 11

[Matthieu Baechler (Jira)]

Matthieu Baechler created JAMES-2932:


 Summary: Upgrade runtime to Java 11
 Key: JAMES-2932
 URL: https://issues.apache.org/jira/browse/JAMES-2932
 Project: James Server
  Issue Type: Task
Affects Versions: 3.4.0
Reporter: Matthieu Baechler


Java 11 is the only "Long Term Support" java release right now so more and more 
people will use it exclusively.
Now that James builds to java 11 for some time, we should target java 11 as the 
runtime.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

[jira] [Created] (JAMES-2999) Reuse SpamAssassin container image between test runs

[Matthieu Baechler (Jira)]

Matthieu Baechler created JAMES-2999:


 Summary: Reuse SpamAssassin container image between test runs
 Key: JAMES-2999
 URL: https://issues.apache.org/jira/browse/JAMES-2999
 Project: James Server
  Issue Type: Improvement
  Components: tests
Reporter: Matthieu Baechler


I found that we built the spamassassin container image everytime we run a test 
using this container.
It's testcontainer default behavior when a container image is built 
programmatically. However, it not only deletes the image but any cached layer, 
preventing reuse and thus speed gains.
By the way, as images share the same layers, not deleting the images has almost 
no space usage.
We should disable deleteOnExit option.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

[jira] [Created] (JAMES-3001) SpamAssassinContract tests are unstable

[Matthieu Baechler (Jira)]

Matthieu Baechler created JAMES-3001:


 Summary: SpamAssassinContract tests are unstable
 Key: JAMES-3001
 URL: https://issues.apache.org/jira/browse/JAMES-3001
 Project: James Server
  Issue Type: Bug
  Components: tests
Reporter: Matthieu Baechler


SpamAssassinContract are failing very often on the CI.
We should try to fix these issues.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

[jira] [Created] (JAMES-3003) Mailbox event delivery should run synchronous listeners concurrently

[Matthieu Baechler (Jira)]

Matthieu Baechler created JAMES-3003:


 Summary: Mailbox event delivery should run synchronous listeners 
concurrently
 Key: JAMES-3003
 URL: https://issues.apache.org/jira/browse/JAMES-3003
 Project: James Server
  Issue Type: Bug
Reporter: Matthieu Baechler


While profiling mail reception I found that latency is higher than needed 
because listeners are run sequentially.
We can actually run them all at the same time for a given event and then wait 
for the synchronous listeners to complete.
Let's see if it unlock a better reception rate.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

[jira] [Created] (JAMES-3004) Reactor boundedElastic can lead to deadlocks

[Matthieu Baechler (Jira)]

Matthieu Baechler created JAMES-3004:


 Summary: Reactor boundedElastic can lead to deadlocks
 Key: JAMES-3004
 URL: https://issues.apache.org/jira/browse/JAMES-3004
 Project: James Server
  Issue Type: Bug
Reporter: Matthieu Baechler


Reactor authors advise users to prefer boundedElastic Scheduler to elastic one.
With https://issues.apache.org/jira/browse/JAMES-2899 we decided to use it as 
it allows to use less threads.
However, we found that it can lead to deadlocks because of complex starvation 
scenarios.
The reality is that James is still calling `block` a lot on Mono/Flux for now 
and the advice doesn't stand in the context.
We can either create a boundedElastic for each usages or revert 
https://issues.apache.org/jira/browse/JAMES-2899 to workaround that risk 
waiting for the day James will be async from end to end.




--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

[jira] [Closed] (JAMES-3001) SpamAssassinContract tests are unstable

[Matthieu Baechler (Jira)]

 [ 
https://issues.apache.org/jira/browse/JAMES-3001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Matthieu Baechler closed JAMES-3001.

Resolution: Fixed

> SpamAssassinContract tests are unstable
> ---
>
> Key: JAMES-3001
> URL: https://issues.apache.org/jira/browse/JAMES-3001
> Project: James Server
>  Issue Type: Bug
>  Components: tests
>Reporter: Matthieu Baechler
>Priority: Major
>
> SpamAssassinContract are failing very often on the CI.
> We should try to fix these issues.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

[jira] [Closed] (JAMES-3003) Mailbox event delivery should run synchronous listeners concurrently

[Matthieu Baechler (Jira)]

 [ 
https://issues.apache.org/jira/browse/JAMES-3003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Matthieu Baechler closed JAMES-3003.

Resolution: Fixed

> Mailbox event delivery should run synchronous listeners concurrently
> 
>
> Key: JAMES-3003
> URL: https://issues.apache.org/jira/browse/JAMES-3003
> Project: James Server
>  Issue Type: Bug
>Reporter: Matthieu Baechler
>Priority: Major
>
> While profiling mail reception I found that latency is higher than needed 
> because listeners are run sequentially.
> We can actually run them all at the same time for a given event and then wait 
> for the synchronous listeners to complete.
> Let's see if it unlock a better reception rate.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

[jira] [Closed] (JAMES-3004) Reactor boundedElastic can lead to deadlocks

[Matthieu Baechler (Jira)]

 [ 
https://issues.apache.org/jira/browse/JAMES-3004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Matthieu Baechler closed JAMES-3004.

Resolution: Fixed

> Reactor boundedElastic can lead to deadlocks
> 
>
> Key: JAMES-3004
> URL: https://issues.apache.org/jira/browse/JAMES-3004
> Project: James Server
>  Issue Type: Bug
>Reporter: Matthieu Baechler
>Priority: Major
>
> Reactor authors advise users to prefer boundedElastic Scheduler to elastic 
> one.
> With https://issues.apache.org/jira/browse/JAMES-2899 we decided to use it as 
> it allows to use less threads.
> However, we found that it can lead to deadlocks because of complex starvation 
> scenarios.
> The reality is that James is still calling `block` a lot on Mono/Flux for now 
> and the advice doesn't stand in the context.
> We can either create a boundedElastic for each usages or revert 
> https://issues.apache.org/jira/browse/JAMES-2899 to workaround that risk 
> waiting for the day James will be async from end to end.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

[jira] [Created] (JAMES-3015) DeploymentValidation tests could be promoted as integration-tests

[Matthieu Baechler (Jira)]

Matthieu Baechler created JAMES-3015:


 Summary: DeploymentValidation tests could be promoted as 
integration-tests
 Key: JAMES-3015
 URL: https://issues.apache.org/jira/browse/JAMES-3015
 Project: James Server
  Issue Type: Bug
  Components: Build System
Reporter: Matthieu Baechler


When running the Jenkins pipeline for a build, we create docker images for 
various James products, deploy them and run some smoke tests on it.

As great as it is, it's unfortunate that this requires Jenkins because that 
means we can't easily run the same tests as a developer.

We could create the docker images during the maven process and run the smoke 
tests during an integration-test phase.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

[jira] [Commented] (JAMES-3019) Clear and flexible handling of base directory

[Matthieu Baechler (Jira)]

[ 
https://issues.apache.org/jira/browse/JAMES-3019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17008842#comment-17008842
 ] 

Matthieu Baechler commented on JAMES-3019:
--

Hi [~sergey-b] and thank you for opening this issue.

I worked on this very topic recently and came to the following conclusions:
* we should behave like any system daemon, that is : read configuration from 
/etc, write data to /var, and so on, by default
* we should allow to override each directory from the command line
* we should provide a real command line "launcher" to implement these options

WDYT about this?



> Clear and flexible handling of base directory
> -
>
> Key: JAMES-3019
> URL: https://issues.apache.org/jira/browse/JAMES-3019
> Project: James Server
>  Issue Type: Improvement
>Affects Versions: 3.3.0, 3.4.0
>Reporter: Sergey B.
>Priority: Major
>
> We need to have a single value from which all relative urls are evaluated. 
> Now some urls pointing to the same places are specified by different values. 
> For example var directory for database storage is presented by the value 
> '../var/' in database.url property, while the same directory for 
> MailRepository is designated by 'file://var/.
> It's confusing. I suggest we make an improvement.
>  # There must be a single value of basedir, from which all relative urls are 
> evaluated.
>  # Algorithm of evaluation of default basedir value must be documented.
>  # Default basedir must be at top level of all resources. I. e. there must be 
> no paths like ../.
>  # Effective basedir must be logged.
>  # There must be an opportunity for users to specify their own basedir on 
> server startup.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

[jira] [Created] (JAMES-3021) When using a docker network, the container ip is not resolved the right way

[Matthieu Baechler (Jira)]

Matthieu Baechler created JAMES-3021:


 Summary: When using a docker network, the container ip is not 
resolved the right way
 Key: JAMES-3021
 URL: https://issues.apache.org/jira/browse/JAMES-3021
 Project: James Server
  Issue Type: Bug
  Components: tests
Reporter: Matthieu Baechler


There are various setup of docker use and it's quite hard to know what IP 
should be used in those various situations.

Until now, we found a solution that solved local dev on linux and mac and CI at 
the same time.

Now we want to use docker networks to run several containers in a network 
during tests and container IP is not resolved to the container IP in this 
network (that should be reachable because docker takes care of the routing 
table).

Let's try to fix all these cases at once (and maybe upstream the solution to 
testcontainers project once done)



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

[jira] [Closed] (JAMES-3021) When using a docker network, the container ip is not resolved the right way

[Matthieu Baechler (Jira)]

 [ 
https://issues.apache.org/jira/browse/JAMES-3021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Matthieu Baechler closed JAMES-3021.

Resolution: Fixed

> When using a docker network, the container ip is not resolved the right way
> ---
>
> Key: JAMES-3021
> URL: https://issues.apache.org/jira/browse/JAMES-3021
> Project: James Server
>  Issue Type: Bug
>  Components: tests
>Reporter: Matthieu Baechler
>Priority: Major
>
> There are various setup of docker use and it's quite hard to know what IP 
> should be used in those various situations.
> Until now, we found a solution that solved local dev on linux and mac and CI 
> at the same time.
> Now we want to use docker networks to run several containers in a network 
> during tests and container IP is not resolved to the container IP in this 
> network (that should be reachable because docker takes care of the routing 
> table).
> Let's try to fix all these cases at once (and maybe upstream the solution to 
> testcontainers project once done)



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

[jira] [Created] (JAMES-3025) ConcurrentTestRunner could support basic distribution patterns

[Matthieu Baechler (Jira)]

Matthieu Baechler created JAMES-3025:


 Summary: ConcurrentTestRunner could support basic distribution 
patterns
 Key: JAMES-3025
 URL: https://issues.apache.org/jira/browse/JAMES-3025
 Project: James Server
  Issue Type: New Feature
  Components: tests
Reporter: Matthieu Baechler


In James, we often want to check that under concurrent workload, our components 
behave correctly at a unit level.
For that, we implemented ConcurrentTestRunner that helps dealing with defining 
the scenarios we want.
However, in case we want operations to be run in a pseudo-random way while 
respecting an even distribution, we write similar code:
{code}
switch (random(numberOfCases)) {
  case 0: firstOperation
  case 1: secondOperation
  case 2: thirdOperation
  ...
}
{code}
We can enhance this situation a bit by providing a method that make the intent 
more obvious:
{code}
randomlyDistributedOperations(
  firstOperation,
  secondOperation,
  thirdOperation
)
{code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

[jira] [Commented] (JAMES-385) Allow to prevent weak ciphers when using "useTLS"

[Matthieu Baechler (JIRA)]

[ 
https://issues.apache.org/jira/browse/JAMES-385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14483365#comment-14483365
 ] 

Matthieu Baechler commented on JAMES-385:
-

Does this ticket still need work ?

> Allow to prevent weak ciphers when using "useTLS"
> -
>
> Key: JAMES-385
> URL: https://issues.apache.org/jira/browse/JAMES-385
> Project: James Server
>  Issue Type: Bug
>  Components: SMTPServer
>Affects Versions: 2.2.0, 2.3.0, 2.3.1, 2.3.2, 3.0-M1, 3.0-M2
> Environment: Linux, jdk 1.4
>Reporter: Ralf Hauser
>Assignee: Eric Charles
>Priority: Critical
> Fix For: 3.0-beta3, 3.0.0-beta5
>
> Attachments: Cornerstone.patch.zip
>
>
> http://james.apache.org/usingTLS_2_1.html and 
> http://wiki.apache.org/james/UsingSSL explain how to setup a pop3s etc. 
> describe how to secure a client connection to James.
>openssl s_client -connect pops.mydom.com:995 -cipher EXPORT
> illustrates that this is possible with james.
> One might argue that a decent client will never ask the server to negotiate a 
> weak cipher. But an attacker (man-in-the-middle) could remove stronger 
> ciphers from the client's offered cipher list, and then break the weak cipher 
> and e.g. obtain the user password to later hijack the account.
> Please amend the documentation how prevent this from happening by forcing 
> james to only negotiate sessions with 128+ bit session key strength



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

[jira] [Created] (MAILBOX-221) Make sure we use Java-6-only API

[Matthieu Baechler (JIRA)]

Matthieu Baechler created MAILBOX-221:
-

 Summary: Make sure we use Java-6-only API
 Key: MAILBOX-221
 URL: https://issues.apache.org/jira/browse/MAILBOX-221
 Project: James Mailbox
  Issue Type: Improvement
Reporter: Matthieu Baechler
Priority: Minor
 Fix For: 0.6


Java compiler is not able to detect the use of non-java-6 API when compiled 
with Java 7 or Java 8. It only detects language-level features.

However, there's a maven plugin that can check this.

It's very valuable in a context of heterogeneous modules.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

[jira] [Created] (MAILBOX-222) Use java 8 for Cassandra Backend

[Matthieu Baechler (JIRA)]

Matthieu Baechler created MAILBOX-222:
-

 Summary: Use java 8 for Cassandra Backend
 Key: MAILBOX-222
 URL: https://issues.apache.org/jira/browse/MAILBOX-222
 Project: James Mailbox
  Issue Type: Improvement
Reporter: Matthieu Baechler
Priority: Minor
 Fix For: 0.6


Cassandra backend will use jdk8.
We must require java 8 to compile it but just ignore this module when using 
java < 8 to prevent build from breaking in this configuration.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

[jira] [Commented] (JAMES-1522) Running james 3.0beta5 fails due to unsatisfied dependencies

[Matthieu Baechler (JIRA)]

[ 
https://issues.apache.org/jira/browse/JAMES-1522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14507147#comment-14507147
 ] 

Matthieu Baechler commented on JAMES-1522:
--

Could you please give us your configuration files ?

> Running james 3.0beta5 fails due to unsatisfied dependencies
> 
>
> Key: JAMES-1522
> URL: https://issues.apache.org/jira/browse/JAMES-1522
> Project: James Server
>  Issue Type: Bug
>  Components: Build System, James Core
>Affects Versions: Trunk
>Reporter: Lee Hanxue
>  Labels: build
> Fix For: 3.0.0-beta5
>
>
> When starting James server after a clean build, this is the error that is 
> produced:
> WARN  00:48:07,605 | 
> org.springframework.beans.factory.support.DisposableBeanAdapter | Invocation 
> of destroy method failed on bean with name 'entityManagerFactory': 
>  
> org.apache.openjpa.persistence.InvalidStateException: This operation failed 
> for some instances.  See the nested exceptions array for details.
> Exception in thread "main" 
> org.springframework.beans.factory.UnsatisfiedDependencyException: Error 
> creating bean with name 'mailprocessor' defined in class path resource 
> [META-INF/spring/mailetcontainer-context.xml]: Unsatisfied dependency 
> expressed through bean property 'mailetContext': : Error creating bean with 
> name 'mailetcontext' defined in class path resource 
> [META-INF/spring/mailetcontainer-context.xml]: Initialization of bean failed; 
> nested exception is org.springframework.beans.FatalBeanException: Unable to 
> execute lifecycle method on beanmailetcontext; nested exception is 
>  
> org.apache.openjpa.persistence.InvalidStateException: This operation cannot 
> be performed while a Transaction is active.; nested exception is 
> org.springframework.beans.factory.BeanCreationException: Error creating bean 
> with name 'mailetcontext' defined in class path resource 
> [META-INF/spring/mailetcontainer-context.xml]: Initialization of bean failed; 
> nested exception is org.springframework.beans.FatalBeanException: Unable to 
> execute lifecycle method on beanmailetcontext; nested exception is 
>  
> org.apache.openjpa.persistence.InvalidStateException: This operation cannot 
> be performed while a Transaction is active.
>   at 
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.autowireByType(AbstractAutowireCapableBeanFactory.java:1199)
>   at 
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.populateBean(AbstractAutowireCapableBeanFactory.java:1091)
>   at 
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:517)
>   at 
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:456)
>   at 
> org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:294)
>   at 
> org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:225)
>   at 
> org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:291)
>   at 
> org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:193)
>   at 
> org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:609)
>   at 
> org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:918)
>   at 
> org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:469)
>   at 
> org.springframework.context.support.ClassPathXmlApplicationContext.(ClassPathXmlApplicationContext.java:139)
>   at 
> org.springframework.context.support.ClassPathXmlApplicationContext.(ClassPathXmlApplicationContext.java:93)
>   at 
> org.apache.james.container.spring.context.JamesServerApplicationContext.(JamesServerApplicationContext.java:39)
>   at 
> org.apache.james.app.spring.JamesAppSpringMain.init(JamesAppSpringMain.java:61)
>   at 
> org.apache.james.app.spring.JamesAppSpringMain.main(JamesAppSpringMain.java:42)
> Caused by: org.springframework.beans.factory.BeanCreationException: Error 
> creating bean with name 'mailetcontext' defined in class path resource 
> [META-INF/spring/mailetcontainer-context.xml]: Initialization of bean failed; 
> nested exception is org.springframework.beans.FatalBeanException: Unable to 
> execute lifecycle method on beanmailetcontext; nested exception is 
>  
> org.apache.openjpa.persistence.InvalidStateException: This operation cannot 
> be perf

[jira] [Created] (JAMES-1571) james-project breaks apache-mime4j build

[Matthieu Baechler (JIRA)]

Matthieu Baechler created JAMES-1571:


 Summary: james-project breaks apache-mime4j build 
 Key: JAMES-1571
 URL: https://issues.apache.org/jira/browse/JAMES-1571
 Project: James Server
  Issue Type: Bug
  Components: Build System
Reporter: Matthieu Baechler


When upgrading james-mime4j 0.7.2 to james-project 1.8.2, maven tries to create 
some jars for projects with packaging=pom.
This is related to changes introduced by JAMES-1465.

We should either rework JAMES-1465 or change maven-jar-plugin configuration in 
james-mime4j projects.




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

[jira] [Updated] (MAILBOX-221) Make sure we use Java-6-only API

[Matthieu Baechler (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MAILBOX-221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Matthieu Baechler updated MAILBOX-221:
--
Attachment: 0001-MAILBOX-221-enforce-use-of-jdk-6-at-build-time.patch

Patch generated from the github PR

> Make sure we use Java-6-only API
> 
>
> Key: MAILBOX-221
> URL: https://issues.apache.org/jira/browse/MAILBOX-221
> Project: James Mailbox
>  Issue Type: Improvement
>Reporter: Matthieu Baechler
>Priority: Minor
> Fix For: 0.6
>
> Attachments: 0001-MAILBOX-221-enforce-use-of-jdk-6-at-build-time.patch
>
>
> Java compiler is not able to detect the use of non-java-6 API when compiled 
> with Java 7 or Java 8. It only detects language-level features.
> However, there's a maven plugin that can check this.
> It's very valuable in a context of heterogeneous modules.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

[jira] [Updated] (MAILBOX-222) Use java 8 for Cassandra Backend

[Matthieu Baechler (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MAILBOX-222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Matthieu Baechler updated MAILBOX-222:
--
Attachment: 0001-MAILBOX-222-disable-build-of-cassandra-module-when-j.patch

Patch generated from github PR

> Use java 8 for Cassandra Backend
> 
>
> Key: MAILBOX-222
> URL: https://issues.apache.org/jira/browse/MAILBOX-222
> Project: James Mailbox
>  Issue Type: Improvement
>Reporter: Matthieu Baechler
>Priority: Minor
> Fix For: 0.6
>
> Attachments: 
> 0001-MAILBOX-222-disable-build-of-cassandra-module-when-j.patch
>
>
> Cassandra backend will use jdk8.
> We must require java 8 to compile it but just ignore this module when using 
> java < 8 to prevent build from breaking in this configuration.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

[jira] [Updated] (MAILBOX-223) ACL interfaces refactor

[Matthieu Baechler (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MAILBOX-223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Matthieu Baechler updated MAILBOX-223:
--
Attachment: 0002-MAILBOX-223-Remove-MaildirMailbox-use-SimpleMailbox-.patch
0001-MAILBOX-223-Update-API-so-that-ACL-operation-are-acc.patch

patches generated from github PR.

> ACL interfaces refactor
> ---
>
> Key: MAILBOX-223
> URL: https://issues.apache.org/jira/browse/MAILBOX-223
> Project: James Mailbox
>  Issue Type: Improvement
>Reporter: Tellier Benoit
> Attachments: 
> 0001-MAILBOX-223-Update-API-so-that-ACL-operation-are-acc.patch, 
> 0002-MAILBOX-223-Remove-MaildirMailbox-use-SimpleMailbox-.patch
>
>
> ACL management should be delegated to mailbox manager.
> Updating ACL should be done in the MailboxMapper to allow implementation 
> specific operations. We should not overwrite the SimpleMailbox Bean to 
> achieve our goals.
> Currently available implementation should not have changed behavior. Hence 
> Maildir implementation need to be updated.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

[jira] [Commented] (MAILBOX-223) ACL interfaces refactor

[Matthieu Baechler (JIRA)]

[ 
https://issues.apache.org/jira/browse/MAILBOX-223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14513054#comment-14513054
 ] 

Matthieu Baechler commented on MAILBOX-223:
---

You can't just check the first patch then the second as the second uses parts 
of the first.
To apply the patches, you can simply run git am 000{1,2}*
I've just checked here and it seems ok.

> ACL interfaces refactor
> ---
>
> Key: MAILBOX-223
> URL: https://issues.apache.org/jira/browse/MAILBOX-223
> Project: James Mailbox
>  Issue Type: Improvement
>Reporter: Tellier Benoit
> Attachments: 
> 0001-MAILBOX-223-Update-API-so-that-ACL-operation-are-acc.patch, 
> 0002-MAILBOX-223-Remove-MaildirMailbox-use-SimpleMailbox-.patch
>
>
> ACL management should be delegated to mailbox manager.
> Updating ACL should be done in the MailboxMapper to allow implementation 
> specific operations. We should not overwrite the SimpleMailbox Bean to 
> achieve our goals.
> Currently available implementation should not have changed behavior. Hence 
> Maildir implementation need to be updated.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

[jira] [Comment Edited] (MAILBOX-223) ACL interfaces refactor

[Matthieu Baechler (JIRA)]

[ 
https://issues.apache.org/jira/browse/MAILBOX-223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14513054#comment-14513054
 ] 

Matthieu Baechler edited comment on MAILBOX-223 at 4/26/15 2:35 PM:


You can't just check the first patch then the second as the second uses parts 
of the first.
To apply the patches, you can simply run {code}git am 000{1,2}* {code}
I've just checked here and it seems ok.


was (Author: matthieub):
You can't just check the first patch then the second as the second uses parts 
of the first.
To apply the patches, you can simply run git am 000{1,2}*
I've just checked here and it seems ok.

> ACL interfaces refactor
> ---
>
> Key: MAILBOX-223
> URL: https://issues.apache.org/jira/browse/MAILBOX-223
> Project: James Mailbox
>  Issue Type: Improvement
>Reporter: Tellier Benoit
> Attachments: 
> 0001-MAILBOX-223-Update-API-so-that-ACL-operation-are-acc.patch, 
> 0002-MAILBOX-223-Remove-MaildirMailbox-use-SimpleMailbox-.patch
>
>
> ACL management should be delegated to mailbox manager.
> Updating ACL should be done in the MailboxMapper to allow implementation 
> specific operations. We should not overwrite the SimpleMailbox Bean to 
> achieve our goals.
> Currently available implementation should not have changed behavior. Hence 
> Maildir implementation need to be updated.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

[jira] [Updated] (MAILBOX-223) ACL interfaces refactor

[Matthieu Baechler (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MAILBOX-223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Matthieu Baechler updated MAILBOX-223:
--
Attachment: 0001-MAILBOX-223-Update-API-so-that-ACL-operation-are-acc.patch

This patch is a merge of previous patches.

> ACL interfaces refactor
> ---
>
> Key: MAILBOX-223
> URL: https://issues.apache.org/jira/browse/MAILBOX-223
> Project: James Mailbox
>  Issue Type: Improvement
>Reporter: Tellier Benoit
> Attachments: 
> 0001-MAILBOX-223-Update-API-so-that-ACL-operation-are-acc.patch, 
> 0001-MAILBOX-223-Update-API-so-that-ACL-operation-are-acc.patch, 
> 0002-MAILBOX-223-Remove-MaildirMailbox-use-SimpleMailbox-.patch
>
>
> ACL management should be delegated to mailbox manager.
> Updating ACL should be done in the MailboxMapper to allow implementation 
> specific operations. We should not overwrite the SimpleMailbox Bean to 
> achieve our goals.
> Currently available implementation should not have changed behavior. Hence 
> Maildir implementation need to be updated.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

[jira] [Updated] (MAILBOX-223) ACL interfaces refactor

[Matthieu Baechler (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MAILBOX-223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Matthieu Baechler updated MAILBOX-223:
--
Attachment: (was: 
0001-MAILBOX-223-Update-API-so-that-ACL-operation-are-acc.patch)

> ACL interfaces refactor
> ---
>
> Key: MAILBOX-223
> URL: https://issues.apache.org/jira/browse/MAILBOX-223
> Project: James Mailbox
>  Issue Type: Improvement
>Reporter: Tellier Benoit
>Assignee: Eric Charles
> Fix For: 0.6
>
> Attachments: 
> 0001-MAILBOX-223-Update-API-so-that-ACL-operation-are-acc.patch
>
>
> ACL management should be delegated to mailbox manager.
> Updating ACL should be done in the MailboxMapper to allow implementation 
> specific operations. We should not overwrite the SimpleMailbox Bean to 
> achieve our goals.
> Currently available implementation should not have changed behavior. Hence 
> Maildir implementation need to be updated.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

[jira] [Updated] (MAILBOX-223) ACL interfaces refactor

[Matthieu Baechler (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MAILBOX-223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Matthieu Baechler updated MAILBOX-223:
--
Attachment: (was: 
0002-MAILBOX-223-Remove-MaildirMailbox-use-SimpleMailbox-.patch)

> ACL interfaces refactor
> ---
>
> Key: MAILBOX-223
> URL: https://issues.apache.org/jira/browse/MAILBOX-223
> Project: James Mailbox
>  Issue Type: Improvement
>Reporter: Tellier Benoit
>Assignee: Eric Charles
> Fix For: 0.6
>
> Attachments: 
> 0001-MAILBOX-223-Update-API-so-that-ACL-operation-are-acc.patch
>
>
> ACL management should be delegated to mailbox manager.
> Updating ACL should be done in the MailboxMapper to allow implementation 
> specific operations. We should not overwrite the SimpleMailbox Bean to 
> achieve our goals.
> Currently available implementation should not have changed behavior. Hence 
> Maildir implementation need to be updated.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

[jira] [Commented] (MAILBOX-223) ACL interfaces refactor

[Matthieu Baechler (JIRA)]

[ 
https://issues.apache.org/jira/browse/MAILBOX-223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14517822#comment-14517822
 ] 

Matthieu Baechler commented on MAILBOX-223:
---

It should be removed.

> ACL interfaces refactor
> ---
>
> Key: MAILBOX-223
> URL: https://issues.apache.org/jira/browse/MAILBOX-223
> Project: James Mailbox
>  Issue Type: Improvement
>Reporter: Tellier Benoit
>Assignee: Eric Charles
> Fix For: 0.6
>
> Attachments: 
> 0001-MAILBOX-223-Update-API-so-that-ACL-operation-are-acc.patch
>
>
> ACL management should be delegated to mailbox manager.
> Updating ACL should be done in the MailboxMapper to allow implementation 
> specific operations. We should not overwrite the SimpleMailbox Bean to 
> achieve our goals.
> Currently available implementation should not have changed behavior. Hence 
> Maildir implementation need to be updated.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

[jira] [Created] (JSIEVE-97) James JSieve should use latest version of other James subprojects

[Matthieu Baechler (JIRA)]

Matthieu Baechler created JSIEVE-97:
---

 Summary: James JSieve should use latest version of other James 
subprojects
 Key: JSIEVE-97
 URL: https://issues.apache.org/jira/browse/JSIEVE-97
 Project: James jSieve
  Issue Type: Task
  Components: MultiModule
Reporter: Matthieu Baechler
 Fix For: 0.6


It should depend on james-project 1.8.3-SNAPSHOT and mime4j 0.8 to use only 
up-to-date component.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

[jira] [Updated] (JSIEVE-97) James JSieve should use latest version of other James subprojects

[Matthieu Baechler (JIRA)]

 [ 
https://issues.apache.org/jira/browse/JSIEVE-97?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Matthieu Baechler updated JSIEVE-97:

Attachment: 0001-JWC-111-Updating-parent-project.patch

This patch update dependencies and fix a call to mime4j.

> James JSieve should use latest version of other James subprojects
> -
>
> Key: JSIEVE-97
> URL: https://issues.apache.org/jira/browse/JSIEVE-97
> Project: James jSieve
>  Issue Type: Task
>  Components: MultiModule
>Reporter: Matthieu Baechler
> Fix For: 0.6
>
> Attachments: 0001-JWC-111-Updating-parent-project.patch
>
>
> It should depend on james-project 1.8.3-SNAPSHOT and mime4j 0.8 to use only 
> up-to-date component.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

[jira] [Created] (MPT-12) Run MTP test suite on Cassandra backend

[Matthieu Baechler (JIRA)]

Matthieu Baechler created MPT-12:


 Summary: Run MTP test suite on Cassandra backend
 Key: MPT-12
 URL: https://issues.apache.org/jira/browse/MPT-12
 Project: James MPT
  Issue Type: Improvement
Reporter: Matthieu Baechler


We would like to check that James over cassandra pass all mpt tests. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

[jira] [Commented] (MAILBOX-230) Mailbox should use latest version of other James subprojects

[Matthieu Baechler (JIRA)]

[ 
https://issues.apache.org/jira/browse/MAILBOX-230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14539984#comment-14539984
 ] 

Matthieu Baechler commented on MAILBOX-230:
---

Eric, could you please merge these patches ? It's a blocker for us.

> Mailbox should use latest version of other James subprojects
> 
>
> Key: MAILBOX-230
> URL: https://issues.apache.org/jira/browse/MAILBOX-230
> Project: James Mailbox
>  Issue Type: Improvement
>Reporter: Antoine Duprat
> Fix For: 0.6
>
> Attachments: 
> 0001-JWC-111-update-james-related-projects-to-SNAPSHOT-ve.patch, 
> 0002-JWC-111-update-mime4j-to-0.8.0-SNAPSHOT.patch
>
>
> We want an integration tool that builds the entire James project in its 
> latest version.
> To do that, each james project needs to use the latest version of all other 
> James subprojects.
> In JDKIM, this means :
> - Update mailet version
> - Update james-project version
> - Update mime4j version



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

[jira] [Created] (MAILBOX-236) Strong type for Mailbox & Message ids

[Matthieu Baechler (JIRA)]

Matthieu Baechler created MAILBOX-236:
-

 Summary: Strong type for Mailbox & Message ids
 Key: MAILBOX-236
 URL: https://issues.apache.org/jira/browse/MAILBOX-236
 Project: James Mailbox
  Issue Type: Improvement
Reporter: Matthieu Baechler


I'd like to bring something that bothers me : whenever you get an Id from a 
Message or a Mailbox, you can only call Object methods.

It makes some code rely on toString() call in case of serialization.

If you put aside some special types, toString is not supposed to return a 
stable and meaningful value.

I'd like to make Message and Mailbox use a bounded parameters. This parameter 
would extend an Id interface, and this interface could have a serialize method.

Comments welcome (and patch is coming soon)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

[jira] [Updated] (MAILBOX-236) Strong type for Mailbox id

[Matthieu Baechler (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MAILBOX-236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Matthieu Baechler updated MAILBOX-236:
--
Description: 
I'd like to bring something that bothers me : whenever you get an Id from a 
Mailbox, you can only call Object methods.

It makes some code rely on toString() call in case of serialization.

If you put aside some special types, toString is not supposed to return a 
stable and meaningful value.

I'd like to make Message and Mailbox use a bounded parameters. This parameter 
would extend an Id interface, and this interface could have a serialize method.

Comments welcome (and patch is coming soon)

  was:
I'd like to bring something that bothers me : whenever you get an Id from a 
Message or a Mailbox, you can only call Object methods.

It makes some code rely on toString() call in case of serialization.

If you put aside some special types, toString is not supposed to return a 
stable and meaningful value.

I'd like to make Message and Mailbox use a bounded parameters. This parameter 
would extend an Id interface, and this interface could have a serialize method.

Comments welcome (and patch is coming soon)

Summary: Strong type for Mailbox id  (was: Strong type for Mailbox & 
Message ids)

> Strong type for Mailbox id
> --
>
> Key: MAILBOX-236
> URL: https://issues.apache.org/jira/browse/MAILBOX-236
> Project: James Mailbox
>  Issue Type: Improvement
>Reporter: Matthieu Baechler
>
> I'd like to bring something that bothers me : whenever you get an Id from a 
> Mailbox, you can only call Object methods.
> It makes some code rely on toString() call in case of serialization.
> If you put aside some special types, toString is not supposed to return a 
> stable and meaningful value.
> I'd like to make Message and Mailbox use a bounded parameters. This parameter 
> would extend an Id interface, and this interface could have a serialize 
> method.
> Comments welcome (and patch is coming soon)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

[jira] [Closed] (MAILBOX-236) Strong type for Mailbox id

[Matthieu Baechler (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MAILBOX-236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Matthieu Baechler closed MAILBOX-236.
-
Resolution: Fixed

> Strong type for Mailbox id
> --
>
> Key: MAILBOX-236
> URL: https://issues.apache.org/jira/browse/MAILBOX-236
> Project: James Mailbox
>  Issue Type: Improvement
>Reporter: Matthieu Baechler
>
> I'd like to bring something that bothers me : whenever you get an Id from a 
> Mailbox, you can only call Object methods.
> It makes some code rely on toString() call in case of serialization.
> If you put aside some special types, toString is not supposed to return a 
> stable and meaningful value.
> I'd like to make Message and Mailbox use a bounded parameters. This parameter 
> would extend an Id interface, and this interface could have a serialize 
> method.
> Comments welcome (and patch is coming soon)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

[jira] [Created] (JAMES-1586) Write a compliant Cassandra User Repository

[Matthieu Baechler (JIRA)]

Matthieu Baechler created JAMES-1586:


 Summary: Write a compliant Cassandra User Repository
 Key: JAMES-1586
 URL: https://issues.apache.org/jira/browse/JAMES-1586
 Project: James Server
  Issue Type: New Feature
Reporter: Matthieu Baechler


To complete the Cassandra backend, we should write a User Repository on top of 
Cassandra.

There's already some code there : 
https://github.com/mbaechler/james/commits/cassandra but it can't be integrated 
as is, it needs some refactoring to use mailbox Cassandra infrastructure.

Once done, we should update the spring configuration to deploy this repository 
and make sure integration tests on a deployed james still works.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

[jira] [Commented] (JAMES-1593) James Spooler performance issue

[Matthieu Baechler (JIRA)]

[ 
https://issues.apache.org/jira/browse/JAMES-1593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14638334#comment-14638334
 ] 

Matthieu Baechler commented on JAMES-1593:
--

geronimo-javamail is supposed to be API compatible with javax.mail.
If you have a look at mailbox/pom.xml, you can see that there's a profile to 
compile with geronimo (the default being using javax.mail).
You could use the same trick to make it possible to choose the javamail 
implementation in other modules in order to try javax.mail for your actual 
problem.

> James Spooler performance issue
> ---
>
> Key: JAMES-1593
> URL: https://issues.apache.org/jira/browse/JAMES-1593
> Project: James Server
>  Issue Type: Bug
>  Components: SMTPServer
>Affects Versions: 3.0-beta4
> Environment: Linux , CentOS release 6.6 (Final), 
>Reporter: Mehdi Salarkia
>  Labels: newbie, performance
>
> We have a mail system based on Apache james and we are experiencing some 
> performance issues .
> The current implementation of Apache james has a dependency on Apache 
> Geronimo for mime and mail processing and it seems there is an issue at-least 
>  in the version "geronimo-javamail_1.4_mail"  package .
> It seems like the "javax.mail.internet.MimeMessage.getEncoding()" method 
> never finishes and when I look at the cpu and I profiled the application it 
> shows this method has a high cpu consumtion, here is a jstack of what was 
> happening at the time:
> "spooler-1" daemon prio=10 tid=0x2b3ee9a5 nid=0x57b4 runnable 
> [0x2b3e8388d000]
>java.lang.Thread.State: RUNNABLE
>   at javax.mail.internet.MimeMessage.getEncoding(MimeMessage.java:751)
>   at 
> org.apache.james.core.MimeMessageUtil.writeMessageBodyTo(MimeMessageUtil.java:135)
>   at 
> org.apache.james.core.MimeMessageWrapper.writeTo(MimeMessageWrapper.java:338)
>   - locked <0x00060ceef588> (a 
> org.apache.james.core.MimeMessageWrapper)
>   at 
> org.apache.james.mailrepository.file.FileMailRepository.internalStore(FileMailRepository.java:203)
>   at 
> org.apache.james.mailrepository.lib.AbstractMailRepository.store(AbstractMailRepository.java:98)
>   at 
> org.apache.james.transport.mailets.ToRepository.service(ToRepository.java:91)
>   at 
> org.apache.james.mailetcontainer.impl.camel.CamelProcessor.process(CamelProcessor.java:65)
>   at 
> org.apache.camel.util.AsyncProcessorConverterHelper$ProcessorToAsyncProcessorBridge.process(AsyncProcessorConverterHelper.java:61)
>   at 
> org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHelper.java:73)
>   at 
> org.apache.camel.processor.DelegateAsyncProcessor.processNext(DelegateAsyncProcessor.java:99)
>   at 
> org.apache.camel.processor.DelegateAsyncProcessor.process(DelegateAsyncProcessor.java:90)
>   at 
> org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHelper.java:73)
>   at 
> org.apache.camel.processor.DelegateAsyncProcessor.processNext(DelegateAsyncProcessor.java:99)
>   at 
> org.apache.camel.processor.DelegateAsyncProcessor.process(DelegateAsyncProcessor.java:90)
>   at 
> org.apache.camel.management.InstrumentationProcessor.process(InstrumentationProcessor.java:73)
>   at 
> org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHelper.java:73)
>   at 
> org.apache.camel.processor.DelegateAsyncProcessor.processNext(DelegateAsyncProcessor.java:99)
>   at 
> org.apache.camel.processor.DelegateAsyncProcessor.process(DelegateAsyncProcessor.java:90)
>   at 
> org.apache.camel.processor.interceptor.TraceInterceptor.process(TraceInterceptor.java:91)
>   at 
> org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHelper.java:73)
>   at 
> org.apache.camel.processor.RedeliveryErrorHandler.processErrorHandler(RedeliveryErrorHandler.java:334)
>   at 
> org.apache.camel.processor.RedeliveryErrorHandler.process(RedeliveryErrorHandler.java:220)
>   at 
> org.apache.camel.processor.RouteContextProcessor.processNext(RouteContextProcessor.java:45)
>   at 
> org.apache.camel.processor.DelegateAsyncProcessor.process(DelegateAsyncProcessor.java:90)
>   at 
> org.apache.camel.processor.interceptor.DefaultChannel.process(DefaultChannel.java:303)
>   at 
> org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHelper.java:73)
>   at 
> org.apache.camel.processor.DelegateAsyncProcessor.processNext(DelegateAsyncProcessor.java:99)
>   at 
> org.apache.camel.processor.ChoiceProcessor.process(ChoiceProcessor.java:81)
>   at 
> org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHelper.java:73)
>   at 
> org.apache.camel.processor.DelegateAsyncProcessor.processNext(DelegateAsyncProcessor.java:99)
>   at 
> org.apache.camel.processor.Dele

[jira] [Commented] (JAMES-1593) James Spooler performance issue

[Matthieu Baechler (JIRA)]

[ 
https://issues.apache.org/jira/browse/JAMES-1593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14640052#comment-14640052
 ] 

Matthieu Baechler commented on JAMES-1593:
--

I agree James shouldn't use something broken by default. Can you provide us 
with a test case that triggers this bug ?

> James Spooler performance issue
> ---
>
> Key: JAMES-1593
> URL: https://issues.apache.org/jira/browse/JAMES-1593
> Project: James Server
>  Issue Type: Bug
>  Components: SMTPServer
>Affects Versions: 3.0-beta4
> Environment: Linux , CentOS release 6.6 (Final), 
>Reporter: Mehdi Salarkia
>  Labels: newbie, performance
>
> We have a mail system based on Apache james and we are experiencing some 
> performance issues .
> The current implementation of Apache james has a dependency on Apache 
> Geronimo for mime and mail processing and it seems there is an issue at-least 
>  in the version "geronimo-javamail_1.4_mail"  package .
> It seems like the "javax.mail.internet.MimeMessage.getEncoding()" method 
> never finishes and when I look at the cpu and I profiled the application it 
> shows this method has a high cpu consumtion, here is a jstack of what was 
> happening at the time:
> "spooler-1" daemon prio=10 tid=0x2b3ee9a5 nid=0x57b4 runnable 
> [0x2b3e8388d000]
>java.lang.Thread.State: RUNNABLE
>   at javax.mail.internet.MimeMessage.getEncoding(MimeMessage.java:751)
>   at 
> org.apache.james.core.MimeMessageUtil.writeMessageBodyTo(MimeMessageUtil.java:135)
>   at 
> org.apache.james.core.MimeMessageWrapper.writeTo(MimeMessageWrapper.java:338)
>   - locked <0x00060ceef588> (a 
> org.apache.james.core.MimeMessageWrapper)
>   at 
> org.apache.james.mailrepository.file.FileMailRepository.internalStore(FileMailRepository.java:203)
>   at 
> org.apache.james.mailrepository.lib.AbstractMailRepository.store(AbstractMailRepository.java:98)
>   at 
> org.apache.james.transport.mailets.ToRepository.service(ToRepository.java:91)
>   at 
> org.apache.james.mailetcontainer.impl.camel.CamelProcessor.process(CamelProcessor.java:65)
>   at 
> org.apache.camel.util.AsyncProcessorConverterHelper$ProcessorToAsyncProcessorBridge.process(AsyncProcessorConverterHelper.java:61)
>   at 
> org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHelper.java:73)
>   at 
> org.apache.camel.processor.DelegateAsyncProcessor.processNext(DelegateAsyncProcessor.java:99)
>   at 
> org.apache.camel.processor.DelegateAsyncProcessor.process(DelegateAsyncProcessor.java:90)
>   at 
> org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHelper.java:73)
>   at 
> org.apache.camel.processor.DelegateAsyncProcessor.processNext(DelegateAsyncProcessor.java:99)
>   at 
> org.apache.camel.processor.DelegateAsyncProcessor.process(DelegateAsyncProcessor.java:90)
>   at 
> org.apache.camel.management.InstrumentationProcessor.process(InstrumentationProcessor.java:73)
>   at 
> org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHelper.java:73)
>   at 
> org.apache.camel.processor.DelegateAsyncProcessor.processNext(DelegateAsyncProcessor.java:99)
>   at 
> org.apache.camel.processor.DelegateAsyncProcessor.process(DelegateAsyncProcessor.java:90)
>   at 
> org.apache.camel.processor.interceptor.TraceInterceptor.process(TraceInterceptor.java:91)
>   at 
> org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHelper.java:73)
>   at 
> org.apache.camel.processor.RedeliveryErrorHandler.processErrorHandler(RedeliveryErrorHandler.java:334)
>   at 
> org.apache.camel.processor.RedeliveryErrorHandler.process(RedeliveryErrorHandler.java:220)
>   at 
> org.apache.camel.processor.RouteContextProcessor.processNext(RouteContextProcessor.java:45)
>   at 
> org.apache.camel.processor.DelegateAsyncProcessor.process(DelegateAsyncProcessor.java:90)
>   at 
> org.apache.camel.processor.interceptor.DefaultChannel.process(DefaultChannel.java:303)
>   at 
> org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHelper.java:73)
>   at 
> org.apache.camel.processor.DelegateAsyncProcessor.processNext(DelegateAsyncProcessor.java:99)
>   at 
> org.apache.camel.processor.ChoiceProcessor.process(ChoiceProcessor.java:81)
>   at 
> org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHelper.java:73)
>   at 
> org.apache.camel.processor.DelegateAsyncProcessor.processNext(DelegateAsyncProcessor.java:99)
>   at 
> org.apache.camel.processor.DelegateAsyncProcessor.process(DelegateAsyncProcessor.java:90)
>   at 
> org.apache.camel.management.InstrumentationProcessor.process(InstrumentationProcessor.java:73)
>   at 
> org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcess

[jira] [Commented] (JAMES-1586) Write a compliant Cassandra User Repository

[Matthieu Baechler (JIRA)]

[ 
https://issues.apache.org/jira/browse/JAMES-1586?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14652288#comment-14652288
 ] 

Matthieu Baechler commented on JAMES-1586:
--

Hi Eric,

My old  https://github.com/mbaechler/james/commits/cassandra branch contains 
user/domain/rtt storage in cassandra and ends with an unrelated guice commit. 
It's a just a base for JAMES-1586 and JAMES-1587
You can have a look at what we done here : 
https://github.com/linagora/james/pull/4.
It's not pushed to Apache repository yet because we have to clean up our 
branches and open new PRs.

About reusing mailbox cassandra infrastructure, it actually JAMES-1588 : we 
need to share the cassandra session between repositories, reuse the table 
creation code and that kind of tools. Nothing in the "cassandra backend" 
project contains any business logic, just technical stuff.

Do you think it's ok ?

> Write a compliant Cassandra User Repository
> ---
>
> Key: JAMES-1586
> URL: https://issues.apache.org/jira/browse/JAMES-1586
> Project: James Server
>  Issue Type: New Feature
>Reporter: Matthieu Baechler
>
> To complete the Cassandra backend, we should write a User Repository on top 
> of Cassandra.
> There's already some code there : 
> https://github.com/mbaechler/james/commits/cassandra but it can't be 
> integrated as is, it needs some refactoring to use mailbox Cassandra 
> infrastructure.
> Once done, we should update the spring configuration to deploy this 
> repository and make sure integration tests on a deployed james still works.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

[jira] [Commented] (JAMES-1588) Create a project to centralize Cassandra tools

[Matthieu Baechler (JIRA)]

[ 
https://issues.apache.org/jira/browse/JAMES-1588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14653259#comment-14653259
 ] 

Matthieu Baechler commented on JAMES-1588:
--

In Cassandra case, it's technical things like : cassandra java driver, 
extensions to this driver, libraries we use to write tests (like cassandra-unit 
that allows to start an embedded cassandra using a JUnit @Rule), Session 
factory and tables creation tools.

> Create a project to centralize Cassandra tools
> --
>
> Key: JAMES-1588
> URL: https://issues.apache.org/jira/browse/JAMES-1588
> Project: James Server
>  Issue Type: Improvement
>Reporter: Tellier Benoit
>
> As we are starting to develop data tools based on Cassandra, we realized we 
> would use tools we defined for the Cassandra mailbox. But :
>  - We don't want a dependency to the cassandra mailbox in our data-cassandra 
> module
>  - We do not want to duplicate information.
> Hence we prefer introducing a new module, that centralize tools needed by 
> modules relying on Cassandra ( for now the Cassandra mailbox, and the 
> data-cassandra module, Cassandra MPT module ).
> As we think this can be a common need to several backend implementation, we 
> want to create a dedicated project for centralizing back-end tools, that will 
> be calles james-backends. Each back-end ( eg : cassandra, jpa, hbase, etc ... 
> ) will create its submodule in it and will use it in other places (MPT, 
> Mailbox, james (server) ).
> Let us now if you have any feedback on this proposal.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

[jira] [Commented] (JAMES-1588) Create a project to centralize Cassandra tools

[Matthieu Baechler (JIRA)]

[ 
https://issues.apache.org/jira/browse/JAMES-1588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14653268#comment-14653268
 ] 

Matthieu Baechler commented on JAMES-1588:
--

> Are you thinking to put this backends module at the same level as server, 
> mailbox...?

Exactly

> I proposed the same kind of module some time ago, but we decided to not 
> follow that way. Looking back , it sound like this would not have been the 
> best thing to do (release management...).

You are right one this point : it makes building James even more difficult. But 
duplicating libraries doesn't seems a good idea neither.

> The other way would be to merge all james modules in one structure to make a 
> single release. This may be worth to start a discussion on the maliling list.

Thank you very much to bring this subject to discussion : we are struggling for 
months to find a good workflow to work on James. The split repositories is a 
hell to manage, you can see our james-parent repository 
(https://github.com/linagora/james-parent) where we aggregate git repositories 
with git submodule. But everything is much harder that way and if we start a 
discussion on the mailing list about repositories merge, I will be happy to 
push my arguments there.

> Create a project to centralize Cassandra tools
> --
>
> Key: JAMES-1588
> URL: https://issues.apache.org/jira/browse/JAMES-1588
> Project: James Server
>  Issue Type: Improvement
>Reporter: Tellier Benoit
>
> As we are starting to develop data tools based on Cassandra, we realized we 
> would use tools we defined for the Cassandra mailbox. But :
>  - We don't want a dependency to the cassandra mailbox in our data-cassandra 
> module
>  - We do not want to duplicate information.
> Hence we prefer introducing a new module, that centralize tools needed by 
> modules relying on Cassandra ( for now the Cassandra mailbox, and the 
> data-cassandra module, Cassandra MPT module ).
> As we think this can be a common need to several backend implementation, we 
> want to create a dedicated project for centralizing back-end tools, that will 
> be calles james-backends. Each back-end ( eg : cassandra, jpa, hbase, etc ... 
> ) will create its submodule in it and will use it in other places (MPT, 
> Mailbox, james (server) ).
> Let us now if you have any feedback on this proposal.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

[jira] [Created] (JAMES-1603) cli should not depend on james-server-spring

[Matthieu Baechler (JIRA)]

Matthieu Baechler created JAMES-1603:


 Summary: cli should not depend on james-server-spring
 Key: JAMES-1603
 URL: https://issues.apache.org/jira/browse/JAMES-1603
 Project: James Server
  Issue Type: Bug
  Components: CLI
Reporter: Matthieu Baechler


cli depends on james-server-spring to access MailboxCopierManagementMBean 
interface.

It's probably a simple mistake to fix, MBeans are usually into data-api module, 
we should have to move MailboxCopierManagementMBean to data-api too.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

[jira] [Created] (JAMES-1605) AbstractRecipientRewriteTable.mapAddress doesn't respect domainAlias ordering

[Matthieu Baechler (JIRA)]

Matthieu Baechler created JAMES-1605:


 Summary: AbstractRecipientRewriteTable.mapAddress doesn't respect 
domainAlias ordering
 Key: JAMES-1605
 URL: https://issues.apache.org/jira/browse/JAMES-1605
 Project: James Server
  Issue Type: Bug
Reporter: Matthieu Baechler


This code snippet seems to tries to putting aliasdomain entries in front of the 
list while keeping entries original order.
 
{code}
 while (mapIt.hasNext()) {
int i = 0;
String mapping = mapIt.next();

if 
(mapping.startsWith(RecipientRewriteTable.ALIASDOMAIN_PREFIX)) {
col.add(i, mapping);
i++;
} else {
col.add(mapping);
}
}
{code}

I looks like no test covers this feature because it actually mess with 
aliasdomain ordering (the 'i' counter is reset for every loop)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

[jira] [Created] (MAILBOX-247) Mailbox doesn't build with Java 6 because of elasticsearch module

[Matthieu Baechler (JIRA)]

Matthieu Baechler created MAILBOX-247:
-

 Summary: Mailbox doesn't build with Java 6 because of 
elasticsearch module
 Key: MAILBOX-247
 URL: https://issues.apache.org/jira/browse/MAILBOX-247
 Project: James Mailbox
  Issue Type: Bug
Reporter: Matthieu Baechler


elasticsearch module makes mailbox modules build fail because it depends on 
tika and tika is not built under Java 6.
elasticsearch module should not depend on tika if java < 1.8



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

[jira] [Created] (MPT-22) Some modules don't compile under java 6 because of required dependencies

[Matthieu Baechler (JIRA)]

Matthieu Baechler created MPT-22:


 Summary: Some modules don't compile under java 6 because of 
required dependencies
 Key: MPT-22
 URL: https://issues.apache.org/jira/browse/MPT-22
 Project: James MPT
  Issue Type: Bug
Reporter: Matthieu Baechler


Same issue as https://issues.apache.org/jira/browse/MAILBOX-247 but for mpt 
modules.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

[jira] [Created] (JAMES-1607) Make MailboxCopierManagementMBean spring-independent

[Matthieu Baechler (JIRA)]

Matthieu Baechler created JAMES-1607:


 Summary: Make MailboxCopierManagementMBean spring-independent
 Key: JAMES-1607
 URL: https://issues.apache.org/jira/browse/JAMES-1607
 Project: James Server
  Issue Type: Improvement
  Components: JMX
Reporter: Matthieu Baechler


MailboxCopierManagementMBean features are very handy and should not have a hard 
dependency on spring.
We could define a "BeanResolver" interface to allow some other injection 
framework to provide it.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

[jira] [Resolved] (MPT-22) Some modules don't compile under java 6 because of required dependencies

[Matthieu Baechler (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MPT-22?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Matthieu Baechler resolved MPT-22.
--
Resolution: Fixed

merged on trunk

> Some modules don't compile under java 6 because of required dependencies
> 
>
> Key: MPT-22
> URL: https://issues.apache.org/jira/browse/MPT-22
> Project: James MPT
>  Issue Type: Bug
>Reporter: Matthieu Baechler
>
> Same issue as https://issues.apache.org/jira/browse/MAILBOX-247 but for mpt 
> modules.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

[jira] [Resolved] (MAILBOX-247) Mailbox doesn't build with Java 6 because of elasticsearch module

[Matthieu Baechler (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MAILBOX-247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Matthieu Baechler resolved MAILBOX-247.
---
Resolution: Fixed

Merged on trunk

> Mailbox doesn't build with Java 6 because of elasticsearch module
> -
>
> Key: MAILBOX-247
> URL: https://issues.apache.org/jira/browse/MAILBOX-247
> Project: James Mailbox
>  Issue Type: Bug
>Reporter: Matthieu Baechler
>
> elasticsearch module makes mailbox modules build fail because it depends on 
> tika and tika is not built under Java 6.
> elasticsearch module should not depend on tika if java < 1.8



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

[jira] [Created] (JAMES-1610) CLI usage doesn't output command names

[Matthieu Baechler (JIRA)]

Matthieu Baechler created JAMES-1610:


 Summary: CLI usage doesn't output command names
 Key: JAMES-1610
 URL: https://issues.apache.org/jira/browse/JAMES-1610
 Project: James Server
  Issue Type: Bug
  Components: CLI
Reporter: Matthieu Baechler


Current output :
{code}
usage: java org.apache.james.cli.ServerCmd --host  

 -h,--hostnode hostname or ip address
 -p,--portremote jmx agent port number
  




 
  
  
  
  
 
 

  

  
{code}

Should be : 
{code}
usage: java org.apache.james.cli.ServerCmd --host  

 -h,--hostnode hostname or ip address
 -p,--portremote jmx agent port number
adduser  
removeuser 
listusers
adddomain 
removedomain 
containsdomain 
listdomains
listmappings
listuserdomainmappings  
addaddressmapping   
removeaddressmapping   
addregexmapping   
removeregexmapping   
setpassword  
copymailbox  
deleteusermailboxes 
createmailbox   
listusermailboxes 
deletemailbox   
{code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

[jira] [Resolved] (JAMES-1610) CLI usage doesn't output command names

[Matthieu Baechler (JIRA)]

 [ 
https://issues.apache.org/jira/browse/JAMES-1610?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Matthieu Baechler resolved JAMES-1610.
--
Resolution: Fixed

merged by benoit

> CLI usage doesn't output command names
> --
>
> Key: JAMES-1610
> URL: https://issues.apache.org/jira/browse/JAMES-1610
> Project: James Server
>  Issue Type: Bug
>  Components: CLI
>Reporter: Matthieu Baechler
>
> Current output :
> {code}
> usage: java org.apache.james.cli.ServerCmd --host  
> 
>  -h,--hostnode hostname or ip address
>  -p,--portremote jmx agent port number
>   
> 
> 
> 
> 
>  
>   
>   
>   
>   
>  
>  
> 
>   
> 
>   
> {code}
> Should be : 
> {code}
> usage: java org.apache.james.cli.ServerCmd --host  
> 
>  -h,--hostnode hostname or ip address
>  -p,--portremote jmx agent port number
> adduser  
> removeuser 
> listusers
> adddomain 
> removedomain 
> containsdomain 
> listdomains
> listmappings
> listuserdomainmappings  
> addaddressmapping   
> removeaddressmapping   
> addregexmapping   
> removeregexmapping   
> setpassword  
> copymailbox  
> deleteusermailboxes 
> createmailbox   
> listusermailboxes 
> deletemailbox   
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

[jira] [Commented] (JAMES-1603) cli should not depend on james-server-spring

[Matthieu Baechler (JIRA)]

[ 
https://issues.apache.org/jira/browse/JAMES-1603?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14790521#comment-14790521
 ] 

Matthieu Baechler commented on JAMES-1603:
--

Can someone merge this PR please (or comment it, of course) ?

> cli should not depend on james-server-spring
> 
>
> Key: JAMES-1603
> URL: https://issues.apache.org/jira/browse/JAMES-1603
> Project: James Server
>  Issue Type: Bug
>  Components: CLI
>Reporter: Matthieu Baechler
>
> cli depends on james-server-spring to access MailboxCopierManagementMBean 
> interface.
> It's probably a simple mistake to fix, MBeans are usually into data-api 
> module, we should have to move MailboxCopierManagementMBean to data-api too.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

[jira] [Resolved] (JAMES-1603) cli should not depend on james-server-spring

[Matthieu Baechler (JIRA)]

 [ 
https://issues.apache.org/jira/browse/JAMES-1603?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Matthieu Baechler resolved JAMES-1603.
--
Resolution: Fixed

merged

> cli should not depend on james-server-spring
> 
>
> Key: JAMES-1603
> URL: https://issues.apache.org/jira/browse/JAMES-1603
> Project: James Server
>  Issue Type: Bug
>  Components: CLI
>Reporter: Matthieu Baechler
>
> cli depends on james-server-spring to access MailboxCopierManagementMBean 
> interface.
> It's probably a simple mistake to fix, MBeans are usually into data-api 
> module, we should have to move MailboxCopierManagementMBean to data-api too.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

[jira] [Commented] (JAMES-1607) Make MailboxCopierManagementMBean spring-independent

[Matthieu Baechler (JIRA)]

[ 
https://issues.apache.org/jira/browse/JAMES-1607?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14791689#comment-14791689
 ] 

Matthieu Baechler commented on JAMES-1607:
--

be careful, this PR comes with https://github.com/apache/james/pull/5

> Make MailboxCopierManagementMBean spring-independent
> 
>
> Key: JAMES-1607
> URL: https://issues.apache.org/jira/browse/JAMES-1607
> Project: James Server
>  Issue Type: Improvement
>  Components: JMX
>Reporter: Matthieu Baechler
>
> MailboxCopierManagementMBean features are very handy and should not have a 
> hard dependency on spring.
> We could define a "BeanResolver" interface to allow some other injection 
> framework to provide it.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

[jira] [Updated] (JAMES-1593) James Spooler performance issue

[Matthieu Baechler (JIRA)]

 [ 
https://issues.apache.org/jira/browse/JAMES-1593?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Matthieu Baechler updated JAMES-1593:
-
Attachment: 0001-JAMES-1593-unit-test-to-show-geronimo-bug.patch

This test case show the broken geronimo behavior

> James Spooler performance issue
> ---
>
> Key: JAMES-1593
> URL: https://issues.apache.org/jira/browse/JAMES-1593
> Project: James Server
>  Issue Type: Bug
>  Components: SMTPServer
>Affects Versions: 3.0-beta4
> Environment: Linux , CentOS release 6.6 (Final), 
>Reporter: Mehdi Salarkia
>  Labels: newbie, performance
> Attachments: 0001-JAMES-1593-unit-test-to-show-geronimo-bug.patch, 
> problem_1.eml
>
>
> We have a mail system based on Apache james and we are experiencing some 
> performance issues .
> The current implementation of Apache james has a dependency on Apache 
> Geronimo for mime and mail processing and it seems there is an issue at-least 
>  in the version "geronimo-javamail_1.4_mail"  package .
> It seems like the "javax.mail.internet.MimeMessage.getEncoding()" method 
> never finishes and when I look at the cpu and I profiled the application it 
> shows this method has a high cpu consumtion, here is a jstack of what was 
> happening at the time:
> "spooler-1" daemon prio=10 tid=0x2b3ee9a5 nid=0x57b4 runnable 
> [0x2b3e8388d000]
>java.lang.Thread.State: RUNNABLE
>   at javax.mail.internet.MimeMessage.getEncoding(MimeMessage.java:751)
>   at 
> org.apache.james.core.MimeMessageUtil.writeMessageBodyTo(MimeMessageUtil.java:135)
>   at 
> org.apache.james.core.MimeMessageWrapper.writeTo(MimeMessageWrapper.java:338)
>   - locked <0x00060ceef588> (a 
> org.apache.james.core.MimeMessageWrapper)
>   at 
> org.apache.james.mailrepository.file.FileMailRepository.internalStore(FileMailRepository.java:203)
>   at 
> org.apache.james.mailrepository.lib.AbstractMailRepository.store(AbstractMailRepository.java:98)
>   at 
> org.apache.james.transport.mailets.ToRepository.service(ToRepository.java:91)
>   at 
> org.apache.james.mailetcontainer.impl.camel.CamelProcessor.process(CamelProcessor.java:65)
>   at 
> org.apache.camel.util.AsyncProcessorConverterHelper$ProcessorToAsyncProcessorBridge.process(AsyncProcessorConverterHelper.java:61)
>   at 
> org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHelper.java:73)
>   at 
> org.apache.camel.processor.DelegateAsyncProcessor.processNext(DelegateAsyncProcessor.java:99)
>   at 
> org.apache.camel.processor.DelegateAsyncProcessor.process(DelegateAsyncProcessor.java:90)
>   at 
> org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHelper.java:73)
>   at 
> org.apache.camel.processor.DelegateAsyncProcessor.processNext(DelegateAsyncProcessor.java:99)
>   at 
> org.apache.camel.processor.DelegateAsyncProcessor.process(DelegateAsyncProcessor.java:90)
>   at 
> org.apache.camel.management.InstrumentationProcessor.process(InstrumentationProcessor.java:73)
>   at 
> org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHelper.java:73)
>   at 
> org.apache.camel.processor.DelegateAsyncProcessor.processNext(DelegateAsyncProcessor.java:99)
>   at 
> org.apache.camel.processor.DelegateAsyncProcessor.process(DelegateAsyncProcessor.java:90)
>   at 
> org.apache.camel.processor.interceptor.TraceInterceptor.process(TraceInterceptor.java:91)
>   at 
> org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHelper.java:73)
>   at 
> org.apache.camel.processor.RedeliveryErrorHandler.processErrorHandler(RedeliveryErrorHandler.java:334)
>   at 
> org.apache.camel.processor.RedeliveryErrorHandler.process(RedeliveryErrorHandler.java:220)
>   at 
> org.apache.camel.processor.RouteContextProcessor.processNext(RouteContextProcessor.java:45)
>   at 
> org.apache.camel.processor.DelegateAsyncProcessor.process(DelegateAsyncProcessor.java:90)
>   at 
> org.apache.camel.processor.interceptor.DefaultChannel.process(DefaultChannel.java:303)
>   at 
> org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHelper.java:73)
>   at 
> org.apache.camel.processor.DelegateAsyncProcessor.processNext(DelegateAsyncProcessor.java:99)
>   at 
> org.apache.camel.processor.ChoiceProcessor.process(ChoiceProcessor.java:81)
>   at 
> org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHelper.java:73)
>   at 
> org.apache.camel.processor.DelegateAsyncProcessor.processNext(DelegateAsyncProcessor.java:99)
>   at 
> org.apache.camel.processor.DelegateAsyncProcessor.process(DelegateAsyncProcessor.java:90)
>   at 
> org.apache.camel.management.InstrumentationProcessor.process(InstrumentationProcessor.java:73)
>   at 
> org.apache.camel.util.Asy

[jira] [Commented] (JAMES-1593) James Spooler performance issue

[Matthieu Baechler (JIRA)]

[ 
https://issues.apache.org/jira/browse/JAMES-1593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14791823#comment-14791823
 ] 

Matthieu Baechler commented on JAMES-1593:
--

Unfortunately, switching to oracle javamail implementation (even upgrading to 
1.5.4) breaks an existing test (see git commit 
51d652939828bafd6dcb724d89c8bf9348a2137c )

I think we have to choose between :
1. fix geronimo
2. use oracle javamail and change to failing test (that seems less important 
than an infinite locking)

Someone has another idea ?

> James Spooler performance issue
> ---
>
> Key: JAMES-1593
> URL: https://issues.apache.org/jira/browse/JAMES-1593
> Project: James Server
>  Issue Type: Bug
>  Components: SMTPServer
>Affects Versions: 3.0-beta4
> Environment: Linux , CentOS release 6.6 (Final), 
>Reporter: Mehdi Salarkia
>  Labels: newbie, performance
> Attachments: 0001-JAMES-1593-unit-test-to-show-geronimo-bug.patch, 
> problem_1.eml
>
>
> We have a mail system based on Apache james and we are experiencing some 
> performance issues .
> The current implementation of Apache james has a dependency on Apache 
> Geronimo for mime and mail processing and it seems there is an issue at-least 
>  in the version "geronimo-javamail_1.4_mail"  package .
> It seems like the "javax.mail.internet.MimeMessage.getEncoding()" method 
> never finishes and when I look at the cpu and I profiled the application it 
> shows this method has a high cpu consumtion, here is a jstack of what was 
> happening at the time:
> "spooler-1" daemon prio=10 tid=0x2b3ee9a5 nid=0x57b4 runnable 
> [0x2b3e8388d000]
>java.lang.Thread.State: RUNNABLE
>   at javax.mail.internet.MimeMessage.getEncoding(MimeMessage.java:751)
>   at 
> org.apache.james.core.MimeMessageUtil.writeMessageBodyTo(MimeMessageUtil.java:135)
>   at 
> org.apache.james.core.MimeMessageWrapper.writeTo(MimeMessageWrapper.java:338)
>   - locked <0x00060ceef588> (a 
> org.apache.james.core.MimeMessageWrapper)
>   at 
> org.apache.james.mailrepository.file.FileMailRepository.internalStore(FileMailRepository.java:203)
>   at 
> org.apache.james.mailrepository.lib.AbstractMailRepository.store(AbstractMailRepository.java:98)
>   at 
> org.apache.james.transport.mailets.ToRepository.service(ToRepository.java:91)
>   at 
> org.apache.james.mailetcontainer.impl.camel.CamelProcessor.process(CamelProcessor.java:65)
>   at 
> org.apache.camel.util.AsyncProcessorConverterHelper$ProcessorToAsyncProcessorBridge.process(AsyncProcessorConverterHelper.java:61)
>   at 
> org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHelper.java:73)
>   at 
> org.apache.camel.processor.DelegateAsyncProcessor.processNext(DelegateAsyncProcessor.java:99)
>   at 
> org.apache.camel.processor.DelegateAsyncProcessor.process(DelegateAsyncProcessor.java:90)
>   at 
> org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHelper.java:73)
>   at 
> org.apache.camel.processor.DelegateAsyncProcessor.processNext(DelegateAsyncProcessor.java:99)
>   at 
> org.apache.camel.processor.DelegateAsyncProcessor.process(DelegateAsyncProcessor.java:90)
>   at 
> org.apache.camel.management.InstrumentationProcessor.process(InstrumentationProcessor.java:73)
>   at 
> org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHelper.java:73)
>   at 
> org.apache.camel.processor.DelegateAsyncProcessor.processNext(DelegateAsyncProcessor.java:99)
>   at 
> org.apache.camel.processor.DelegateAsyncProcessor.process(DelegateAsyncProcessor.java:90)
>   at 
> org.apache.camel.processor.interceptor.TraceInterceptor.process(TraceInterceptor.java:91)
>   at 
> org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHelper.java:73)
>   at 
> org.apache.camel.processor.RedeliveryErrorHandler.processErrorHandler(RedeliveryErrorHandler.java:334)
>   at 
> org.apache.camel.processor.RedeliveryErrorHandler.process(RedeliveryErrorHandler.java:220)
>   at 
> org.apache.camel.processor.RouteContextProcessor.processNext(RouteContextProcessor.java:45)
>   at 
> org.apache.camel.processor.DelegateAsyncProcessor.process(DelegateAsyncProcessor.java:90)
>   at 
> org.apache.camel.processor.interceptor.DefaultChannel.process(DefaultChannel.java:303)
>   at 
> org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHelper.java:73)
>   at 
> org.apache.camel.processor.DelegateAsyncProcessor.processNext(DelegateAsyncProcessor.java:99)
>   at 
> org.apache.camel.processor.ChoiceProcessor.process(ChoiceProcessor.java:81)
>   at 
> org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHelper.java:73)
>   at 
> org.apache.camel.processor.DelegateAsyncProcessor.pr

[jira] [Created] (MAILBOX-248) The source code should not issue any warning

[Matthieu Baechler (JIRA)]

Matthieu Baechler created MAILBOX-248:
-

 Summary: The source code should not issue any warning
 Key: MAILBOX-248
 URL: https://issues.apache.org/jira/browse/MAILBOX-248
 Project: James Mailbox
  Issue Type: Improvement
Reporter: Matthieu Baechler


A great way to be productive with our IDEs is to fix all warnings. That way, we 
can easily detect newly introduced warning that could be real bugs and fix them 
immediately.

I propose to fix all warning that I find in eclipse as a first step.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

[jira] [Commented] (JAMES-1607) Make MailboxCopierManagementMBean spring-independent

[Matthieu Baechler (JIRA)]

[ 
https://issues.apache.org/jira/browse/JAMES-1607?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14805152#comment-14805152
 ] 

Matthieu Baechler commented on JAMES-1607:
--

anybody to comment and/or merge this PR ?

> Make MailboxCopierManagementMBean spring-independent
> 
>
> Key: JAMES-1607
> URL: https://issues.apache.org/jira/browse/JAMES-1607
> Project: James Server
>  Issue Type: Improvement
>  Components: JMX
>Reporter: Matthieu Baechler
>
> MailboxCopierManagementMBean features are very handy and should not have a 
> hard dependency on spring.
> We could define a "BeanResolver" interface to allow some other injection 
> framework to provide it.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

[jira] [Commented] (MAILBOX-248) The source code should not issue any warning

[Matthieu Baechler (JIRA)]

[ 
https://issues.apache.org/jira/browse/MAILBOX-248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14805155#comment-14805155
 ] 

Matthieu Baechler commented on MAILBOX-248:
---

I opened a PR here for a first batch of fixes : 
https://github.com/apache/james-mailbox/pull/11

> The source code should not issue any warning
> 
>
> Key: MAILBOX-248
> URL: https://issues.apache.org/jira/browse/MAILBOX-248
> Project: James Mailbox
>  Issue Type: Improvement
>Reporter: Matthieu Baechler
>
> A great way to be productive with our IDEs is to fix all warnings. That way, 
> we can easily detect newly introduced warning that could be real bugs and fix 
> them immediately.
> I propose to fix all warning that I find in eclipse as a first step.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

[jira] [Created] (JAMES-1611) site points to a deprecated Nightly Build repository

[Matthieu Baechler (JIRA)]

Matthieu Baechler created JAMES-1611:


 Summary: site points to a deprecated Nightly Build repository
 Key: JAMES-1611
 URL: https://issues.apache.org/jira/browse/JAMES-1611
 Project: James Server
  Issue Type: Bug
  Components: Documentation
Affects Versions: Trunk
Reporter: Matthieu Baechler


There is a "Nightly Build" link that go to 
https://repository.apache.org/content/repositories/snapshots/org/apache/james/apache-james/
 put this repository has not been updated since 2012.

I suggest to remove this link.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

[jira] [Created] (JAMES-1612) dev-build documentation is not consistent wrt beta4

[Matthieu Baechler (JIRA)]

Matthieu Baechler created JAMES-1612:


 Summary: dev-build documentation is not consistent wrt beta4
 Key: JAMES-1612
 URL: https://issues.apache.org/jira/browse/JAMES-1612
 Project: James Server
  Issue Type: Bug
  Components: Documentation
Affects Versions: Trunk
Reporter: Matthieu Baechler


dev-build defines three different things for  JAMES_SRC_HOME :

1.  source distribution : it's an almost empty shell that just downloads 
everything from maven central
2.  http://svn.apache.org/repos/asf/james/server/tags/james-server-3.0-beta4/ 
checks out the server sources
3. http://svn.apache.org/repos/asf/james/current checks out every james modules

I suggest to change this to http://svn.apache.org/repos/asf/james/current 
content for the 3 ways and to tag http://svn.apache.org/repos/asf/james/current 
on releases.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

[jira] [Created] (JAMES-1613) Document needs some updates

[Matthieu Baechler (JIRA)]

Matthieu Baechler created JAMES-1613:


 Summary: Document needs some updates
 Key: JAMES-1613
 URL: https://issues.apache.org/jira/browse/JAMES-1613
 Project: James Server
  Issue Type: Bug
  Components: Documentation
Affects Versions: Trunk
Reporter: Matthieu Baechler


The website has some consistency problems and typos that could be fixed.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

[jira] [Closed] (JAMES-1607) Make MailboxCopierManagementMBean spring-independent

[Matthieu Baechler (JIRA)]

 [ 
https://issues.apache.org/jira/browse/JAMES-1607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Matthieu Baechler closed JAMES-1607.

Resolution: Fixed

merged

> Make MailboxCopierManagementMBean spring-independent
> 
>
> Key: JAMES-1607
> URL: https://issues.apache.org/jira/browse/JAMES-1607
> Project: James Server
>  Issue Type: Improvement
>  Components: JMX
>Reporter: Matthieu Baechler
>
> MailboxCopierManagementMBean features are very handy and should not have a 
> hard dependency on spring.
> We could define a "BeanResolver" interface to allow some other injection 
> framework to provide it.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

[jira] [Created] (JAMES-1621) James server modules merge

[Matthieu Baechler (JIRA)]

Matthieu Baechler created JAMES-1621:


 Summary: James server modules merge
 Key: JAMES-1621
 URL: https://issues.apache.org/jira/browse/JAMES-1621
 Project: James Server
  Issue Type: Task
Reporter: Matthieu Baechler


We should get the following tree into james-project module :

james-project
| server
| mailbox
| mailet
| mpt
| protocols

If you agree, we should do :

in https://svn.apache.org/repos/asf/james/project/trunk :

svn mv http://svn.apache.org/repos/asf/james/server server
svn mv http://svn.apache.org/repos/asf/james/mailbox mailbox
svn mv http://svn.apache.org/repos/asf/james/mailet mailet
svn mv http://svn.apache.org/repos/asf/james/mpt mpt
svn mv http://svn.apache.org/repos/asf/james/protocols protocols

I chose "svn mv" to prevent confusion about where are modules actual trunk 
located.

Then we have to update http://svn.apache.org/repos/asf/james/current 
accordingly with the following command :

svn propset svn:externals http://svn.apache.org/repos/asf/james/current
hupa https://svn.apache.org/repos/asf/james/hupa/trunk
jdkim https://svn.apache.org/repos/asf/james/jdkim/trunk
jspf https://svn.apache.org/repos/asf/james/jspf/trunk
mime4j https://svn.apache.org/repos/asf/james/mime4j/trunk
postage https://svn.apache.org/repos/asf/james/postage/trunk
jsieve https://svn.apache.org/repos/asf/james/jsieve/trunk
project https://svn.apache.org/repos/asf/james/project/trunk
skin https://svn.apache.org/repos/asf/james/skin/trunk

Then, to update the documentation and the "project" pom, you have to apply the 
attached patches and finally commit all this.




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

[jira] [Updated] (JAMES-1621) James server modules merge

[Matthieu Baechler (JIRA)]

 [ 
https://issues.apache.org/jira/browse/JAMES-1621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Matthieu Baechler updated JAMES-1621:
-
Description: 
To get the following tree into james-project module :
{code}
james-project
| server
| mailbox
| mailet
| mpt
| protocols
{code}

do these commands in https://svn.apache.org/repos/asf/james/project/trunk :
{code}
svn mv http://svn.apache.org/repos/asf/james/server server
svn mv http://svn.apache.org/repos/asf/james/mailbox mailbox
svn mv http://svn.apache.org/repos/asf/james/mailet mailet
svn mv http://svn.apache.org/repos/asf/james/mpt mpt
svn mv http://svn.apache.org/repos/asf/james/protocols protocols
{code}

Then we have to update http://svn.apache.org/repos/asf/james/current 
svn:external property

{code}
svn propset svn:externals http://svn.apache.org/repos/asf/james/current
{code}

with the content :
{code}
hupa https://svn.apache.org/repos/asf/james/hupa/trunk
jdkim https://svn.apache.org/repos/asf/james/jdkim/trunk
jspf https://svn.apache.org/repos/asf/james/jspf/trunk
mime4j https://svn.apache.org/repos/asf/james/mime4j/trunk
postage https://svn.apache.org/repos/asf/james/postage/trunk
jsieve https://svn.apache.org/repos/asf/james/jsieve/trunk
project https://svn.apache.org/repos/asf/james/project/trunk
skin https://svn.apache.org/repos/asf/james/skin/trunk
{code}

Then, to update the documentation and the "project" pom, you have to apply the 
attached patches and finally commit all this.


  was:
We should get the following tree into james-project module :

james-project
| server
| mailbox
| mailet
| mpt
| protocols

If you agree, we should do :

in https://svn.apache.org/repos/asf/james/project/trunk :

svn mv http://svn.apache.org/repos/asf/james/server server
svn mv http://svn.apache.org/repos/asf/james/mailbox mailbox
svn mv http://svn.apache.org/repos/asf/james/mailet mailet
svn mv http://svn.apache.org/repos/asf/james/mpt mpt
svn mv http://svn.apache.org/repos/asf/james/protocols protocols

I chose "svn mv" to prevent confusion about where are modules actual trunk 
located.

Then we have to update http://svn.apache.org/repos/asf/james/current 
accordingly with the following command :

svn propset svn:externals http://svn.apache.org/repos/asf/james/current
hupa https://svn.apache.org/repos/asf/james/hupa/trunk
jdkim https://svn.apache.org/repos/asf/james/jdkim/trunk
jspf https://svn.apache.org/repos/asf/james/jspf/trunk
mime4j https://svn.apache.org/repos/asf/james/mime4j/trunk
postage https://svn.apache.org/repos/asf/james/postage/trunk
jsieve https://svn.apache.org/repos/asf/james/jsieve/trunk
project https://svn.apache.org/repos/asf/james/project/trunk
skin https://svn.apache.org/repos/asf/james/skin/trunk

Then, to update the documentation and the "project" pom, you have to apply the 
attached patches and finally commit all this.



> James server modules merge
> --
>
> Key: JAMES-1621
> URL: https://issues.apache.org/jira/browse/JAMES-1621
> Project: James Server
>  Issue Type: Task
>Reporter: Matthieu Baechler
>
> To get the following tree into james-project module :
> {code}
> james-project
> | server
> | mailbox
> | mailet
> | mpt
> | protocols
> {code}
> do these commands in https://svn.apache.org/repos/asf/james/project/trunk :
> {code}
> svn mv http://svn.apache.org/repos/asf/james/server server
> svn mv http://svn.apache.org/repos/asf/james/mailbox mailbox
> svn mv http://svn.apache.org/repos/asf/james/mailet mailet
> svn mv http://svn.apache.org/repos/asf/james/mpt mpt
> svn mv http://svn.apache.org/repos/asf/james/protocols protocols
> {code}
> Then we have to update http://svn.apache.org/repos/asf/james/current 
> svn:external property
> {code}
> svn propset svn:externals http://svn.apache.org/repos/asf/james/current
> {code}
> with the content :
> {code}
> hupa https://svn.apache.org/repos/asf/james/hupa/trunk
> jdkim https://svn.apache.org/repos/asf/james/jdkim/trunk
> jspf https://svn.apache.org/repos/asf/james/jspf/trunk
> mime4j https://svn.apache.org/repos/asf/james/mime4j/trunk
> postage https://svn.apache.org/repos/asf/james/postage/trunk
> jsieve https://svn.apache.org/repos/asf/james/jsieve/trunk
> project https://svn.apache.org/repos/asf/james/project/trunk
> skin https://svn.apache.org/repos/asf/james/skin/trunk
> {code}
> Then, to update the documentation and the "project" pom, you have to apply 
> the attached patches and finally commit all this.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

[jira] [Updated] (JAMES-1621) James server modules merge

[Matthieu Baechler (JIRA)]

 [ 
https://issues.apache.org/jira/browse/JAMES-1621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Matthieu Baechler updated JAMES-1621:
-
Attachment: current.patch

This patch apply to http://svn.apache.org/repos/asf/james/current

> James server modules merge
> --
>
> Key: JAMES-1621
> URL: https://issues.apache.org/jira/browse/JAMES-1621
> Project: James Server
>  Issue Type: Task
>Reporter: Matthieu Baechler
> Attachments: current.patch, mailbox.patch, mailet.patch, merge.patch, 
> protocols.patch, server.patch
>
>
> To get the following tree into james-project module :
> {code}
> james-project
> | server
> | mailbox
> | mailet
> | mpt
> | protocols
> {code}
> do these commands in https://svn.apache.org/repos/asf/james/project/trunk :
> {code}
> svn mv http://svn.apache.org/repos/asf/james/server server
> svn mv http://svn.apache.org/repos/asf/james/mailbox mailbox
> svn mv http://svn.apache.org/repos/asf/james/mailet mailet
> svn mv http://svn.apache.org/repos/asf/james/mpt mpt
> svn mv http://svn.apache.org/repos/asf/james/protocols protocols
> {code}
> Then we have to update http://svn.apache.org/repos/asf/james/current 
> svn:external property
> {code}
> svn propset svn:externals http://svn.apache.org/repos/asf/james/current
> {code}
> with the content :
> {code}
> hupa https://svn.apache.org/repos/asf/james/hupa/trunk
> jdkim https://svn.apache.org/repos/asf/james/jdkim/trunk
> jspf https://svn.apache.org/repos/asf/james/jspf/trunk
> mime4j https://svn.apache.org/repos/asf/james/mime4j/trunk
> postage https://svn.apache.org/repos/asf/james/postage/trunk
> jsieve https://svn.apache.org/repos/asf/james/jsieve/trunk
> project https://svn.apache.org/repos/asf/james/project/trunk
> skin https://svn.apache.org/repos/asf/james/skin/trunk
> {code}
> Then, to update the documentation and the "project" pom, you have to apply 
> the attached patches and finally commit all this.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

[jira] [Updated] (JAMES-1621) James server modules merge

[Matthieu Baechler (JIRA)]

 [ 
https://issues.apache.org/jira/browse/JAMES-1621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Matthieu Baechler updated JAMES-1621:
-
Attachment: merge.patch
protocols.patch
server.patch
mailbox.patch
mailet.patch

These patches apply to the merged tree.

> James server modules merge
> --
>
> Key: JAMES-1621
> URL: https://issues.apache.org/jira/browse/JAMES-1621
> Project: James Server
>  Issue Type: Task
>Reporter: Matthieu Baechler
> Attachments: current.patch, mailbox.patch, mailet.patch, merge.patch, 
> protocols.patch, server.patch
>
>
> To get the following tree into james-project module :
> {code}
> james-project
> | server
> | mailbox
> | mailet
> | mpt
> | protocols
> {code}
> do these commands in https://svn.apache.org/repos/asf/james/project/trunk :
> {code}
> svn mv http://svn.apache.org/repos/asf/james/server server
> svn mv http://svn.apache.org/repos/asf/james/mailbox mailbox
> svn mv http://svn.apache.org/repos/asf/james/mailet mailet
> svn mv http://svn.apache.org/repos/asf/james/mpt mpt
> svn mv http://svn.apache.org/repos/asf/james/protocols protocols
> {code}
> Then we have to update http://svn.apache.org/repos/asf/james/current 
> svn:external property
> {code}
> svn propset svn:externals http://svn.apache.org/repos/asf/james/current
> {code}
> with the content :
> {code}
> hupa https://svn.apache.org/repos/asf/james/hupa/trunk
> jdkim https://svn.apache.org/repos/asf/james/jdkim/trunk
> jspf https://svn.apache.org/repos/asf/james/jspf/trunk
> mime4j https://svn.apache.org/repos/asf/james/mime4j/trunk
> postage https://svn.apache.org/repos/asf/james/postage/trunk
> jsieve https://svn.apache.org/repos/asf/james/jsieve/trunk
> project https://svn.apache.org/repos/asf/james/project/trunk
> skin https://svn.apache.org/repos/asf/james/skin/trunk
> {code}
> Then, to update the documentation and the "project" pom, you have to apply 
> the attached patches and finally commit all this.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

[jira] [Commented] (JAMES-1613) Document needs some updates

[Matthieu Baechler (JIRA)]

[ 
https://issues.apache.org/jira/browse/JAMES-1613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14900616#comment-14900616
 ] 

Matthieu Baechler commented on JAMES-1613:
--

see https://github.com/apache/james/pull/6

> Document needs some updates
> ---
>
> Key: JAMES-1613
> URL: https://issues.apache.org/jira/browse/JAMES-1613
> Project: James Server
>  Issue Type: Bug
>  Components: Documentation
>Affects Versions: Trunk
>Reporter: Matthieu Baechler
>
> The website has some consistency problems and typos that could be fixed.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

[jira] [Commented] (JAMES-1609) JMX unregister of queues : some queues are ignored.

[Matthieu Baechler (JIRA)]

[ 
https://issues.apache.org/jira/browse/JAMES-1609?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14902158#comment-14902158
 ] 

Matthieu Baechler commented on JAMES-1609:
--

Can someone merge this PR : https://github.com/apache/james/pull/8 ?

> JMX unregister of queues : some queues are ignored.
> ---
>
> Key: JAMES-1609
> URL: https://issues.apache.org/jira/browse/JAMES-1609
> Project: James Server
>  Issue Type: Bug
>  Components: Queue
>Affects Versions: Trunk
>Reporter: Tellier Benoit
> Fix For: Trunk
>
>
> The @PreDestoy method called look like this :
> ```
> for ( String mbean : mbeans) {
> unregister(mbean);
> mbeans.remove(mbean);
> }
> ```
> Causing mbeans being ignored and not unregistered.
> Solution is to simply not modify collection content while working on it and 
> simply clear it outside the for loop.
> Acceptance criteria :
>  - Being able to launch a James server, stop it and restart it.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

[jira] [Commented] (JAMES-1613) Document needs some updates

[Matthieu Baechler (JIRA)]

[ 
https://issues.apache.org/jira/browse/JAMES-1613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14902160#comment-14902160
 ] 

Matthieu Baechler commented on JAMES-1613:
--

can someone merge this PR : https://github.com/apache/james/pull/6 ?

> Document needs some updates
> ---
>
> Key: JAMES-1613
> URL: https://issues.apache.org/jira/browse/JAMES-1613
> Project: James Server
>  Issue Type: Bug
>  Components: Documentation
>Affects Versions: Trunk
>Reporter: Matthieu Baechler
>
> The website has some consistency problems and typos that could be fixed.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

[jira] [Closed] (JAMES-1613) Document needs some updates

[Matthieu Baechler (JIRA)]

 [ 
https://issues.apache.org/jira/browse/JAMES-1613?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Matthieu Baechler closed JAMES-1613.

Resolution: Fixed

> Document needs some updates
> ---
>
> Key: JAMES-1613
> URL: https://issues.apache.org/jira/browse/JAMES-1613
> Project: James Server
>  Issue Type: Bug
>  Components: Documentation
>Affects Versions: Trunk
>Reporter: Matthieu Baechler
>
> The website has some consistency problems and typos that could be fixed.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

[jira] [Commented] (MAILBOX-248) The source code should not issue any warning

[Matthieu Baechler (JIRA)]

[ 
https://issues.apache.org/jira/browse/MAILBOX-248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14902451#comment-14902451
 ] 

Matthieu Baechler commented on MAILBOX-248:
---

There are some warning left. I keep this ticket open for next batch.


> The source code should not issue any warning
> 
>
> Key: MAILBOX-248
> URL: https://issues.apache.org/jira/browse/MAILBOX-248
> Project: James Mailbox
>  Issue Type: Improvement
>Reporter: Matthieu Baechler
>
> A great way to be productive with our IDEs is to fix all warnings. That way, 
> we can easily detect newly introduced warning that could be real bugs and fix 
> them immediately.
> I propose to fix all warning that I find in eclipse as a first step.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

[jira] [Commented] (JAMES-1611) site points to a deprecated Nightly Build repository

[Matthieu Baechler (JIRA)]

[ 
https://issues.apache.org/jira/browse/JAMES-1611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14904146#comment-14904146
 ] 

Matthieu Baechler commented on JAMES-1611:
--

Can somebody merge this one : https://github.com/apache/james/pull/9 ?

> site points to a deprecated Nightly Build repository
> 
>
> Key: JAMES-1611
> URL: https://issues.apache.org/jira/browse/JAMES-1611
> Project: James Server
>  Issue Type: Bug
>  Components: Documentation
>Affects Versions: Trunk
>Reporter: Matthieu Baechler
>
> There is a "Nightly Build" link that go to 
> https://repository.apache.org/content/repositories/snapshots/org/apache/james/apache-james/
>  put this repository has not been updated since 2012.
> I suggest to remove this link.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org