1. Crear un proyecto Web (no importa la herramienta, son siempre iguales)
2. Configurar el web.xml indicándole que direcciones los pedidos (de alguna url) al servlet de jax-ws

<listener>
	<listener-class>
		com.sun.xml.ws.transport.http.servlet.WSServletContextListener
	</listener-class>
</listener>
<servlet>
	<description>## descripción del Servlet ##</description>
	<display-name>## nombre a mostrar entre los servicios ejecutándose en el servidor ##</display-name>
	<servlet-name>## nombre de referencia dentro del xml para el Servlet ##</servlet-name>
	<servlet-class>
		com.sun.xml.ws.transport.http.servlet.WSServlet
	</servlet-class>
	<load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
	<servlet-name>## nombre de referencia dentro del xml para el Servlet ##</servlet-name>
	<url-pattern>/##url_dentro_de_la_aplicacion_para_el_servlet##</url-pattern>
</servlet-mapping>

3. Crear un WEB-INF/sun-jaxws.xml que contenga:

<?xml version="1.0" encoding="UTF-8"?>
<endpoints xmlns='http://java.sun.com/xml/ns/jax-ws/ri/runtime' version='2.0'>
	<endpoint name='##nombre_de_la_aplicacion##' implementation='paquete.ClaseConAnotacionWebService' url-pattern='/url_asignada_al_servlet_del_webservice' />
</endpoints>

4. Configurar las clases que se desea publicar como WebService, con un @WebService
5. Descargar el jax-ws (la descarga es un jar, que al clickear muestra una licencia y al aceptar descomprime muchos archivos). Hay que copiar todos los *.jar dentro del directorio $CATALINA/lib
6. Al desplegar la aplicación web, dentro de un WAR, en el tomcat, el jax generará automáticamente los wsdl y todo archivo necesario para publicar el webservice.

Espero que con esto se entienda, links de referencia:

• http://mywheel.net/blog/index.php/2007/04/18/deploying-java-6-web-services-in-tomcat/
• http://mywheel.net/blog/index.php/2007/03/28/web-services-in-java-6/

El concepto de package en si es muy bueno, casi todos los lenguajes modernos lo tienen de una u otra manera, con un nombre u otro. Se utilizan para evitar coliciones de nombres entre diferentes espacios de nombres.

De tal manera, que en el package paypal puede existir la clase Payment y en el package AlertPay tener otra clase con el mismo nombre Paypal sin ninguna relación con la anterior y cohexistir en el mismo proyecto. Cuando hay una duda (ambiguedad) sobre que clase se esta utilizando basta con escribir el nombre entero de la clase, incluido el package a la que pertenece y listo.

Diciendo esto cualquiera podria ver que tienen cierta utilidad especialmente cuando se comienzan a mezclar codigos desarrolaldos en diferentes lugares (ala plugins) en un mismo proyecto y no se puede tener control sobre que dos desarrolladores no elijan nombres que entren en conflicto.

¿Pero que sucede con grails? Desde la versión 1.2.0 cuando se crea cualquier artefact (ya sea un controller, un dominio, un servicio, etc) y no se le especifica un package, aparece un warning diciendo que es aconsejable utilizar siempre un package al cual hay que contestar con yes, para poder seguir adelante.

Eso es algo bueno, pero por la forma en que funciona Grails los packages pierden un poco su sentido. No pueden haber dos clases de Dominio, ni dos clases Controllers que tengan el mismo nombre aunque esten definidas en packages diferentes! Se entiende esto dado que Grails utiliza los nombres de las cases para su “Convention Over Configuration” y de esa manera mapear facilmente los dominios a tablas con GORM, o las urls para acceder a los Controllers. (Aclaro que lo entiendo, y seguramente hay implicancias ténicas para que sea así, pero me gustaría se le encontrara alguna vuelta)

