Desplegar una aplicación Grails en Glassfish (con Oracle 10g e Ingres)

Jueves, 3 de Diciembre de 2009

Una se pone a buscar información sobre como desplegar una aplicación grails que usa oracle 10g en glassfish  y no encuentra casi nada, y mucho menos si hablamos de algo referente a Ingres. Así que después de pegarme con esto unos días y con un resultado satisfactorio voy a aportar mi granito de arena con este post.

Una vez desarrollada mi aplicación en Grails (que pronto saldrá a la luz), la tengo que desplegar en Glassfish v2.1. Pronto empiezan a aparecer los primeros problemas, que explicaré junto con algunas particularidades de mi aplicación:

  • Mis tablas están en una base de datos de Oracle 10g y en un esquema determinado.
  • Además, mi aplicación depende de otras tablas de esa misma base de datos pero que están en otro esquema. A la información de estas tablas accedo a través de un Api, cuyo dataSource será el mismo que el de mi aplicación.
  • Pero hay más: mi aplicación depende de otra tabla, de una base de datos de Ingres, a la cual también accedo a través de otro Api con un dataSource distinto (evidentemente).
  • Para solucionar todo esto, tiro de Spring y del fichero “resources.xml” de la siguiente manera:
    • Para el problema del Api que usa el mismo dataSource que mi aplicación sólo tengo que importar su “applicationContext.xml”
<beans>
    <import resource="classpath:applicationContext.xml" />
</beans>
  • Para el problema del Api que usa un dataSource distinto al de mi aplicación sólo tengo que definir un nuevo dataSource, pasándole los datos de la conexión a la base de datos y un bean de la clase que gestiona el Api. A este último le paso el dataSource:
<beans>

<bean id="dataSourceIngres" class="org.apache.commons.dbcp.BasicDataSource">

    <property name="driverClassName" value="com.ingres.jdbc.IngresDriver" />

    <property name="url" value="jdbc:ingres://url/bbdd;cursor_mode=readonly" />

    <property name="username" value="username" />

    <property name="password" value="******" />

</bean>

<bean id="nameBean" class="beanClass" factory-method="getInstance">

    <property name="dataSource"><ref local="dataSourceIngres"/></property>

</bean>

</beans>
  • Todo esto, como ya he dicho, dentro de “myApp/grails-app/conf/spring/resources.xml“. Una vez hecho esto, podemos acceder a la información de todas las tablas sin ningún problema.
  • Cambio de tercio: La versión con la que empecé a desarrollar mi aplicación fue la 1.1.1 (stable release) y el plugin grails-ui 1.1-SNAPSHOT, este último porque uso gui-dataTables en mis listados. Con esta versión del plugin tenía problemas en la ordenación de las columnas de forma que cuando salió la release 1.1 me actualicé para comprobar que estos problemas estaban resueltos, pero a su vez me obligaba a actualizarme a la versión de grails 1.2-M2. Como mis problemas se  resolvieron y todo iba bien, así se quedó la cosa. Salieron nuevas “milestones” pero no iba a estar cambiando la versión de grails constantemente sin necesitarlo.
  • El gran problema llega a la hora de desplegar la aplicación. El GRAN PROBLEMA realmente son dos:
    • Por un lado, definiendo el datasource en producción utilizando jndiName = “jdbc/myDatasource”, no accedía  la base de datos.
    • Por otro lado, aunque definiese el datasource en producción pasándole los datos de la conexión (que así si accedía a base de datos) Glassfish se quedaba colgado continuamente, no se podían desplegar otras aplicaciones, no se podía hacer “undeploy”….
    • Después de probar varias cosas e ir de un lado para otro decidimos volver a la versión 1.1.2 que es la última estable y el GRAN PROBLEMA se resolvió. También probé con la última versión “milestone” de grails, la 1.2-M4 y tampoco hay ningún problema, pero prefiero dejar mi aplicación en producción con una versión estable ya que todo funciona a la perfección.

Conclusión: hemos dado muchas vueltas, cuando, en definitiva, la solución era una tontería. Elegimos el camino equivocado pensando en que el problema estaba en la definición de los datasources y en Oracle, en parte porque hemos encontrado poca información al respecto. Por eso, insisto, escribo esta laaaaaarga entrada en mi blog, para que a alguien le pueda servir, al menos, para ahorrarse un poquito de tiempo.

