Bouncycastle no se puede cargar cuando vuelvo a desplegar la aplicación

Question

Sigo estas instrucciones para agregar bouncycastle: http://www.bouncycastle.org/wiki/display/JA1/Provider+Installation pero todavía tengo un problema. A veces, cuando vuelvo a implementar mi aplicación, no se encuentra este proveedor, por lo que mi aplicación lanza una excepción. Este problema ocurre solo uno por 100 redesplegar (quizás menos). Cuando reinicio mi servidor - weblogic, entonces comienza a funcionar nuevamente. Voy a ser muy agradecido por cualquier consejo por qué se produce este problema

EDIT:

estoy usando tanto el método en el enlace de arriba, porque cuando se utiliza sólo uno de ellos, entonces no trabaja agrego a esta java.security provder y luego en mi clase I registrado este provder:

static { 
    Security.addProvider(new BouncyCastleProvider()); 
} 

Answer 1

probablemente tiene un NoClassDefFoundError. Este es un problema conocido con las implementaciones de JSSE.

Aquí está el panorama:

• Sus cargas de contenedores clases castillo hinchable en un cargador de clases para aplicaciones específicas
• La instancia de proveedor se crea depende de que las clases y así sucesivamente que ClassLoader
• A continuación, el proveedor es registrado en JRE API gracias a campos estáticos en el nivel superior JVM ClassLoader
• Al volver a implementar, el contenedor descarta la aplicación ClassLoader para crear una nueva
• Como el algoritmo ya se sabe, la segunda inserción proveedor falla en silencio
• Cuando se utiliza el algoritmo de la instancia proveedor es simplemente inutilizable debido a que el cargador de clases ha sido descartada
• entonces la única opción es reiniciar el contenedor para tener la situación fijada .

Como no existe un detector estándar para el evento de anulación de despliegue, no es posible desencadenar la eliminación del proveedor de JSSE en el momento.

La forma recomendada de evitar ese problema es tener clases de castillo hinchable en su JVM ClassPath o en su contenedor ClassPath. Tienes que eliminarlo de tu aplicación. Ahora necesita registrar el proveedor de BC con una opción alternativa al inicializador estático. WebLogic proporciona ways to trigger code at server startup (he utilizado la clase de inicio del servidor), este código será responsable de registrar los proveedores de JSSE para toda la vida útil del servidor/JVM.

Una opción alternativa es añadir la siguiente línea en JRE java.security archivo con hinchable frasco castillo jre/lib/ext, pero no me gusta de esa manera, ya que se puede perder cuando se actualiza: security.provider.7=org.bouncycastle.jce.provider.BouncyCastleProvider

Así entonces la aplicación simplemente espera que las implementaciones están allí, puede ser una buena idea agregar pruebas de disponibilidad de algoritmo para informar cualquier problema a los operadores y usuarios.

Answer 2

puedo utilizar esta solución alternativa para implementar la aplicación en Tomcat:

public class GenSignCastle { 
    BouncyCastleProvider  bcProvider = null; 

public GenSignCastle() { 
    if (bcProvider == null) { 
     bcProvider = new BouncyCastleProvider(); 
     Provider[] providers = Security.getProviders(); 

     String name = bcProvider.getName(); 
     Security.removeProvider(name); // remove old instance 

     Security.addProvider(bcProvider); 
    } 
} 
. 
. 
. 
} 

Lo interesante es que tengo que quitar el BouncyCastleProvider primero en utilizar de nuevo después de redeploy.

Answer 3

este problema podría ser fácilmente resuelto por el siguiente código y uso del paquete sun.security.jce:

ProviderList list = Providers.getFullProviderList(); 
ProviderList.add(list, new BouncyCastleProvider()); 
Providers.beginThreadProviderList(list); 

la lista se extenderá a utilizar el proveedor castillo hinchable y se inyectará la nueva lista como un hilo local. esto podría usarse dentro de un servletfilter u otra cosa. tal vez sea necesario restablecer la lista al valor anterior después de que finalice la solicitud

Providers.endThreadProviderList(this.oldList);