Mi caso puntual, que me motivo a escribir este post, es que estaba realizando un plugin para realizar pagos que tenía una clase de dominio llamada Payment, y debía utilizar este plugin en un proyecto que utiliza el plugin de Paypal el cual también tiene una clase de dominio llamada Payment.

Al incluir los dos plugins en un mismo proyecto y ejecutar la aplicación se genera el siguiente error:


org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'messageSource': Initialization of bean failed; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'transactionManager': Cannot resolve reference to bean 'sessionFactory' while setting bean property 'sessionFactory'; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'sessionFactory': Invocation of init method failed; nested exception is org.hibernate.DuplicateMappingException: duplicate import: Payment refers to both com.soluciones3f.tpv.Payment and org.grails.paypal.Payment (try using auto-import="false")


No investigaré como resolver este problema, simplemente cambiaré el nombre de mi clase para salir del paso y continuar sin problemas. Pero en todo caso es un problema latente que me gutaría encontrarle alguna solución.

Esto llevaría a pensar que, si igualmente voy a tener colision de nombres entre paquetes, ¿para que usar packages? El problema es que a veces queremos usar packages para order el código (dado que para usar packages se crean directorios.. esto lo ordena un poco y evita tener un unico directorio que mezcla Exceptions, Strategies, Utilites, etc en una sopa indistinguible) pero si alguna de estas clases que SI pertenecen a un package necesita usar una clase de dominio, que por lo que dije antes decidí no poner en un package… ahí esta nuevamente el problema.

Grails, o groovy si vamos al caso, heredan la limitación de Java de no poder hacer un import del package (default). Aquel package al que van a parar todas las clases sin package. En consecuencia no tengo forma de usarlas. Entonces, nuevamente, es muy recomendable usar siempre packages a pesar de que grails le quite un poco de sentido.

Por lo pronto, recomiendo ponerle package a todo, ya que tal vez nos puede ahorrar un dolor de cabeza si despues aparece un package que necesita usar lo que ya habia hecho antes, y si bien voy a tener que seguir coordinándome con el resto del universo para no tener dos clases con el mismo nombre, el esfuero que representa usar packages no es tan grande como para no hacerlo y desear que algún día se resuelva este problema.

Una de estas aplicaciones que estamos desarrollando con Grails tiene configurado el plugin de IVY; IVY es un manejador de dependencias que está dentro del paquete de herramientas de Apache; cuando intentamos hacer el upgrade (desde la versión 1.1 a 1.1.1) nos encontramos con una serie de errores:

Error executing script Upgrade: : java.lang.NoSuchMethodError: org.apache.tools.ant.util.FileUtils.createTempFile(Ljava/lang/String;Ljava/lang/String;Ljava/io/File;ZZ)Ljava/io/File;
gant.TargetExecutionException: : java.lang.NoSuchMethodError: org.apache.tools.ant.util.FileUtils.createTempFile(Ljava/lang/String;Ljava/lang/String;Ljava/io/File;ZZ)Ljava/io/File;
        at gant.Gant$_dispatch_closure4.doCall(Gant.groovy:331)
        at gant.Gant$_dispatch_closure6.doCall(Gant.groovy:334)
        at gant.Gant$_dispatch_closure6.doCall(Gant.groovy)
        at gant.Gant.withBuildListeners(Gant.groovy:344)
        at gant.Gant.this$2$withBuildListeners(Gant.groovy)
        at gant.Gant$this$2$withBuildListeners.callCurrent(Unknown Source)
        at gant.Gant.dispatch(Gant.groovy:334)
        at gant.Gant.this$2$dispatch(Gant.groovy)
        at gant.Gant.invokeMethod(Gant.groovy)
        at gant.Gant.processTargets(Gant.groovy:495)
        at gant.Gant.processTargets(Gant.groovy:480)
