Uploaded image for project: 'James Server'
  1. James Server
  2. JAMES-343

James does not compile using Sun JDK 5.0

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Trivial
    • Resolution: Duplicate
    • Affects Version/s: 2.3.0
    • Fix Version/s: 2.3.0
    • Component/s: None
    • Labels:
      None
    • Environment:
      Sun JDK 5.0
      Ant 1.6.2

      Description

      Several of the source files use a variable called "enum" for Enumerators. This is a new keyword in Java 1.5, and the Sun JDK 5.0 compiler fails when it sees these variables.

      Please add "source='1.4'" (or whichever language version is officially supported) to the "javac" task in build.xml.

      Changing the names of these variables would also work, but the "source" attribute provides better forward compatability as the Java language evolves.

        Activity

        Hide
        fiveside Stuart Roe added a comment -

        A code patch for this has been posted on JAMES-237.

        Show
        fiveside Stuart Roe added a comment - A code patch for this has been posted on JAMES-237 .
        Hide
        ralfhauser Ralf Hauser added a comment -

        in order to get the SSL working again, in build.xml, I had to amend the target sar with
        <property environment="env" />
        <property name="sunJce"
        location="$

        {env.JAVA_HOME}

        /jre/lib/ext/sunjce_provider.jar" />
        <copy file="$

        {sunJce}

        " todir="$

        {build.lib}

        "/>
        right before the sar task and in org.apache.james.James.initialize(), I had to add
        Security.addProvider(new SunJCE());
        Otherwise, when accessing with outlook, it dies with "bad handshake record MAC" and when accessing it with thunderbird, it dies with "DiffieHellman KeyPairGenerator not available"

        Vincenzo says that in currrent SVN branch_2_1_fcs, the registration is automatically done (statically) by org.apache.james.security.KeyHolder (at least for the SMIMESign mailet)

        Show
        ralfhauser Ralf Hauser added a comment - in order to get the SSL working again, in build.xml, I had to amend the target sar with <property environment="env" /> <property name="sunJce" location="$ {env.JAVA_HOME} /jre/lib/ext/sunjce_provider.jar" /> <copy file="$ {sunJce} " todir="$ {build.lib} "/> right before the sar task and in org.apache.james.James.initialize(), I had to add Security.addProvider(new SunJCE()); Otherwise, when accessing with outlook, it dies with "bad handshake record MAC" and when accessing it with thunderbird, it dies with "DiffieHellman KeyPairGenerator not available" Vincenzo says that in currrent SVN branch_2_1_fcs, the registration is automatically done (statically) by org.apache.james.security.KeyHolder (at least for the SMIMESign mailet)
        Hide
        vincenzo Vincenzo Gianferrari Pini added a comment -

        In currrent SVN branch_2_1_fcs, a registration of the org.bouncycastle.jce.provider.BouncyCastleProvider provider is automatically done by org.apache.james.security.KeyHolder when the SMIMESign mailet is initialized.
        The BouncyCastleProvider provider is needed as such mailet needs some SMIME functionalities wich are not available with the SunJCE provider (at least using jre 1.3x and 1.4x). The registration is done this way for convenience, but it could also be done "statically" adding a "security.provider.n=org.bouncycastle.jce.provider.BouncyCastleProvider" line to the appropriate (JRE or JSDK) <jre>/lib/security/java.security file.

        But this is specific to SMIMESign mailet; SSL does not need BouncyCastle. Let's explain. There are two separate actions/things to deal with:

        a) The appropriate/needed security provider(s) must be "registered" either statically in the java.security file or dinamically through a java.security.Security.addProvider() call (see org.apache.james.security.KeyHolder.InitJCE.init() as an example, where the call is done in a static method - don't confuse between static and dynamic here).

        b) When the registration(s) is/are done, the related jars must be found somewhere.

        Now the situation is as follows:

        1) SSL support needs a security provider. It can be SunJCE or some other (BouncyCastle works quite well).

        2) SMIMESign needs BouncyCastle (because of some SMIME functionality).

        3) Both JSDK and JRE 1.4x (and I suppose also 1.5) come by default with appropriate security.provider.n static registration entries in the <jre>/lib/security/java.security file for the Sun provider.

        4) Both JSDK and JRE 1.4x (and I suppose also 1.5) have the appropriate Sun security provider jars in the <jre>/lib directory.

        5) Avalon registers dynamically (see JAMES-348) the Sun providers; probably it was needeed for jre 1.3.

        6) In the current SVN branch_2_1_fcs, hence in the next coming James release, org.apache.james.security.KeyHolder registers the BouncyCastle provider when the SMIMESign mailet is started.

        7) Avalon loads (it's a fact) from <james>/lib, not from <jre>/lib, so the jars needed mus be placed in <james>/lib. I mean <james>/lib, not <james>/apps/james/SAR-INF/lib.

        8) No one (as far as I know - am I wrong?) including ASF, is allowed to distribute java run-time code from Sun in its own installations, so no Sun security provider jars are by default in the <james>/lib, and should be put there only manually.

        9) In the current SVN branch_2_1_fcs, hence in the next coming James release, the BouncyCastle provider jars are put in <james>/lib by the James install process, with the appropriate BC license file. The jars are choosen in order to have both jre 1.3x and 1.4x compatibility; 1.5 has never been tested.

        --------------

        Now the options:

        A. If you are using the latest SVN branch_2_1_fcs release:

        A.1 If you want to use SMIMESign, just put the appropriate entry in config.xml.

        A.2 If you want to use SSL, put the appropriate entries in config.xml and:

        A.2.1 If you have activated SMIMESign, SSL will work using the BouncyCastle provider. This is my own setup.

        A.2.2 If you don't activate SMIMESign, either:

        A.2.3 Copy the appropriate Sun provider jars to <james>/lib, or

        A.2.4 Do a dynamic registration of the BC provider somewhere, for example issuing a call to org.apache.james.security.KeyHolder.InitJCE.init() from org.apache.james.James.initialize().

        B. If you are using James 2.2.0- release, and want to use SSL:

        B.1 Copy the appropriate Sun provider jars to <james>/lib, or

        B.2 Copy some other provider jars to <james>/lib, and do s static or dynamic registration.

        I think that all this applies also to jre 1.5, but it should be tested anyhow. Check the security.provider.n static registration entries in the <jre>/lib/security/java.security file: the names may have changed.

        This comment came out very monotonous, but hopefully is clear.

        Show
        vincenzo Vincenzo Gianferrari Pini added a comment - In currrent SVN branch_2_1_fcs, a registration of the org.bouncycastle.jce.provider.BouncyCastleProvider provider is automatically done by org.apache.james.security.KeyHolder when the SMIMESign mailet is initialized. The BouncyCastleProvider provider is needed as such mailet needs some SMIME functionalities wich are not available with the SunJCE provider (at least using jre 1.3x and 1.4x). The registration is done this way for convenience, but it could also be done "statically" adding a "security.provider.n=org.bouncycastle.jce.provider.BouncyCastleProvider" line to the appropriate (JRE or JSDK) <jre>/lib/security/java.security file. But this is specific to SMIMESign mailet; SSL does not need BouncyCastle. Let's explain. There are two separate actions/things to deal with: a) The appropriate/needed security provider(s) must be "registered" either statically in the java.security file or dinamically through a java.security.Security.addProvider() call (see org.apache.james.security.KeyHolder.InitJCE.init() as an example, where the call is done in a static method - don't confuse between static and dynamic here). b) When the registration(s) is/are done, the related jars must be found somewhere. Now the situation is as follows: 1) SSL support needs a security provider. It can be SunJCE or some other (BouncyCastle works quite well). 2) SMIMESign needs BouncyCastle (because of some SMIME functionality). 3) Both JSDK and JRE 1.4x (and I suppose also 1.5) come by default with appropriate security.provider.n static registration entries in the <jre>/lib/security/java.security file for the Sun provider. 4) Both JSDK and JRE 1.4x (and I suppose also 1.5) have the appropriate Sun security provider jars in the <jre>/lib directory. 5) Avalon registers dynamically (see JAMES-348 ) the Sun providers; probably it was needeed for jre 1.3. 6) In the current SVN branch_2_1_fcs, hence in the next coming James release, org.apache.james.security.KeyHolder registers the BouncyCastle provider when the SMIMESign mailet is started. 7) Avalon loads (it's a fact) from <james>/lib, not from <jre>/lib, so the jars needed mus be placed in <james>/lib. I mean <james>/lib, not <james>/apps/james/SAR-INF/lib. 8) No one (as far as I know - am I wrong?) including ASF, is allowed to distribute java run-time code from Sun in its own installations, so no Sun security provider jars are by default in the <james>/lib, and should be put there only manually. 9) In the current SVN branch_2_1_fcs, hence in the next coming James release, the BouncyCastle provider jars are put in <james>/lib by the James install process, with the appropriate BC license file. The jars are choosen in order to have both jre 1.3x and 1.4x compatibility; 1.5 has never been tested. -------------- Now the options: A. If you are using the latest SVN branch_2_1_fcs release: A.1 If you want to use SMIMESign, just put the appropriate entry in config.xml. A.2 If you want to use SSL, put the appropriate entries in config.xml and: A.2.1 If you have activated SMIMESign, SSL will work using the BouncyCastle provider. This is my own setup. A.2.2 If you don't activate SMIMESign, either: A.2.3 Copy the appropriate Sun provider jars to <james>/lib, or A.2.4 Do a dynamic registration of the BC provider somewhere, for example issuing a call to org.apache.james.security.KeyHolder.InitJCE.init() from org.apache.james.James.initialize(). B. If you are using James 2.2.0- release, and want to use SSL: B.1 Copy the appropriate Sun provider jars to <james>/lib, or B.2 Copy some other provider jars to <james>/lib, and do s static or dynamic registration. I think that all this applies also to jre 1.5, but it should be tested anyhow. Check the security.provider.n static registration entries in the <jre>/lib/security/java.security file: the names may have changed . This comment came out very monotonous, but hopefully is clear.
        Hide
        bago Stefano Bagnara added a comment -

        The main issue is a duplicate of the enum issue already closed. The security issue (if still valid) should be posted in its own issue.

        Show
        bago Stefano Bagnara added a comment - The main issue is a duplicate of the enum issue already closed. The security issue (if still valid) should be posted in its own issue.
        Hide
        danny@apache.org Danny Angus added a comment -

        Closing issue fixed in released version.

        Show
        danny@apache.org Danny Angus added a comment - Closing issue fixed in released version.

          People

          • Assignee:
            bago Stefano Bagnara
            Reporter:
            jkeyser Jeff Keyser
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development