Fátima Casaú Pérez Groovy & Grails

Inyectar un Datasource Ingres en Grails

Miércoles, 30 de Septiembre de 2009

Estos días me he encontrado con la necesidad de inyectar un datasource a un Dao de una librería externa a mi aplicación, siendo éste, un datasource distinto al de mi aplicacion y a través del cuál se establece una conexión a una base de datos de INGRES. De primeras…suena mal pero luego resulta ser muy sencillo.

Respecto a que sea INGRES y no otro gestor de BBDD más común como ORACLE o MySQL … ningún problema. Ni siquiera si este va a ser el gestor de la  BBDD de la aplicación. En su día me encontré con este caso y tampoco tuve problemas, tan sólo alguna incompatibilidad con algún tipo de datos pero nada importante.

Sobre a que haya que utilizar otro datasource distinto al de mi aplicación, ningún problema tampoco, se le llama de otra forma y listo. Y finalmente, ¿Cómo o dónde inyectarlo? Pues he echado mano del resources.xml y ahí me he definido el datasource y el bean que hace referencia al Dao:

resources.xml


<?xml version="1.0" encoding="UTF-8"?>

<beans xmlns="http://www.springframework.org/schema/beans"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.0.xsd">

<bean id="dataSourceIngres">

<property name="driverClassName" value="ca.ingres.jdbc.IngresDriver" />

<property name="url" value="jdbc:ingres://DATABASE" />

<property name="username" value="USERNAME" />

<property name="password" value="PASSWORD" />

</bean>

<bean id="ingresDao" factory-method="getInstance">

<property name="dataSource"><ref local="dataSourceIngres"/></property>

</bean>

</beans>

y por último se hace un getInstance() del Dao y se llama al método que corresponda pasándole los argumentos que sean necesarios

Fátima Casaú Pérez Groovy & Grails

Usando jquery (incompatibiladad entre prototype.js y grailsUI 1.1-SNAPSHOT)

Viernes, 18 de Septiembre de 2009

Siendo sincera, hasta que no me he visto en la necesidad no me he puesto a utilizar jquery aunque si me lo había planteado.

El motivo ha sido una incompatibilidad que hay entre la librería prototype.js y Grails-UI 1.1-SNAPSHOT y es que estaba intentando hacer un formulario de búsqueda con selects encadenados o dependientes unos de otros y que a su vez, se mostrara el resultado en un gui:datatable. Necesitaba prototype porque estaba realizando una llamada en el “onchange” del “select” utilizando “${remoteFunction(…)}” El problema es que la tabla no se carga y sólo salía “Loading…” además del siguiente error javascript:

