Publica tu how-to

Dinos como hacer lo que sabes hacer, mándanos un email a wdonet@gmail.com y lo publicamos (dos días máximo) o si te interesa unirte al equipo de redactores, también háznoslo saber por correo.

Usando una conexión a base de datos distinta en un subreporte de JasperReports

Al incluir un subreporte en JasperReports por default éste utiliza la misma conexión a base de datos que el reporte maestro que contiene el subreporte.


Sin embargo, a veces es deseable que el subreporte se conecte a una base de datos diferente.


Una manera de lograrlo es la siguiente:

  1. Incluir el subreporte como cualquier otro
  2. Agregar un parametro, que en este ejemplo llamaré SUBREPORT_CONNECTION, con Parameter Class = java.sql.Connection , no usar prompt,Default value expression = java.sql.DriverManager.getConnection("jdbc:mysql://localhost:3306/base_de_datos", "usuario", "password")[Obviamente, editar la url para que coincida con el motor de BD usado, nombre de base, puerto, host y demas datos]
  3. En las propiedades del subreporte,Connection type = Use a connection expression,
    Connection expression = $P{SUBREPORT_CONNECTION}(o como sea que se le haya nombrado al parámetro del inciso anterior)
  4. Si al intentar generar el reporte, aparece un error del tipo "No suitable driver found for jdbc:mysql://localhost:3306/base_de_datos", puede funcionar agregar un parametro mas, que se cargue antes del de SUBREPORT_CONNECTION (en iReport se pueden acomodar el orden de los parámetros y ese es el orden de carga también), que no use prompt, que
    Parameter Class = java.lang.Classy con
    Default value expression = Class.forName("com.mysql.jdbc.Driver").getName()[O como sea que se llame la clase Driver del manejador de BD utilizado...]
  5. Por último, si aún con esto surge una excepción ClassNotFoundException para, en este ejemplo, com.mysql.jdbc.Driver, se puede copiar el jar al subdirectorio jre/lib/ext de donde se encuentre instalada la máquina virtual que use JasperReports para compilar los reportes.

Usando una base de datos SQLite en un proyecto de Symfony2

Para configurar una base de datos en un proyecto de Symfony2, se edita el archivo app/config/parameters.ini:


[parameters]
    database_driver   = pdo_sqlite
    database_host     = localhost
    database_port     =
    database_name     = test_project.db
    database_user     = root
    database_password = 


Sin embargo, con esta configuración, que es la default para usar cualquier otro motor de base de datos con Doctrine2 (incluido en cualquier instalación estándar de Symfony2), una base de datos SQLite no funciona.


Lo correcto es, primero, editar y agregar una línea en app/config/config.yml:



doctrine:
    dbal:
        driver:   %database_driver%
        host:     %database_host%
        port:     %database_port%
        dbname:   %database_name%
        user:     %database_user%
        password: %database_password%
        path:     %database_path%
        charset:  UTF8

Esta línea no se encuentra originalmente en el archivo, se agrega para que Doctrine utilice el parámetro 'database_path', que ahora se agrega a parameters.ini:

[parameters]
    database_driver   = pdo_sqlite
    database_host     = localhost
    database_port     =
    database_name     = test_project.db
    database_user     = 
    database_password = 
    database_path     = /path_to_my_project/app/db/test_project.db

Y con eso, la base de datos queda creada en el path establecido. Notar que para servidores Unix (Linux por ejemplo), este archivo debe quedar con permisos de lectura/escritura por parte del usuario que utilice el servidor web (cualquiera que este sea, http, www-data o lo que sea): Y el directorio donde reside el archivo tambien debe tener permisos de lectura, escritura y ejecución para este mismo usuario (en este caso, el subdirectorio db que yo puse aquí dentro de app/, pero en realidad podría residir donde más nos convenga).


Autowiring basado en anotaciones con Spring Framework

Autowiring se un método que tiene Spring Framework para inyectar de forma automática las dependencias entre clases (servicios, daos, controllers, etc).
Para cada DAO, agrega una anotación de nivel clase @Repository.

