[prev in list] [next in list] [prev in thread] [next in thread] 

List:       james-dev
Subject:    [jira] Commented: (JAMES-343) James does not compile using Sun JDK 5.0
From:       "Vincenzo Gianferrari Pini (JIRA)" <server-dev () james ! apache ! org>
Date:       2005-01-11 11:03:12
Message-ID: 1498750920.1105441392712.JavaMail.jira () ajax ! apache ! org
[Download RAW message or body]

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

> 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:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira


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


[prev in list] [next in list] [prev in thread] [next in thread]