Caused by: : java.lang.NoSuchMethodError: org.apache.tools.ant.util.FileUtils.createTempFile(Ljava/lang/String;Ljava/lang/String;Ljava/io/File;ZZ)Ljava/io/File;
        at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:115)
        at org.apache.tools.ant.Task.perform(Task.java:348)
        at org.apache.tools.ant.taskdefs.Sequential.execute(Sequential.java:62)
        at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:105)
        at org.apache.tools.ant.Task.perform(Task.java:348)
        at Upgrade$_run_closure1.doCall(Upgrade:82)
        at Upgrade$_run_closure2.doCall(Upgrade:261)
        at gant.Gant$_dispatch_closure4.doCall(Gant.groovy:324)
        ... 10 more
Caused by: java.lang.NoSuchMethodError: org.apache.tools.ant.util.FileUtils.createTempFile(Ljava/lang/String;Ljava/lang/String;Ljava/io/File;ZZ)Ljava/io/File;
        at org.apache.tools.ant.taskdefs.optional.ReplaceRegExp.doReplace(ReplaceRegExp.java:326)
        at org.apache.tools.ant.taskdefs.optional.ReplaceRegExp.execute(ReplaceRegExp.java:527)
        at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:288)
        at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:105)
        ... 17 more

Básicamente el problema es que el script que ejecuta GRAILS pone en classpath en primera instancia nuestro directorio lib, en condiciones normales esto sería lógico (porque nuestra aplicación puede usar una versión más nueva de algo que GRAILS no usa) pero en estas condiciones resulta en un error del script conocido como Upgrade.groovy es por eso que terminamos ese error.

¿Cuál es la solución? Fácil, movemos a un directorio temporario todo nuestro directorio lib, ejecutamos upgrade y volvemos a mover todo al lugar donde estaba Tendremos la aplicación actualizada sin mayores problemas, jijiji.

La idea, no fue mía, fue obra y gracia de Google . Aquí el link original.

Lo interesante es que gracias al gran crecimiento que tuvo JBoss y su comunidad, Red Hat se vió interesada y compró la empresa. Atrás de eso, se construyó el JBoss Studio, una especie de Websphere hecho por y para JBoss. Pero, claro, para no descuidar la comunidad open source, el equipo de JBoss tambíen distribuye una pack de plugins que convierten al Eclipse es un paso intermedio entre JBoss IDE y Eclipse SDK pelado.

Si van a trabajar con Eclipse y JBoss, les recomiendo usar el JBoss Tools. Lamentablemente tuve algunos problemas para poder usarlo con el Ganymede (la última versión de Eclipse, 3.4), pero en la versión anterior me ha funcionado bastante bien.

Aquí el link para poder bajar todas las utilidades de jboss tools.

Obvio, aquellos que me conocen, saben perfectamente que soy un fan de MyEclipse. Lo soy porque más de una vez me ha sacado de aprietos. Me ha simplificado la vida. Seamos sinceros. Si algo te simplifica la vida, ¡por qué no agarrarlo fuerte!

En este próximo Tutorial les voy a contar cómo levantar en pocos pasos un JBoss. Debo aclarar que, al ser MyEclipse tan estandard, este mismo criterio se puede usar para cualquier Servidor de Aplicaciones de Java (sea Tomcat, Geronimo, Resin, etc).

Start up – ¿Qué será necesario?

• JBoss 4.2.2
• MyEclipse 6.01 (personalmente, prefiero el full bundle)
• JDK 1.5 (es la versión más probada y aceptada)
• Concepto: Deploy, del inglés, despliegue.

Paso a paso

1. Primero, lo primero, configuramos un Eclipse para este ejemplo.

2. Nos aseguramos de haber configurado un JDK, porque lo vamos a necesitar después.

3. Nos bajamos un JBoss. En este ejemplo yo bajé la versión 4.2.2-GA, pero es prácticamente lo mismo. La pueden bajar de la página de JBoss. Lo descomprimimos en algún lado y recordamos el directorio. Yo, la tengo en c:\windows\java\jboss-4.2.2.GA.