Estas anotaciones van en la clase de implementación y no en la intefaz.
import org.sringframework.stereotype.Repository;
@Repository("parametroDao")
public class ParametroDaoImpl implements ParametroDao {
    // ...
}
Para cada componente Servicio, agrega una anotacion de nivel clase @Service.
import org.springframework.stereotype.Service;
@Service("parametroService")
public class ParametroServiceImpl implements ParametroService {
    // ...
}
Para cada controller en Spring MVC, agrega una anotacion de nivel clase @Controller.

No te preocupes de proveer el nombre, no se necesita.
import org.springframework.stereotype.Controller;
@Controller
public class ParametroServiceImpl implements ParametroController {
    // ...
}
Hasta ahora no se ha cambiado nada a la aplicación, se pueden seguir teniendo los nombres de beans usados en la configuración manual, pero es recomendable compilar y construir el proyecto para revisar que no se haya afectado algo.

Una vez hecho lo anterior, hay que decirle a Spring dos cosas: dónde encontrar los nombres para nuestros beans y que estrategia usar para el autowiring.

Para definir donde encontrar los nombres de beans debemos usar el tag <context:component-scan> en el archivo de configuración del contexto de Spring.  Se debe declarar el namespace y schema location:
<beans xmlns="http://www.springframework.org/schema/beans"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:context="http://www.springframework.org/schema/context"
    xsi:schemaLocation="http://www.springframework.org/schema/aop
         http://www.springframework.org/schema/aop/spring-aop-3.0.xsd
         http://www.springframework.org/schema/beans
         http://www.springframework.org/schema/beans/spring-beans-3.0.xsd
         http://www.springframework.org/schema/context
         http://www.springframework.org/schema/context/spring-context-3.0.xsd
         http://www.springframework.org/schema/jee
         http://www.springframework.org/schema/jee/spring-jee-3.0.xsd
         http://www.springframework.org/schema/tx
         http://www.springframework.org/schema/tx/spring-tx-3.0.xsd">    
    <context:component-scan base-package="x.y.dao">
        <context:include-filter type="annotation"
            expression="org.springframework.stereotype.Repository"/>
    </context:component-scan>
</beans>

Las piezas importantes del xml anterior son xmlns:context, xsi_schemaLocation y <context:component-scan>.  Se le está diciendo a Spring que haga un escaneo (búsqueda) de componentes que tengan la aotación @Repository sobre el paquete x.y.dao y si a la anotacion usada se le coloca un valor textual, como en en nuestros casos anteriores del @Repository y el @Service, ése será el nombre a utlilizar como bean para el autowiring

Con la anotacion @Autowired aplicada a los atributos de las clases, se pueden evitar tener setters de dicho atributo, pero si tienes clases unitarias, necesitaríamos setter para inyectar mocks u otras implementaciones.

La convención es utilizar, como nombres de las propiedades que se pretende auto-inyectar, los mismos nombre del componente, lo cual nos permite eliminar los componentes Dao, Service y Controller del archivo de configuracion del contexto de Spring (xml) dado que la configuración ya se está dando en la misma clasa, mediante las anotaciones.

No obstante, sigue siendo recomendable configurar dentro del XML los objetos DataSource (la configuración del orígen de datos, es decir, la Base de Datos), SessionFactory (Hibernate o algún otro ORM) y TransactioManager (Para el control de las transacciones).

Referencia del entorno de programación en Unix

Resulta que recomendando un libro sobre programación en Unix, me encontré con esta referencia que puedes descargar desde el mediafire.com :

 http://www.mediafire.com/?hf3zzzmdwt3

Como referencia me pareció bastante buena, se las dejo para quien guste descargarla y si en algún momento el enlace está roto, me avisan para ver como repararlo.

Referencias:
=======================

El entorno de programación UNIX
Kernighan, Brian W.
Pike, Rob
Editorial Pearson
  • Del autor del PDF (Fernando Bellas Permuy).
  • Descargar capítulos del libro de Kerninghan aquí.