too much recursion } else if (isArray(input)) {  //grailsui.js (line 48)  (ver error)

Total, que después de dar vueltas por google y de consultar en la lista de correo llegué a la siguiente conclusión:

1- Usar jquery

2-Volver a Grails-UI 1.0.4 (en esta versión no existe el problema)

Y como no iba a volver atrás en el tiempo pues decidí utilizar jquery y este es el resultado:

searchForm.gsp


<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
<meta name="layout" content="main" />
<g:javascript library="jquery-1.3.2" />
<script>
$(document).ready(function() {
$("#personSelect").change(function() {
$.ajax({
url: "/persons/search/loadAddress",
data: "id=" + this.value,
cache: false,
success: function(html) {
$("#addressSelect").html(html)
}
});
});
});
</script>
</head>
<body>
>[...]
<g:form>
<div>
<table>
[...]
<td valign="top" class="value ${hasErrors(bean:person,field:'userRealName','errors')}">
<g:select
id="personSelect"
optionKey="id"
from="${Person.list()}"
name="personSelect" value="">
</g:select>
</td>
><td valign="top" class="name">
<label for="address">Address:</label>
</td>
<td valign="top" class="value ${hasErrors(bean:address,field:'description','errors')}">
<div id="addressSelect">
<g:select noSelection="${['null':'Select One...']}"
optionKey="id"
from=""
name="addressSelect" value="">
</g:select>
</div>
</td>
[...]
</table>
</div>
</g:form>
<div>
<gui:datatable> [...] </gui:datatable>
</div>
</body>

</html>

searchController.groovy

def loadAddress = {

def address = []//Address.findByPerson(params.id)

if(address.size()==0){

render """<select id="addressSelect" name="addressSelect"><option value="-1">- Select One -</option></select>"""

}else{

render g.select( optionKey:'id', from: address, id: 'addressSelect', name: "addressSelect")

}

}

y esto es todo.

Seguiré indagando en jquery

Fátima Casaú Pérez Groovy & Grails

Grails 1.2. M2 Released

Miércoles, 12 de Agosto de 2009

La versión de #Grails 1.2. M2 ya está fuera. Podemos encontrar sus “released notes” y “new features” en http://www.grails.org/1.2-M2+Release+Notes y podemos descargarlo en: http://www.grails.org/Download

Destacar que es la primera release que integra la última versión de Spring 3 soucecode y que además podemos utilizar etiquetas de Spring del tipo @Service, @Component, @Controller. De esta forma con @Component podemos convertir una clase en un bean de Spring e inyectarlo en otras clases, o con @Controller podemos convertir un controller en un Spring MVC Controller y conbinar Spring MVC con Grails.

Todavía no lo he probado así que habrá que ponerse a ello

Fátima Casaú Pérez Groovy & Grails

#Grails – gui:dataTable con imágenes

Martes, 11 de Agosto de 2009

Tenemos un proyecto grails, en el que estamos utilizando, como no, los plugins yui y grails-ui. Nos disponemos a implementar las típicas pantallas de administración en las que se gestionan recursos de una aplicación de forma que se dan de alta, de baja, se modifican, se insertan, se borran… A la hora de mostrar los listados, una manera fácil y rápida de hacerlo es utilizando las gui:dataTables con las que con sólo una closure de un controller y una gsp muy sencilla, tenemos un listado paginado de los objetos de una clase del dominio. Por ejemplo:

Clase del dominio:

</code></code>

class Person {

String name

Integer age

String state

static constraints = {

}

Controlador:

</span></span>

<span style="font-family: -webkit-monospace"> </span>def listPersonsAsJSON = {
def personList = Person.list(params)
response.setHeader("Cache-Control", "no-store")
def list = personList.collect {
[
id: it.id,
name: it.name,
age: it.age,
state: it.state,
dataUrl: g.createLink(action: 'show') + "/$it.id"
]
}
def data = [
totalRecords: Person.count(),
results: list
]
render data as JSON
}

gsp:

<gui:dataTable</code></code>

draggableColumns="true"

id="listPersons"

columnDefs="[

[key:'id', sortable:true, resizeable: true, label:'ID'],

[key:'name', sortable:true, resizeable: true, label:'NAME'],

[key:'age', sortable:true, resizeable: true, label: 'AGE'],

[key:'state', sortable:true, resizeable: true, label: 'STATE']

]"

sortedBy="name"

controller="person" action="listPersonsAsJSON"

paginate="true"

rowClickNavigation="true"

rowsPerPage="5"

/>

Y este es el resultado:

dataTabale sin imágenes

... pero la forma de mostrar el estado... es un poco cutre, quedaría mejor con una imagen que refleje el estado.

El problema es que si intentamos buscar como insertar una imagen en un gui:dataTable, casi no encontramos nada, más bien, parece que no se puede hacer y cuando en un principio pensaba que tenía que recurrir a lo que hay por debajo, es decir, yui:dataTable, probé lo más tonto: poner en la lista que me defino en el contralador, en lugar del valor del estado, un tag <img> con la url de la imagen que quiero mostrar en función del estado que me venga:

def list = personList.collect {
def state=""
if(it.state=="Y"){

state="img src='${createLinkTo(dir:'images',file:'accept.png')}'/"

}else{

state="img src='${createLinkTo(dir:'images',file:'delete.png')}'/"

}

[
id: it.id,
name: it.name,
age: it.age,
state:state,

dataUrl: g.createLink(action: 'show') + "/$it.id"

]

}
Y lo que en un principio parecía una tontería que no iba a funcionar ...
pues aquí está:
dataTable-con-imagenesfacilísimo

Fátima Casaú Pérez Groovy & Grails

Mi blog y Twitter

Martes, 11 de Agosto de 2009

Poco a poco mis entradas de blog irán apareciendo en twitter o eso espero.

Fátima Casaú Pérez General

Nuevo diseño de grails.org

Martes, 28 de Julio de 2009

Tenemos nuevo diseño de la página de Grails.

El contenido aparentemente es el mismo, pero tiene un diseño más vistoso e intuitivo. La parte de búsqueda de plugins está bastante mejor y más accesible donde podemos encontrar los plugins clasificados por categorías (destacados, más populares, nuevos, últimos modificados, …) así como la posibilidad de buscar un plugin por texto. En esta pantalla también encontraremos accesos directos a:

Para comprobar todo esto hay que acceder a la página y echarle un vistazo

Fátima Casaú Pérez Groovy & Grails

Introducción a GRAILS

Lunes, 20 de Julio de 2009

Grails es un framework de código abierto intuitivo y fácil de usar, para el desarrollo de aplicaciones web que llega como una revolución en este campo. Sigue los principios “don’t repeat yourself” o “DRY” y “convention over configuration” o “CoC“, es decir, evitar la repeticion de fragmentos de código para evitar inconsistencias y favorecer la claridad, así como, reducir todo lo posible los aspectos configurables de una aplicación.

Está desarrollado sobre el lenguaje Groovy, el cual, a su vez, está basado en la plataforma Java ofreciéndonos una modelo de capas MVC , además de ofrecernos otras capas como una capa de persistencia y una  capa de servicos. Otras ventajas:

  • Es un productivo framework para la Java Platform.
  • Proporciona la reutilizacion de tecnologías java como Hibernate o Spring en una simple y consistente interfaz
  • Proporciona un completo modo de desarrollo que incluye el servidor web y además, no hace falta volver a ejecutar la aplicacion para recargar sus recursos, según se van haciendo cambios.
  • Además, se pueden incluir numerosos plugins que complementan todo esto. Algunos de ellos son : Grails-ui, yui, bubbling, acegi, jasper-report … Además, al ser de código abierto, podemos crear nuestros propios plugins y publicarlos.

Tenemos varias vías a través de las cuales podemos interactuar con otros usuarios de grails para enviar “feedbacks”, dudas, problemas, errores en el código … Como ejemplos tenemos:

  • Lista de correo de grails: http://www.grails.org/Mailing+lists
  • Jira: http://jira.codehaus.org/browse/GRAILS . Más adelante hablaremos de Jira. Como resumen, comentar que es es una aplicación diseñada para mejorar el proceso de dar seguimiento a los defectos y errores, es decir mantener la trazabilidad de la información, así como administrar y manejar proyectos no solo de desarrollo de software sino de cualquier tipo de situacines que maneje la organización. En concreto en Grails podemos crear “issues” con los errores que encontremos sobre grails o cualquiera de sus plugins para que así vayan solucinándose en posteriores versiones. Debido a esto, y a que Grails es relativamente reciente, tanto las versiones de Grails como las de sus plugins cambian con frecuencia.  Además, se liberan versiones no definitivas (SNAPSHOT) para que los usuarios puedan probarlas  y reportar errores.

Dos paginas muy útiles y que tenemos que tener muy presentes a la hora de programar aplicaciones en grails son:

En resumen, este framework facilita de una forma clara, sencilla e intuitiva, el desarrollo de aplicaciones. Y por último decir que Grails es “cool” e “impresionante” ;-)