4. Dentro de nuestro Eclipse. Windows->Preferences->Server->JBoss->JBoss 4.x

Debemos activarlo (1.) y después definir el directorio dónde está el JBoss (2.) que para nuestro ejemplo, es el que descomprimimos en el punto 3.

5. Configuramos el JDK con el que se lanzará el JBoss. Comentario: el JBoss (tanto como otros Application Server) se ejecutan dentro de una máquina virtual de Java. Eso es, justamente, un JRE. Por ser un servidor de aplicaciones, necesita tener funciones de compilación y es por eso que es necesario configurarle un JDK. Básicamente, para dejarle al JBoss compilar Java.

6. Ahora, dentro de la ventana principal del Eclipse, podemos hacer Windows->Show View->Server y nos aparecerá como se indica en la figura, todos los servidores que tenemos configurados (en mi caso es un JBoss, pero obviamente podría ser cualquier otro)

7. Dentro de esta vista tenemos que hacer click derecho: “Manage Deployments” y nos permitirá agregar alguna aplicación. Las aplicaciones que MyEclipse nos dejará ejecutar en el servidor serán: EJB Project, Web Service Project, Web Project. No querrá hacer un despliegue de aplicaciones Java comunes u otro tipo de proyecto soportado por el eclipse.

8. Ahora bien, una vez que aceptamos eso. El MyEclipse mantendrá sincronizado nuestro código con el servidor y así nos simplificará mucho la vida. Tenemos que iniciar el JBoss para ver nuestra aplicación funcionar. Se puede iniciar, como todo en Java, en modo Debug (si queremos hacer depuración) como Normal (si queremos más performance).

9. ¡Listo! la aplicación debería estar funcionando perfectamente en el servidor. Si es una aplicación web, podríamos verla en un navegador. El puerto predeterminado de JBoss, es el 8080…

¡Disfruten!

En adelante les mostraré algunos trucos (tips, hints, ideas) para simplificar la tarea diaria de uso de Eclipse y permitir, al mismo tiempo, reducir los altos costos de aprendizaje que implican. En adelante cómo manejar un buen workspace y cómo hacer para que el compilador interno del Eclipse no nos genere conflictos con svn. El ejemplo está ilustrado con Eclipse 3.3, otras versiones deberían tener funciones similares pero quedan fuera de esta explicación.

¿Cómo preparar un buen workspace?

Al arrancar por primera vez un Eclipse, nos pasa que nos pregunta dónde vamos a querer tener nuestro workspace. Para el inexperto, eso podría significar solamente dónde va a poner Eclipse los proyectos Java. Como todo en Java, eso no es tan así. Lo que pasa es que Eclipse requiere guardar información temporaría, llamada metadata, y otros parámetros de configuración que solo dependerán de ese workspace.

En un comienzo podríamos pensar que es algo malísimo, porque tenemos un directorio muerto dentro de nuestra máquina con información que no entendemos. Pero no es así, ese directorio guarda información referente a los proyectos asociados, y es una genial alternativa para cuando uno trabaja con diferentes tecnologías o conjuntos de proyectos (imaginen que necesitan usar Java 6 para una aplicación, otra con Java 5 y otra con Java 1.4… ahora imaginen que cada una tiene diferentes configuraciones de variables y cuestiones directamente relacionadas con la configuración del Eclipse… esta información está toda guardada dentro del .metadata del directorio correspondiente al workspace). Podemos aprovechar esto para simplificarnos la vida.

1. Creamos 2 directorios directorio, ejemplo:
   c:\blog3f\src - dónde pondremos nuestros proyectos (o haremos un download de svn/cvs)
   c:\blog3f\ws - dónde apuntaremos el Eclipse
