You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by "Ralph Holland (JIRA)" <se...@james.apache.org> on 2010/01/01 03:44:29 UTC
[jira] Created: (JAMES-942) James FetchMail instances are sharing
the same Properties class instance preventing correct setting of
mail.pop3.port etc
James FetchMail instances are sharing the same Properties class instance preventing correct setting of mail.pop3.port etc
-------------------------------------------------------------------------------------------------------------------------
Key: JAMES-942
URL: https://issues.apache.org/jira/browse/JAMES-942
Project: JAMES Server
Issue Type: Bug
Components: Deployment Modules
Affects Versions: 2.3.2
Environment: Bug is in FetchMail.java
Reporter: Ralph Holland
Fix For: 2.4
James-fetchmail permits you to set the mail API properies via the JavaMailProperties element in the james-fetchmail.xml config file e.g:
<javaMailProperties>
<property name="mail.pop3.connectiontimeout" value="0"/>
<property name="mail.pop3.timeout" value="0"/>
<property name="mail.pop3.port" value="2000"/>
</javaMailProperties>
However, the FetchMail class passes a reference to the Systems.getProperties() class into the Service that interacts with the MailAPI, this means that multiple instances of the FetchMail class are actually sharing the same Properties class and prevents different values from being set, e.g. the mail.pop3.port.
A simple fix for this bug is to change FetchMail.getSession() so a new instance of a PropertiesClass is passed in to create the session, using the System Properties as a default, as per the example below:
/**
* Answers a new Session.
* @return Session
*/
protected Session computeSession()
{
// Make separate properties instance so the
// fetchmail.xml <javaMailProperties> can override the
// property values without interfering with other fetchmail instances
return Session.getInstance( new Properties( System.getProperties()) );
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
[jira] Updated: (JAMES-942) James FetchMail instances are sharing
the same Properties class instance preventing correct setting of
mail.pop3.port etc
Posted by "Ralph Holland (JIRA)" <se...@james.apache.org>.
[ https://issues.apache.org/jira/browse/JAMES-942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ralph Holland updated JAMES-942:
--------------------------------
Description:
James-fetchmail.xml permits you to set the mail API properies via the JavaMailProperties element e.g:
<javaMailProperties>
<property name="mail.pop3.connectiontimeout" value="0"/>
<property name="mail.pop3.timeout" value="0"/>
<property name="mail.pop3.port" value="2000"/>
</javaMailProperties>
However, the FetchMail class passes a reference to the Systems.getProperties() class into the Service that interacts with the MailAPI, this means that multiple instances of the FetchMail class are actually sharing the same Properties class and prevents different values from being set, e.g. the mail.pop3.port.
A simple fix for this bug is to change FetchMail.computeSession() so a new instance of a PropertiesClass is passed in to create the session instance, using the System Properties as a default, as per the example below:
/**
* Answers a new Session.
* @return Session
*/
protected Session computeSession()
{
// Make separate properties instance so the
// fetchmail.xml <javaMailProperties> can override the
// property values without interfering with other fetchmail instances
return Session.getInstance( new Properties( System.getProperties()) );
}
was:
James-fetchmail.xml permits you to set the mail API properies via the JavaMailProperties element e.g:
<quote>
<javaMailProperties>
<property name="mail.pop3.connectiontimeout" value="0"/>
<property name="mail.pop3.timeout" value="0"/>
<property name="mail.pop3.port" value="2000"/>
</javaMailProperties>
</quote>
However, the FetchMail class passes a reference to the Systems.getProperties() class into the Service that interacts with the MailAPI, this means that multiple instances of the FetchMail class are actually sharing the same Properties class and prevents different values from being set, e.g. the mail.pop3.port.
A simple fix for this bug is to change FetchMail.computeSession() so a new instance of a PropertiesClass is passed in to create the session instance, using the System Properties as a default, as per the example below:
<quote>
/**
* Answers a new Session.
* @return Session
*/
protected Session computeSession()
{
// Make separate properties instance so the
// fetchmail.xml <javaMailProperties> can override the
// property values without interfering with other fetchmail instances
return Session.getInstance( new Properties( System.getProperties()) );
}
</quote>
> James FetchMail instances are sharing the same Properties class instance preventing correct setting of mail.pop3.port etc
> -------------------------------------------------------------------------------------------------------------------------
>
> Key: JAMES-942
> URL: https://issues.apache.org/jira/browse/JAMES-942
> Project: JAMES Server
> Issue Type: Bug
> Components: Deployment Modules
> Affects Versions: 2.3.2
> Environment: Bug is in FetchMail.java
> Reporter: Ralph Holland
> Fix For: 2.4
>
>
> James-fetchmail.xml permits you to set the mail API properies via the JavaMailProperties element e.g:
> <javaMailProperties>
> <property name="mail.pop3.connectiontimeout" value="0"/>
> <property name="mail.pop3.timeout" value="0"/>
> <property name="mail.pop3.port" value="2000"/>
> </javaMailProperties>
> However, the FetchMail class passes a reference to the Systems.getProperties() class into the Service that interacts with the MailAPI, this means that multiple instances of the FetchMail class are actually sharing the same Properties class and prevents different values from being set, e.g. the mail.pop3.port.
> A simple fix for this bug is to change FetchMail.computeSession() so a new instance of a PropertiesClass is passed in to create the session instance, using the System Properties as a default, as per the example below:
> /**
> * Answers a new Session.
> * @return Session
> */
> protected Session computeSession()
> {
> // Make separate properties instance so the
> // fetchmail.xml <javaMailProperties> can override the
> // property values without interfering with other fetchmail instances
> return Session.getInstance( new Properties( System.getProperties()) );
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
[jira] Assigned: (JAMES-942) James FetchMail instances are sharing
the same Properties class instance preventing correct setting of
mail.pop3.port etc
Posted by "Norman Maurer (JIRA)" <se...@james.apache.org>.
[ https://issues.apache.org/jira/browse/JAMES-942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Norman Maurer reassigned JAMES-942:
-----------------------------------
Assignee: Norman Maurer
> James FetchMail instances are sharing the same Properties class instance preventing correct setting of mail.pop3.port etc
> -------------------------------------------------------------------------------------------------------------------------
>
> Key: JAMES-942
> URL: https://issues.apache.org/jira/browse/JAMES-942
> Project: JAMES Server
> Issue Type: Bug
> Components: Deployment Modules
> Affects Versions: 2.3.2
> Environment: Bug is in FetchMail.java
> Reporter: Ralph Holland
> Assignee: Norman Maurer
> Fix For: 2.4
>
>
> James-fetchmail.xml permits you to set the mail API properies via the JavaMailProperties element e.g:
> <javaMailProperties>
> <property name="mail.pop3.connectiontimeout" value="0"/>
> <property name="mail.pop3.timeout" value="0"/>
> <property name="mail.pop3.port" value="2000"/>
> </javaMailProperties>
> However, the FetchMail class passes a reference to the Systems.getProperties() class into the Service that interacts with the MailAPI, this means that multiple instances of the FetchMail class are actually sharing the same Properties class and prevents different values from being set, e.g. the mail.pop3.port.
> A simple fix for this bug is to change FetchMail.computeSession() so a new instance of a PropertiesClass is passed in to create the session instance, using the System Properties as a default, as per the example below:
> /**
> * Answers a new Session.
> * @return Session
> */
> protected Session computeSession()
> {
> // Make separate properties instance so the
> // fetchmail.xml <javaMailProperties> can override the
> // property values without interfering with other fetchmail instances
> return Session.getInstance( new Properties( System.getProperties()) );
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
[jira] Resolved: (JAMES-942) James FetchMail instances are sharing
the same Properties class instance preventing correct setting of
mail.pop3.port etc
Posted by "Norman Maurer (JIRA)" <se...@james.apache.org>.
[ https://issues.apache.org/jira/browse/JAMES-942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Norman Maurer resolved JAMES-942.
---------------------------------
Resolution: Fixed
Fix Version/s: 3.0-M1
3.0
Fixed.. Thx for the patch!
> James FetchMail instances are sharing the same Properties class instance preventing correct setting of mail.pop3.port etc
> -------------------------------------------------------------------------------------------------------------------------
>
> Key: JAMES-942
> URL: https://issues.apache.org/jira/browse/JAMES-942
> Project: JAMES Server
> Issue Type: Bug
> Components: Deployment Modules
> Affects Versions: 2.3.2
> Environment: Bug is in FetchMail.java
> Reporter: Ralph Holland
> Assignee: Norman Maurer
> Fix For: 2.4, 3.0, 3.0-M1
>
>
> James-fetchmail.xml permits you to set the mail API properies via the JavaMailProperties element e.g:
> <javaMailProperties>
> <property name="mail.pop3.connectiontimeout" value="0"/>
> <property name="mail.pop3.timeout" value="0"/>
> <property name="mail.pop3.port" value="2000"/>
> </javaMailProperties>
> However, the FetchMail class passes a reference to the Systems.getProperties() class into the Service that interacts with the MailAPI, this means that multiple instances of the FetchMail class are actually sharing the same Properties class and prevents different values from being set, e.g. the mail.pop3.port.
> A simple fix for this bug is to change FetchMail.computeSession() so a new instance of a PropertiesClass is passed in to create the session instance, using the System Properties as a default, as per the example below:
> /**
> * Answers a new Session.
> * @return Session
> */
> protected Session computeSession()
> {
> // Make separate properties instance so the
> // fetchmail.xml <javaMailProperties> can override the
> // property values without interfering with other fetchmail instances
> return Session.getInstance( new Properties( System.getProperties()) );
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
[jira] Updated: (JAMES-942) James FetchMail instances are sharing
the same Properties class instance preventing correct setting of
mail.pop3.port etc
Posted by "Ralph Holland (JIRA)" <se...@james.apache.org>.
[ https://issues.apache.org/jira/browse/JAMES-942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ralph Holland updated JAMES-942:
--------------------------------
Description:
James-fetchmail.xml permits you to set the mail API properies via the JavaMailProperties element e.g:
<quote>
<javaMailProperties>
<property name="mail.pop3.connectiontimeout" value="0"/>
<property name="mail.pop3.timeout" value="0"/>
<property name="mail.pop3.port" value="2000"/>
</javaMailProperties>
</quote>
However, the FetchMail class passes a reference to the Systems.getProperties() class into the Service that interacts with the MailAPI, this means that multiple instances of the FetchMail class are actually sharing the same Properties class and prevents different values from being set, e.g. the mail.pop3.port.
A simple fix for this bug is to change FetchMail.computeSession() so a new instance of a PropertiesClass is passed in to create the session instance, using the System Properties as a default, as per the example below:
<quote>
/**
* Answers a new Session.
* @return Session
*/
protected Session computeSession()
{
// Make separate properties instance so the
// fetchmail.xml <javaMailProperties> can override the
// property values without interfering with other fetchmail instances
return Session.getInstance( new Properties( System.getProperties()) );
}
</quote>
was:
James-fetchmail permits you to set the mail API properies via the JavaMailProperties element in the james-fetchmail.xml config file e.g:
<javaMailProperties>
<property name="mail.pop3.connectiontimeout" value="0"/>
<property name="mail.pop3.timeout" value="0"/>
<property name="mail.pop3.port" value="2000"/>
</javaMailProperties>
However, the FetchMail class passes a reference to the Systems.getProperties() class into the Service that interacts with the MailAPI, this means that multiple instances of the FetchMail class are actually sharing the same Properties class and prevents different values from being set, e.g. the mail.pop3.port.
A simple fix for this bug is to change FetchMail.getSession() so a new instance of a PropertiesClass is passed in to create the session, using the System Properties as a default, as per the example below:
/**
* Answers a new Session.
* @return Session
*/
protected Session computeSession()
{
// Make separate properties instance so the
// fetchmail.xml <javaMailProperties> can override the
// property values without interfering with other fetchmail instances
return Session.getInstance( new Properties( System.getProperties()) );
}
> James FetchMail instances are sharing the same Properties class instance preventing correct setting of mail.pop3.port etc
> -------------------------------------------------------------------------------------------------------------------------
>
> Key: JAMES-942
> URL: https://issues.apache.org/jira/browse/JAMES-942
> Project: JAMES Server
> Issue Type: Bug
> Components: Deployment Modules
> Affects Versions: 2.3.2
> Environment: Bug is in FetchMail.java
> Reporter: Ralph Holland
> Fix For: 2.4
>
>
> James-fetchmail.xml permits you to set the mail API properies via the JavaMailProperties element e.g:
> <quote>
> <javaMailProperties>
> <property name="mail.pop3.connectiontimeout" value="0"/>
> <property name="mail.pop3.timeout" value="0"/>
> <property name="mail.pop3.port" value="2000"/>
> </javaMailProperties>
> </quote>
> However, the FetchMail class passes a reference to the Systems.getProperties() class into the Service that interacts with the MailAPI, this means that multiple instances of the FetchMail class are actually sharing the same Properties class and prevents different values from being set, e.g. the mail.pop3.port.
> A simple fix for this bug is to change FetchMail.computeSession() so a new instance of a PropertiesClass is passed in to create the session instance, using the System Properties as a default, as per the example below:
> <quote>
> /**
> * Answers a new Session.
> * @return Session
> */
> protected Session computeSession()
> {
> // Make separate properties instance so the
> // fetchmail.xml <javaMailProperties> can override the
> // property values without interfering with other fetchmail instances
> return Session.getInstance( new Properties( System.getProperties()) );
> }
> </quote>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org