Espero que el post sea de interes y posteriores entradas iré comentando con ejemplos como crear aplicaciones, utilizar plugins, así como los problemas que me surjan en mi trabajo diario y como salgo, satisfactioriamente o no, de ellos.

Fátima Casaú Pérez Groovy & Grails

Reflexiones…

Lunes, 13 de Julio de 2009

Me costó decidirme hacer un blog y me ha costado volver a escribir en él. Los motivos darán igual o no, pero tampoco los voy a contar.

La cuestión es que desde ese momento hasta ahora he tenido que reflexionar sobre dónde empecé, dónde estoy y hacia dónde voy en mi vida profesional. Así que voy a aprovechar todo esto y este blog para hablar sobre las cosas que he aprendido, las que voy descubriendo y las que me quedan por descubrir.

Desde un primer momento, tenía claro que me quería dedicar al desarrollo de aplicaciones web y tuve la suerte de encontrarme en el camino con personas que me han ayudado bastante (y lo siguen haciendo).  Así que mi primer contacto con este mundo fue al incorporarme al desarrollo de una aplicación desarrollada en Java utilizando arquitectura J2EE, Struts, Spring, Ajax, Dojo… en definitiva, un montón de cosas que me sonaban a chino prácticamente todas, pero que poco a poco fui entendiendo y aprendiendo a utilizar.