2. Configuramos un acceso directo a Eclipse, y dentro de las propiedades le agregamos a la linea de comando: “-data c:\blog3f\ws” sin las comillas.
3. Arrancamos el Eclipse, no preguntará dónde está el workspace, justamente, porque en el punto anterior le dijimos con el parámetro -data.
4. Configuramos ese workspace cómo nos guste.
5. Si queremos crear proyectos, recordar que la idea es que queden en c:\blog3f\src, entonces si queremos crear el proyecto Post1, en el asistente debemos ingresar tanto el nombre del proyecto (Post1) como el directorio dónde iría a dejarse (c:\blog3f\src\Post1)
6. Si queremos importar un proyecto (que sería el caso de algo que bajamos de svn/cvs) hacemos File->Import->Existing project into Workspace e indicamos el directorio (c:\blog3f\src). Nos dará la opción de seleccionar los poyectos existentes en ese directorio src.

Nota: recordar que si no hay un .project o un .classpath dentro del directorio del proyecto el paso 6, no encontrará el proyecto y habrá que simular un paso 5 apuntando al directorio que tiene faltantes el .project .classpath

¿Cómo evitar que los directorios .svn nos hagan un embrollo?

Si están acostumbrados a usar svn, les gusta el tortoise y entienden cómo funciona. Sabrán que un directorio .svn en cada directorio. El problema con esto es que Eclipse automáticamente los copia adentro del directorio compilado.

Si tenemos un directorio de compilación diferente a dónde tenemos el código fuente, terminará, el Eclipse, diciendole al svn que nuestro directorio compilado equivale a la rama de svn de nuestro código fuente. Dando diferente tipo de errores cuando queramos hacer un commit.

La alternativa es fácil, tienen que cambiar la configuración del workspace. Dentro de windows->preferences->java->compiler->building, miren la imagen,

En la próxima clase, cómo configurar un jboss con myeclipse, después @EJB 3 con cliente Swing remoto, después @EJB 3 persistencia (JPA)… sintonicen.

Introducción

DB2 es un motor de base de datos construido por IBM. En los últimos tiempos con mucha inversión se ha logrado posicionar dentro de las más grandes compañías del mundo. Principalmente porque aquellas empresas que tienen Mainframe/Cobol prefieren seguir contando con su proveedor de tecnología. Así es como IBM es la mejor opción.

Por otro lado, dentro de este mismo marco tecnológico, al usar IBM para base de datos, también se prefiere usar IBM para entornos de desarrollo de nueva generación. Es así como decide usarse WebSphere en estas ocasiones. El WebSphere es otra “grandiosa” herramienta de IBM de la que vamos a hablar en otra ocasión.

Problema

Cuando de Java se trata, es muy habitual necesitar una librería JDBC para acceder a una base de datos. Hay diferentes tipos de niveles JDBC y cada nivel tendrá su correspondiente driver y clase de implementación para la Conexión (java.sql.Connection). Los factores que yo considero graves a la hora de usar DB2 como base de datos desde Java son:

• En versiones antiguas de DB2 driver, era necesario instalar un listener (pequeño demonio en el servidor) que escuara los pedidos de JDBC, porque trabaja en un nivel no nativo. Este listener transformaría los pedidos remotos en bajo nivel, cuestión que DB2 lo interprete (o sea, el driver en el cliente es muy bobo y solo reenvia los pedidos e interpreta las respuestas)
• Las versiones antes mencionadas muestran errores coherentes y claros cuando hay problemas, sin embargo la descripción de los errores, en drivers nuevos,  son con códigos, pero códigos feos, que uno tiene que interpretar mágicamente. Ejemplo: SQLCODE: -401, SQLSTATE: 42818 para decirnos que los operadores no son compatibles.
• La actualización de los drivers. Mi peor problema. ¡No exsiten! es prácticamente imposible encontar un driver lisa y llanamente. Es necesario recorrer toda internet y bajarse un paquete integramente de drivers para DB2, descomprimirlo manualmente y, para colmo de males, descomprimir un .CAB para así sacarles los drivers necesarios para conexión.
• En lo que Java respecta, hay instalaciones de DB2 en dónde no funcionan bien algunos métodos de obtención de Metadata (DatabaseMetadata), para lo cuál también hablaremos en algún momento .

