Buscar este blog

sábado, 31 de agosto de 2013

Weblogic despliega dos veces / Weblogic deploy twice

Al trabajar con weblogic y eclipse, muchas veces da la impresión de que las aplicaciones se despliegan dos veces. Una junto al arranque del servidor y, una vez éste está running, vuelve a hacer el deploy correspondiente.

Parece que el problema está en la carpeta tmp del server que no se borra durante los reinicios.

Para solucionarlo se puede modificar el script de arranque de startWebLogic.cmd añadiendo la instrucción  rd de MS-DOS para borrar el tmp antes de iniciar:


 @ECHO OFF  
 @REM WARNING: This file is created by the Configuration Wizard.  
 @REM Any changes to this script may be lost when adding extensions to this configuration.  
 SETLOCAL  
 set DOMAIN_HOME=C:\Oracle\Middleware\user_projects\domains\comercio_domain  

 @REM Borrar tmp  
 rd /S /Q %DOMAIN_HOME%\servers\AdminServer\tmp  

 call "%DOMAIN_HOME%\bin\startWebLogic.cmd" %*  
 ENDLOCAL  


Este archivo está en el DOMAIN_HOME de Weblogic.

domingo, 11 de agosto de 2013

Error: com.sun.xml.ws.wsdl.parser.InaccessibleWSDLException, message: 2 counts of InaccessibleWSDLException.

Trabajando con Weblogic 10.3.5, JAX-WS y Axis2 puede que aparezca el siguiente error:


 weblogic.wsee.jaxws.framework.policy.advertisementimpl.AdvertisementHelperImpl registerExtension  
 ADVERTENCIA: Registering oracle.j2ee.ws.wsdl.extensions.addressing.AddressingExtensionRegistry extension failed; java.lang.ClassNotFoundException: oracle.j2ee.ws.wsdl.extensions.addressing.AddressingExtensionRegistry  
 weblogic.wsee.jaxws.spi.WLSServiceDelegate addWsdlDefinitionFeature  
 GRAVE: Failed to create WsdlDefinitionFeature for wsdl location: https://xxxxxx.xx/xxxxx?wsdl, error: com.sun.xml.ws.wsdl.parser.InaccessibleWSDLException, message: 2 counts of InaccessibleWSDLException.  

Realmente no es un problema, ya que todo funciona correctamente, pero va estar llenando los logs de basura innecesaria.
El origen está en la incompatibilidad de jars del tipo javax. que son los que trae por defecto weblogic.

Tras muchas pruebas, el útlimo jar que vi que daba problemas era wsdl4j-1.6.2.jar, que excluyéndolo elimina el aviso.

El total de exclusiones en el pom.xml de Maven es el siguiente:


 <dependency>  
      <groupId>org.apache.axis2</groupId>  
      <artifactId>axis2-kernel</artifactId>  
      <version>1.4.1</version>  
      <exclusions>  
           <exclusion>  
                <groupId>org.apache.geronimo.specs</groupId>  
                <artifactId>geronimo-activation_1.1_spec</artifactId>  
           </exclusion>  
           <exclusion>  
                <groupId>org.apache.geronimo.specs</groupId>  
                <artifactId>geronimo-javamail_1.4_spec</artifactId>  
           </exclusion>  
           <exclusion>  
                <groupId>org.apache.geronimo.specs</groupId>  
                <artifactId>geronimo-jms_1.1_spec</artifactId>  
           </exclusion>  
           <exclusion>  
                <groupId>org.apache.geronimo.specs</groupId>  
                <artifactId>geronimo-stax-api_1.0_spec</artifactId>  
           </exclusion>  
           <exclusion>  
                <groupId>javax.activation</groupId>  
                <artifactId>activation</artifactId>  
           </exclusion>  
           <exclusion>  
                <artifactId>wsdl4j</artifactId>  
                <groupId>wsdl4j</groupId>  
           </exclusion>  
      </exclusions>  
 </dependency>  
 <dependency>  
      <groupId>org.apache.axis2</groupId>  
      <artifactId>axis2-codegen</artifactId>  
      <version>1.4.1</version>  
      <exclusions>  
           <exclusion>            
                <groupId>org.apache.geronimo.specs</groupId>  
                <artifactId>geronimo-activation_1.1_spec</artifactId>  
           </exclusion>  
           <exclusion>  
                <groupId>org.apache.geronimo.specs</groupId>  
                <artifactId>geronimo-stax-api_1.0_spec</artifactId>  
           </exclusion>                 
      </exclusions>  
 </dependency>  