Voy a hacer un brever resumen de todo esto, tampoco me voy a enrollar con explicaciones que para eso ya está google.

Java es un lenguaje Orientado a Objetos (O.O.P.), una forma distinta de trabajar pero más sencilla y  estructurada, (sobre todo, cuando los lenguajes que se han aprendido en la universidad son lenguajes estructurados como C#)

J2EE es una plataforma para el desarrollo de aplicaciones web en Java cuyos componentes se organizan en una arquitectura de capas y dicha aplicación se ejecutará en un servidor de aplciaciones.

Struts es un framework para el desarrollo de aplicaciones web bajo la plataforma J2EE y que sigue la arqutectura de Modelo-Vista-Controlador (MVC).

Spring es otro framework de código abierto para el desarrollo de aplicaciones web.

Ajax es una técnica, que utilizada en el desarrollo de aplicaciones web permite al cliente interactuar con el servidor de manera asincrónica, actualizando el contenido de las páginas, sin necesidad de volver a cargarlas.

Dojo es otro framework para facilitar el desarrollo de aplicaciones web que utilizan Ajax

… y más cosas … así que la mejor forma de entenderlo es con un pequeño ejemplo práctico:

http://cwiki.apache.org/S2WIKI/struts-2-spring-2-jpa-ajax.html

Este es un buen ejemplo para familiarizarse con todo esto aunque las versiones de struts, spring … son “old versions”, en sus correspondientes páginas se pueden encontrar sus “release” o versiones liberadas.

Lo mejor para aprender es crearse projectos paso a paso y hacer pruebas, ya que por mucha teoría que se lea, si no se prueban las cosas no se entienden del todo. Además, llega a aburrir y se puede perder el interés. Lo digo con conocimiento de causa. Aunque casi no tengo experiencia, sí que me ha tocado dar un par de veces un curso básico de J2EE y los alumnos, cuando se les cuenta teoría pierden la atención y se aburren, además, perciben la sensación de que no se enteran de nada.

Conclusión: este fue mi primer contacto. A partir de ahí, cada día se presentaba algo distinto que hacer y que aprender (dentro del desarrollo de una misma aplicación). No todo se sabe de memoria, o simplemente no se sabe. Hay que buscar información y probar y además, no sólo hay que quedarse con la primera solución ya que no tiene por qué ser la mejor.

… y seguiré reflexionando…

Fátima Casaú Pérez General

Mi primer POST!!

Lunes, 23 de Marzo de 2009

Me ha costado unos días decidirme y por fin me dispongo a escribir mi primer post en mi primer blog siguiendo el ejemplo de mis compañeros de Salenda, Daniel Ortega y Álvaro Sánchez.

Como ya he dicho, pertenezco a Salenda y desde hace más de un año trabajo como desarrolladora y también he impartido algún que otro curso sobre J2EE. Si miro hacia atrás, un par de meses antes de entrar a trabajar, no había hecho nada más que terminar las asignaturas de Ing. Tec. en Informática en la Carlos III y no sabía absolutamente de nada, por mucha carrera que haga una, por muy pronto que se aprueben las asiganturas y por mucha Carlos III. Así que todo lo que sé lo he aprendido aquí y haciendo un repaso, resulta que no es tan poco. Éste es el motivo de escribir este blog, hablar de lo que voy aprendiendo en mi trabajo diario, que problemas me surgen y como salgo victoriosa o no de ellos. Quizá debería haber empezado a escribir hace tiempo, pero bueno, nunca es tarde…

Fátima Casaú Pérez General