James Server
  1. James Server
  2. JAMES-942

James FetchMail instances are sharing the same Properties class instance preventing correct setting of mail.pop3.port etc

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.3.2
    • Fix Version/s: 2.4, 3.0-M1, 3.0.0
    • Component/s: Deployment Modules
    • Labels:
      None
    • Environment:
      Bug is in FetchMail.java

      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()) ); }

        Activity

        Ralph Holland created issue -
        Ralph Holland made changes -
        Field Original Value New Value
        Description 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.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>
        Ralph Holland made changes -
        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>
        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()) );
            }
        Norman Maurer made changes -
        Assignee Norman Maurer [ norman ]
        Norman Maurer made changes -
        Status Open [ 1 ] Resolved [ 5 ]
        Fix Version/s 3.0 [ 10427 ]
        Fix Version/s 3.0-M1 [ 12314294 ]
        Resolution Fixed [ 1 ]
        Mark Thomas made changes -
        Workflow jira [ 12485826 ] Default workflow, editable Closed status [ 12566421 ]
        Mark Thomas made changes -
        Workflow Default workflow, editable Closed status [ 12566421 ] jira [ 12581822 ]

          People

          • Assignee:
            Norman Maurer
            Reporter:
            Ralph Holland
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development