PHP

Es muy frecuente que estemos desarrollando, en nuestro entorno en local, con php 5, pero si no tenemos cuidado,hemos instalado php 5.5.x, generalmente el que viene con herramientas tipo WAMP o LAMP, pero al migrar nuestro código al servidor, nos encontramos la sorpresa que en el script donde usábamos password_hash explota estrepitosamente, dándonos un error 500 , tras el susto inicial , es cuando descubrimos que nuestro servidor está usando PHP 5.4.x

En PHP 5.5 , cuando tenemos que generar una hash de una contraseña, utilizamos la función password_hash .

test-5_5.php
<?php
try {
    $password = "test";
    $hashed_password = password_hash($password, PASSWORD_DEFAULT);
    echo password_verify($password, $hashed_password);  
} catch(Exception $e) {
    var_dump($e);
    die();
}
?>

Para versiones inferiores a PHP 5.5, PHP 5.4, podemos utilizar crypt

test-5_4.php
<?php
try {
  $password = "test";
    $salt = uniqid(mt_rand(), true); 
    $options = ['salt'=>$salt, 'cost'=>12];     
    $cryptpwd = crypt($password,'$2y$12$'.$salt.'$'); 
    echo $cryptpwd;   
} catch(Exception $e) {
    var_dump($e);
    die();
}
?>

En ambos casos, obtendremos un hash codificado de nuestra contraseña.

Aún así, existen otras alternativas:
- Para PHP < 5.3.5 , phpass
- Para PHP >= 5.3.7, password_compat

Cuando estás trabajando con bases de datos grandes, y usas clientes para su gestión, ya sea phpmyadmin u otro cualquier, podemos tener problemas para importar o exportar gran volumen de datos.

Para solventarlo, podemos utilizar la consola de mysql y ejecutar las sentencias.

  • Para exportar:

mysqldump -u mysql_user -p DATABASE_NAME > backup.sql

  • Para importar:

mysql -u mysql_user -p DATABASE < backup.sql

En algunas ocasiones que estemos trabajando con weblogic , y un cliente que haga uso de las librerías de este servidor de aplicaciones, necesitaremos tener la librería wlfullclient.jar

Para generarla, deberemos situarnos en el directorio de weblogic

cd WL_HOME/server/lib

y ejecutar

java -jar wljarbuilder.jar

Generándose la librería wlfullclient.jar a partir de la versión de weblogic desde donde la ejecutemos.

Puede darse el caso que en algún momento necesitemos obtener las columnas de una tabla.
En Oracle podemos hacerlo mediante la sentencia describe

DESCRIBE NOMBRE_TABLA

cuyo resultado sería, para una tabla ejemplo:

DESCRIBE  NOMBRE_TABLA
Nombre                 Nulo      Tipo          
--------------------- -------- ------------- 
ID                    NOT NULL    NUMBER(10)    
DESCRIPTION           NOT NULL    VARCHAR2(255) 
FECHA_ALTA                        TIMESTAMP(6)  
VALUE                 NOT NULL    NUMBER(1)     

pero ¿y si queremos comprobar si existe una columna y realizar una operación u otra si existe o no?

Podemos utilizar la sentencia SQL, que consulta la tabla USER_TAB_COLUMNS que según la documentación de oracle , describe las tablas, vistas del usuario.

Por tanto, filtramos por nombre de tabla y columna:

select TABLE_NAME, COLUMN_NAME from USER_TAB_COLUMNS where TABLE_NAME = 'NOMBRE_TABLA' AND COLUMN_NAME = 'DESCRIPTION'

Cuyo resultado será vacío si no existe y devolverá un resultado en caso que sí:

TABLE_NAME            COLUMN_NAME                  
--------------------- ------------- 
NOMBRE_TABLA          DESCRIPTION