Solución

Probablemente si llegaron aquí es porque quieren algunas respuestas. Respuestas a nivel informativo, respuestas porque han tenido problemas similares a los mios o sencillamente porque ya agotaron todos los recursos que tuvieron disponibles. Lamentablemente cuando se trata de DB2 cada instalación es un mundo y decirles que tengo la solución es dificil… pero voy a hacerles algunas sugerencias que pueden ser útiles.

• Para bajar los drivers, hacerlo de este link (upd: nuevo link). Si les pide usuario, dense de alta, es gratis y no te llenan la casilla de Spam. Aviso, es un archivo de casi 300mb (gracias IBM por sobrecargar la red)
• Al bajar ese archivo, descomprimirlo en algún lado y buscar el archivo db2_v9_nt32_client.zip\CLIENT\image\db2\Windows\JDBC0001.cab (esto es en la versión que yo bajé). Ese archivo contiene algunos archivos .AAAAAA2677C3 borrar esta extensión, deberían quedar archivos .JAR y .ZIP. Estos son los drivers JDBC para DB2.
• Los errores son bastante habituales, pero no desesperen. Hay una genial página de IBM que supuestamente tiene detalle de todos los errores con una cierta descripción. DB2 Universal Database – SQL Messages.
• Cuando se intenta obtener información de MetaData, a veces es bueno no especificar el tipo de dato que estamos buscando (por ejemplo, si queremos ver la estructura de una tabla y nuestro acceso es a través de su sinónimo, mejor no indicar tabla, dejar que el driver traiga lo que crea conveniente)

Referencias

http://www.ibm.com/developerworks/db2/library/techarticle/dm-0512kokkat/#install

http://publib.boulder.ibm.com/infocenter/db2luw/v9/index.jsp?topic=/com.ibm.db2.udb.apdv.java.doc/doc/tjvjcccn.htm

http://uda.openlinksw.com/jdbc/mt/jdbc-db2-mt/

https://www14.software.ibm.com/webapp/iwm/web/preLogin.do?lang=en_US&source=swg-idsjs11

Conclusión

Espero haberles sido de ayuda… debo confesar que diariamente lucho contra esto. Creo que IBM hace un buen trabajo de bajo nivel, pero cuando tiene que poner un poco sobre el programador o usuario, se queda medio corto.

Los drivers de DB2 deberían estar super pulidos, hasta Oracle tiene unos drivers Excelentes.. pero más allá de eso prácticamente todas las comunidades opensource tienen drivers geniales. Hasta SQL Server da unos drivers excelentes. ¡A ver si aprendemos ibm!

• JDK = Java Development Kit, o sea, Kit de desarrollo para Java.
• JRE = Java Runtime Environment, o sea, entorno de ejecución de aplicaciónes Java.

Está claro, entonces, que tenemos que tener configurado un JDK si vamos a desarrollar. Justamente está previsto para la gente de Sun y es por eso que el Eclipse recien nos dará ayuda en linea, si tenemos configurado un JDK. Irónico es que, por default, el Eclipse venga configurado con un JRE.

Otra cosa importante es tener el compliance level en la misma versión que el JDK que estemos usando.

En adelante, describiré con cierto detalle cómo configurar un Eclipse correctamente para simplificar el desarrollo.

Asumimos para este tutorial que el que lo está leyendo sabe lo que es el Eclipse, lo tiene instalado y arrancado y puede seguir las instrucciones. Si no, nos dicen y haremos un nuevo post sobre cómo instalar el Eclipse y qué técnicas les recomendamos para sobrellevarlo .