viernes, 9 de agosto de 2013

Comprobar si sesion serializable cluster / Check Session Serializable cluster

Cuando se trabaja con aplicaciones web que van a ejecutarse en varios nodos de un cluster, una de las cosas que hay que tener en cuenta es que todo objeto que se almacene en sesión debe ser serializable.

Esto es debido a que el gestor del cluster va a serializarla para repartirla entre los distintos nodos. Así, ante la caída de uno de ellos, el balanceador de carga puede redireccionar al usuario hacia otro nodo conservando todos los datos de sesión, por ejemplo el contexto de spring security.

Un objeto es serializable cuando:
  1. Implementa el interface java.io.serializable
  2. Todas sus propiedades también son serializables

Para comprobar si un objeto es serializable, lo mejor es intentar serializarlo. Si salta una excepción entonces es que tenemos algo mal.

A continuación se muestra un trozo de código que lee todos los objetos de sesión y los serializa a un fichero de texto. Para mayor seguridad, seguidamente intenta leerlos de ese fichero.
Si este código no da error, entonces la sesión es serializable y no habrá problemas con los cluster.

 private void checkSession(HttpSession session) {  
   final String RUTA = "C:/MyDir/session.ser";  
   File f = new File(RUTA);  
   f.delete();  
   try {  
        FileOutputStream fileOut = new FileOutputStream(RUTA);  
        ObjectOutputStream out = new ObjectOutputStream(fileOut);  
        String nombreAtributo;  
        @SuppressWarnings("rawtypes")  
        Enumeration enumNombres = session.getAttributeNames();  
        while (enumNombres.hasMoreElements()) {  
             nombreAtributo = (String) enumNombres.nextElement();  
             System.out.println("Serializando... " + nombreAtributo);  
             out.writeObject(session.getAttribute(nombreAtributo));  
        }  
        out.flush();  
        out.close();  
        fileOut.close();  
        System.out.printf("Todo ok");  
   } catch (IOException e) {  
           System.out.println("No serializable!!!!");  
           e.printStackTrace();  
   }  
   //****************************************//  
   FileInputStream fileIn = null;  
   ObjectInputStream in = null;  
   try {  
        fileIn = new FileInputStream(RUTA);  
        in = new ObjectInputStream(fileIn);  
        Object objeto;          
        while (true){  
             objeto = in.readObject();  
             System.out.println("Deserializando...." + objeto.getClass() + " -----> " + objeto);  
        }                                
   }  
   catch (EOFException exc) {  
        try {  
             in.close();  
             fileIn.close();  
        } catch (IOException e) {                        
             e.printStackTrace();  
        }                        
   }  
   catch (IOException i) {  
           i.printStackTrace();  
   }   
   catch (ClassNotFoundException e) {  
           e.printStackTrace();  
   }  
 }  

Este código se puede poner en cualquier parte de la aplicación que tenga acceso a la request. Por ejemplo, en Spring MVC se podría usar en un controller, un interceptor o incluso en un filtro.

lunes, 5 de agosto de 2013

Cargar certificado de fichero / Load certificate from file

 String ruta = "C:/miDir/test.crt"; 
 CertificateFactory cf = CertificateFactory.getInstance("X.509"); 
 BufferedInputStream in = new BufferedInputStream(new FileInputStream(ruta)); 
 java.security.cert.Certificate cert = cf.generateCertificate(in); 

Forzar a utilizar la última versión de Internet Explorer

A partir de Explorer 8 se incluyen las vistas de compatibilidad, que permiten mostrar una página como si se emplease Explorer 7.

Para forzar a utilizar siempre la última versión disponible hay que incluir la siguiente meta e la cabecera


 <meta http-equiv="X-UA-Compatible" content="IE=Edge" />