Puede darse el caso que en algún momento de nuestra vida como desarrollador [developer :smile: ] queramos conocer la versión de la base de datos oracle que estamos utilizando. Para obtener esta información tenemos dos opciones.

  1. Preguntar al administrador de sistemas que gestiona esa máquina.... :sunglasses:
  2. Lanzar la siguiente consulta desde una nueva hoja de trabajo, por ejemplo, abierta con SQL DEVELOPERS

    Obtendremos la información que buscamos:

PRODUCT VERSION STATUS
NLSRTL 11.2.0.3.0 Production
Oracle Database 11g Enterprise Edition 11.2.0.3.0 64bit Production
PL/SQL 11.2.0.3.0 Production
TNS for Linux: 11.2.0.3.0 Production

Cuando desplegamos una aplicación con Vaadin 7, la cuál la hemos compilado con mvn, (mvn clean install) , podemos encontrarnos que al cargar en el navegador se nos abra un alert, ventana emergente con el error:

Failed to load the widgetset: ./VAADIN/widgetsets/AppWidgetset/AppWidgetset.nocache.js?

y en la consola se podrá ver más detalle del error.

com.vaadin.server.VaadinServlet serveStaticResourcesInVAADIN
INFO: Requested resource [/VAADIN/widgetsets/com.mypackage.client.ui.AppWidgetSe
t/com.mypackage.client.ui.AppWidgetSet.nocache.js] not found from filesystem or
through class loader. Add widgetset and/or theme JAR to your classpath or add fi
les to WebContent/VAADIN folder.

Vaadin utiliza GWT para compilar código Java y convertilo en javascript. El resultado final de esta compilación son los llamados widgetset, además de todo código autogenerado. El error que se muestra es debido a que la aplicación debe usar widgetset personalizado que se encuentra en com.mypackage.client.ui.AppWidgetSet en lugar del predeterminado incluido con Vaadin 7.

Para solventarlo deberemos tener en el pom.xml de nuestro proyecto la siguiente dependencia.

<dependency>
  <groupId>com.vaadin</groupId>
  <artifactId>vaadin-client-compiled</artifactId>
  <version>${vaadin7.version}</version>
  <!--<scope>provided</scope>-->
</dependency>
  • Eliminar este fragmento de código del archivo web.xml. Sin él, Vaadin utilizará el widgetset predeterminado que encuentra dentro de los frascos de Vaadin.

    <Init-param>
    <Param-name> widgetset </ param-name>
    <Param-value> com.mypackage.client.ui.AppWidgetSet </ param-value>
    </ Init-param>
    
  • Compilar el widgetset, en nuestro proyecto, añadiendo el goal vaadin:update-widgetset a maven, es decir:

    mvn vaadin:update-widgetset install
    

Esta vez , nos encontramos en el caso de que queremos encontrar que tablas de nuestra base de datos contienen una columna de la cuál sabemos su nombre o una parte de él, para realizar esta búsqueda, tenemos dos formas, o vamos abriendo tabla por tabla... o bien mediante una consulta SQL, donde especificamos en el LIKE el nombre de la columna a buscar

MYSQL

select * from INFORMATION_SCHEMA.COLUMNS 
where COLUMN_NAME like '%nombreColumna%' 
order by TABLE_NAME

ORACLE

select distinct table_name, 
                column_name, 
                data_type || ' (' || 
                decode(data_type,'LONG',null,'LONG RAW',null,
                       'BLOB',null,'CLOB',null,'NUMBER',
                       decode(data_precision,null,to_char(data_length),
                              data_precision||','||data_scale
                             ), data_length
                      ) || ')' data_type
  from all_tab_columns
 where column_name like ('%' || upper('nombreColumna') || '%');

Debemos tener en cuenta las mayúsculas o minúsculas del nombre de la tabla, para ello, bastaría con modificar las queries de manera sencilla.

Puede darse el caso que a la hora de compilar nuestros proyectos en maven querramos forzar que se baje los jars (dependencias establecidas en el archivo pom.xml) del repositorio remoto , para ello , a nuestro comando de compilación añadiremos -U