1. Bajar un JDK
Para nuestro ejemplo, debemos tener instalado un JDK, eso se puede bajar directamente de la página de Sun. Ojo al piojo que queremos bajar el JDK Update y no otra cosa. Aquí una imagen.

Para los nuevos, una pequeña nota.

JDK 1.4 => JDK 1.4
JDK 1.5 => JDK 5
JDK 1.6 => JDK 6

2. Configurar el JDK dentro del Eclipse

Para configurar el JDK, tenemos que ir a la configuración del Eclipse. Para eso hacemos Windows->Preferences. Buscamos la opción Installed JREs.

Dentro de esta ventana, seleccionamos Add… y apuntamos a dódne tenemos instalado nuestro JDK. Hay que tomar mucha atención, estamos dentro de la opción Installed JREs y seleccionando un JDK para que sea agregado. Puede sonar confuso. Para mi lo es. Habría que preguntarle a la gente de Eclipse por qué lo hicieron de esta forma. Por favor, recordar, tenemos que agregar un JDK (y no un JRE). A modo de ejemplo, yo tengo mi jdk 1.6.01. Eso no requiere mayor atención.

3. Configurar el compliance level de Eclipse

Una vez configurado el JDK como JRE (si, ya dijimos es medio ambiguo), tenemos que asegurarnos que el Eclipse va a seguir nuestras versiones correctamente. Eso es, validar nuestro código como si fuera código del JDK correspondiente que tenemos. Si usamos un JDK 1.6, tenemos que tener el compliance level en 6.0. Si usamos un JDK 1.4, tenemos que tener el compliance level en 1.4. He aquí una pantalla.

4. El toque final

Para algunos es suficiente tener una ayuda de código en linea, para otros, es muy lindo ver una ventana dentro del Eclipse que nos de ayuda de los métodos. ¡Esto es posible! El Eclipse es una herramienta genial que nos permite hacer casi cualquier cosa. Para eso, en cualquier perspectiva que estemos, activamos la ventana JavaDoc. Tenemos que ir Window->Show View->Javadoc (o apretar Alt+Shift+Q, J)

Miren abajo para el juego final.

Como verán, con solo pararse arriba de cualquier método (que sea de la JDK, obviamente) nos dará una ayuda excelente para que podamos trabajar más tranquilos y con menos esfuerzo.

Hoy se me dio por instalar la ultima versión de Eclipse en mi computadora. Cuando lo ejecuto me dice que requiere Java igual o superior a 1.5, entonces fue momento de instalarlo.

El proceso es como cualquier otro al comienzo:

$ sudo apt-get install sun-java6-jre sun-java6-plugin sun-java6-fonts

El secreto es que luego no hay que olvidar de ejecutar:

$ sudo update-java-alternatives -s java-6-sun

de lo contrario es probable que aún este usando alguna otra máquina virtual.

Para asegurarnos de que estamos ejecutando la correcta, basta ejecutar en la terminal: “java -version”. En mi caso ahora dice Java version 1.6.0_03, sin embargo antes de ejecutar update-java-alternatives me decía 1.4.2 Blackdown lo cual me estaba dando muchos dolores de cabeza al no entender porque si habia instalado una versión 1.6 aun me decía 1.4

En fin, espero que a alguien esto le sea útil como me fue a mi.

Es así como hace cosa de unos meses encontré una herramienta genial para preparar JNDI dentro de una plataforma de pruebas JUNIT. La herramienta se llama jrUnitTestHelper. La he probado y me resultó sumamente útil. Me sorprendió también encontrar que la persona que mejoró esa herramienta tiene una interesante coleccción de otras utilidades.

Les sugiero a todos los javianos por ahí, tenerla en cuenta porque: No tiene sentido intentar reinventar la rueda. Si está hecho, usarlo, si se puede mejorar, mejorarlo. Si no, a quemarse la cabeza. Esta última opción es menos preferida, pero puede pasar.

The JavaRanch Codebarn – http://faq.javaranch.com/java/CodeBarn