[ 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
