james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vincenzo Gianferrari Pini (JIRA)" <server-...@james.apache.org>
Subject [jira] Commented: (JAMES-343) James does not compile using Sun JDK 5.0
Date Tue, 11 Jan 2005 11:03:12 GMT
     [ http://issues.apache.org/jira/browse/JAMES-343?page=comments#action_57500 ]
Vincenzo Gianferrari Pini commented on JAMES-343:

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

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.

> James does not compile using Sun JDK 5.0
> ----------------------------------------
>          Key: JAMES-343
>          URL: http://issues.apache.org/jira/browse/JAMES-343
>      Project: James
>         Type: Bug
>     Versions: 2.2.1
>  Environment: Sun JDK 5.0
> Ant 1.6.2
>     Reporter: Jeff Keyser
>     Priority: Trivial

> 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.

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
If you want more information on JIRA, or have a bug to report see:

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

View raw message