Por ejemplo, si queremos borrar carpeta target, compilar y forzar que se baje las dependencias, ejecutaremos:

mvn clean install -U

En el caso que no queramos que se baje ningún jar de nuestro repositorio remoto, si no, que siempre use las que tengamos en nuestro repositorio local, usaremos -o

mvn clean install -o

Puede darse el caso que necesitemos saber con que versión de la JDK de java está compilada la calse, para ello tenemos dos comandos que podemos utilizar, en función del sistema operativo en el que nos encontremos.

Para Windows:

javap -v <class> | findstr major

Para Linux/Unix:

javap -v <class> | grep major

Por ejemplo, si queremos saber la versión con que está compilada la clase ./org/apache/log4j/Appender.class del jar de log4j

javap -v ./org/apache/log4j/Appender.class | grep major
 major version: 45

Donde nos indica que la versión es la 51, número que corresponde con la siguiente tabla de versiones de Java JDK:

Major version Versión Java
45.3 Java 1.1
46 Java 1.2
47 Java 1.3
48 Java 1.4
49 Java 5
50 Java 6
51 Java 7
52 Java 8

Para enviar emails desde un EJB, tendremos que crear un bean de sessión donde definimos por jndi la configuración del email, a posteriori creamos nuestro message de la clase MimeMessage

@Stateless(name = "EmailEJB")
public class EmailEJB implements EmailRemoteEJB {


@Resource(name = "mail/miMailSession")
private Session mailSession;

@Asynchronous
@Lock(LockType.READ)
    public void sendMail(String recipient, String subject, String msg) {
        try {
                        //En algunos servidores (como wildfly 10) la inyección del Resource no funciona, entonces tendremos que hacer el lookup.
            if (mailSession == null) {
                InitialContext ic = new InitialContext();
                mailSession = (Session) ic.lookup("java:/futuramail");
            }
            MimeMessage message = new MimeMessage(mailSession);
            Address[] to = new InternetAddress[]{new InternetAddress(recipient)};
            message.setRecipients(Message.RecipientType.TO, to);
            message.setSubject(subject);
            message.setSentDate(new Date());
            message.setContent(msg, "text/html"); 

            // No es obligatorio, pero es bueno, indicar quien genera el mensaje
             message.setHeader("X-Mailer", "Mail generado por runando");

            Transport.send(message);
            Logger.getLogger(EmailEJB.class.getName()).log(Level.INFO, null, "Email enviado correctamente.");
        } catch (MessagingException me) {
            //me.printStackTrace();
            Logger.getLogger(EmailEJB.class.getName()).log(Level.SEVERE, null, ex);
        } catch (NamingException ex) {              
            Logger.getLogger(EmailEJB.class.getName()).log(Level.SEVERE, null, ex);
        }
    }
}

Ahora tendremos que configurar el JNDI Mail Session en nuestro contenedor de aplicaciones (weblogic , wildfly, jboss...)
Entramos en la consola de weblogic:

http://IPWEBLOGIC:port/console

En la opción de Services, subopción Mail Sessions, pulsamos sobre "configurar un email de sesión", siendo los parámetros:

Name: mail/miMailSession
JNDI name: mail/miMailSession
Username: miEmail@company.com
Password:  [password del usuario]
JavaMail Properties:
mail.smtp.starttls.enable=true
mail.smtp.port=587
mail.user=miEmail
mail.smtp.ssl.trust=smtp.company.com
mail.smtp.auth=true
mail.smtp.host=smtp.company.com
mail.smtp.password=[password del usuario]
mail.debug=True
username=miEmail@company.com
mail.from=miEmail@company.com
mail.smtp.user=miEmail@company.com
mail.transport.protocol=smtp

No olvidar seleccionar un servidor de destino al final del procedimiento, para que la sesión esté disponible.

Copyright © 2016 runando