Bosco Curtu

Archive for the ‘TempAlias’ Category

Resulta que estas Navidades estoy bastante ocioso por casa y he recuperado el proyecto de TempAlias (ver etiqueta) con la intención de instalarlo en un entorno real.
Primeramente me lo he descargado en local, y ha funcionado sin ningún problema (eso si, introduje demasiada configuración para gerónimo y ahora me arrepiento)
A continuación he buscado un VPS (Virtual Private Server) asequible. He probado primeramente con el de arxanet (desde 7 euros) pero he desistido porque al intentar registrar mi dominio resulta que su servicio de whois fallaba, y decía que todos los dominios .com y .net estaban ocupados. Así que lo he dejado por ahora
Después he descubierto e-xperta, por 8 euros al mes, y además me permiten probarlo gratis durante una semana.
Me he registrado pensando que hasta mañana no iba a saber nada,y sorpresa, en seguida me han dado un usuario y password para acceder a mi máquina virtual en un periquete.
La verdad que tiene muy buena pinta, vamos una máquina linux, un usuario root, una cuenta de scp… Perfecto para hacer todo lo que uno quiera. Pero cuando por fin me he bajado todo a la máquina (james, tomcat, java y war) han empezado los problemas
He intentado instalar java SE 6, la ultimísima versión de java, recien estrenada. Y ha fallado. Parece que necesita mucha memoria para correr, y el VPS de prueba no tiene suficiente (tiene algo más de 100MB libres!)
Entonces me he bajado el java SE 5.0, este si he podido instalarlo.
A continuación he arrancado james.
Pero cuando he intentado correr tomcat, nada de nada. No puede arrancar por falta de memoria… Y hasta aquí he llagado hoy, mañana continuaré, pero pinta mal el asunto. Parece que voy a necesitar 256 MB de RAM para arrancar el invento…

Mañana más…

Joder!!!!!!!
Mirad lo que acaban de publicar en microsiervos!
Es una aplicación parecida a mi tempalias, genera direcciones de correo que duran 10 minutos!
La diferencia con la mía, es que estas son direcciones reales, es decir, tienen buzón web propio. En mi tempalias, lo que se genera es un alias para tu buzón de correo. Además en tempalias el tiempo es configurable. Claramente es mejor el mío (snifff)
De todas formas, debo plantearme subirlo ya a producción
Que rabia

Finalmente has salido la versión 2.3.0 de JAMES, el servidor de correo que utilizo en mi proyecto TempAlias. Debo probarlo y posiblemente migre el proyecto a esta versión, más que nada porque espero que sea más rápido, es el inconveniente más gordo que he podido veer(espero que no tenga ninguna incompatibilidad, porque casi no tengo tiempo para pelearme)
También aprovecharé para instalarlo todo en el servidor virtual que miré y así lo publico realmente en internet y lo probamos. Ya falta menos para hacer rico: mis minolles!!. Ahora solo falta que telefónica me de de alta mi línea para que pueda contratar ADSL.
Y esa es otra historia. Como muy bien contaba mi amigo el Sr Acido en su blog “Vivir sin Internet“, nuestros técnicos telefónicos no hacen más que superarse en su incompetencia.
Resulta que me di de alta el telefónica, ya que sale gratis. Eso fue el 23 de Septiembre (hoy es 7 de Noviembre!). Bueno, todo hay que decirlo durante unas horas tuve internet. Fue el día 2 de noviembre, entre las 5 y las 9 de la noche, es decir, cuando el instalador hizo su prueba, y después, yo hacia las 9, lo volví a probar. Funcionaba bien, lo juro.
Nadie sabe por qué, el 3 de noviembre ya no tenía línea. Porque???!?!??!!?!!!
En fin, el operador del 1002 (averías telefónicas) encima me amenazó diciendo que si tiene que venir un técnico a mi casa para resolver la avería me cobrarán 30 euracos. Pero qué culpa tengo yo!!!!!!
Pues eso, atando cabos. Te das de alta gratis, haces la prueba y funciona. Al día siguiente se estropea, y viene el técnico y pagas 30 euros. Joder, si lo que quieren es cobrarnos por el alta que no hagan ofertas de alta gratis! Que digan 30 euros por el alta. Vale! Lo pago! Pero no me toméis el pelo! uffffff

Qué son cada uno de estos xml files, también conocidos como Deployments plans:

• application.xml: Enumera los diferentes ejbs que hay dentro del ear. una lista de ficheros.jar y wars
• geronimo-application.xml: contiene el nombre que le das al ear dentro del application server, versiones y otros datos. Importante es el tag dependencies que indica que debe utilizar las librerías externas situadas en shared/lib (ver post)
• ejb-jar.xml: Aquí se declaran los ejbs (session y entity), sus classes, y así como los recursos adicionales
• openejb-jar.xml: En este fichero lo más interesante es la etiqueta jndi-name, que declara el nombre del ejb que tendrá en jndi

En este post hablaré de la estructura que debe tener el fichero .ear:
servicio.ear:
-META-INF
—-application.xml
—-geronimo-application.xml
—-MANIFEST.MF
-servicio.jar
-otros_ejb.jar

Dentro de los jars (las implementaciones de los ejbs) encontraremos algo parecido:
-META-INF
—-ejb-jar.xml
—-openajb-jar.xml
—-MANIFEST.MF
-com.comp.service.. (carpetas de las classes java de tu ejb)
-applicationContext.xml (para Spring)
-resources.xml (otras historias que neceistes)

Bueno, voy a escribir una serie de posts acerca de como crear EJBs 3.0 usando Spring y Geronimo como App Server.
Para empezar voy a hacer un comentario sobre librerias (.jar) necesarias para tu aplicación. Es posible que necesites librerías externeas, como mínimo spring.jar. Si la pones en tu ear, parece que Geronimo no la incluye en el classpath ( a no ser que modifiques el MANIFEST.MF)
Para que las coja bien hay que copiarlas en la carpeta geronimo-1.1/var/shared/lib
Reinicia Gerónimo, y ya podrías hacer el deploy de tu ear (en el siguiente post veremos que necesitas para crear el ear)

He bajado el Geronimo Application Server de Apache, para probar que tal funciona, ya que está an la versión 1.1 y puede ser interesante conocerlo como alternativa a JBoss, que es el típico. Para el proyecto que estamos utilizando no es necesario, ya que con un tomcat es suficiente y menos complejo, sin embargo hay que ir conociéndolo para futuras applicaciones, ya que es probable que termine convirtiendose en un standard

Para empezar voy a mostrar los scripts que he creado para arrancarlo, pararlo, deploys… no son los mejores ni los más bonitos, básicamente utilizan los scripts que vienen con Gerónimo, pero bueno, si vas  justo de tiempo puedes hacer un copy paste de ellos, que seguro que funcionan. Ya saldrá algún friki  que los optimice, de mientras yo uso estos:

    <target name="init">
        <taskdef resource="net/sf/antcontrib/antcontrib.properties">
            <classpath>
                <pathelement path="${ utils.dir}/ant-contrib.jar"/>
            </classpath>
        </taskdef>
    </target>

    <target name="geronimo-start" depends="init" description="Starts Geronimo app server">
        <if>
            <http url="${geronimo.url}"/>
        <then>
            <echo level="info">Geronimo is already running</echo>
        </then>
        <else>
            <echo level="info">Starting Geronimo (it can take up to some minutes, it depends on your machine)…</echo>
            <exec spawn="true" dir="${ geronimo.home}" executable="${geronimo.bin}/${geronimo.start}">
            </exec>
         </else>
         </if>  
    </target>  

    <target name="geronimo-stop" depends="init" description="Stops Geronimo app server">
        <if>
            <http url="${geronimo.url}"/>
        <then>
            <echo level="info">Stopping Geronimo…</echo>
            <exec dir="${geronimo.home }" executable="${geronimo.bin}/${geronimo.stop}">
                <arg value="–user=${geronimo.user}"/>
                <arg value="–password=${geronimo.pwd}"/>
            </exec>
        </then>
        <else>
            <echo level="info">Geronimo is not running!</echo>
         </else>
         </if>  
    </target>  

    <target name="geronimo-restart" depends="geronimo-stop,geronimo-start" description="Restarts the app server"/>

    <target name="geronimo-deploy" depends="geronimo-start,prepare_release" description="Deployin webapp in geronimo">
        <echo level="info">Deploying ${basedir}/${ dist.base}/${proj_name}.war</echo>
        <exec dir="${geronimo.home}" executable="${geronimo.bin}/${geronimo.deploy}">
            <arg line="–user ${geronimo.user} –password ${geronimo.pwd} deploy ${basedir}/${dist.base}/${proj_name}.war"/>
        </exec>
    </target>  

    <target name="geronimo-undeploy" depends="geronimo-start" description="Deploying webapp in geronimo">
        <echo level="info">Undeploying ${proj_name}</echo>
        <exec dir="${geronimo.home}" executable="${geronimo.bin}/${geronimo.deploy}">
            <arg line="–user ${geronimo.user} –password ${geronimo.pwd} undeploy ${proj_name}"/>
        </exec>
    </target>  

Bueno, vuelvo a hacer un resumen sobre el proyecto, porque ha cambiado bastante desde la última vez.

Para empezar, la localización del proyecto. He movido la última revision de la branch (54) otra vez al trunk, ya que he completado el Milestone 2,y habian ciertos cambios importantes (Hibernate…)  que ya eran interesantes de llevar al trunk.
Para descargarlo, utilizando Eclipse y Subclipse, hay que hacer un checkout del proyecto desde la url:

El proyecto empezó utilizando JDBC, pero lo he migrado  a Hibernate, y he deprecado la implementacion JDBC.

El proyecto trabaja con (entre otros) Spring 2.0, JSP 2.0, Hibernate 3, James Email Server, jCaptcha, XFire y Annotations (JSR 220, 181 y 175)

Para hacerlo funcionar:
0. Baja e instala Java 5 (sin NetBeans, please)
1. Baja e instala James
2. Baja e instala Tomcat 5.5
3. Baja e instala Eclipse (3.x)
4. Baja e instala Subclipse
5. Bajate el código
6. Copy-paste template.properties, renombralo como user.properties y cambia los valores
6. Ejecuta la tarea start-james-db
7. Ejecuta la tarea deploy
8. La aplicación estará en http://127.0.0.1:8080/tempalias/

Bueno, pues hoy he alcanzado el milestone 2 del proyecto, al añadir la posiblidad de autogestionarse los alias, e introduciendo un formulario de login. En este post explicaré como gestionar el login de una forma más o menos interesante.

Existen varias formas, la clásica es utilizar el login propietario del application server, como se define en la especificación de las webapps de sun. Sin embargo esta solución no es demasiado práctica, ni portable a diferentes appd servers, ni te permite acceder de manera directa a los objetos desde tu código.

Otra solución, la que está más de moda y se supone que es la más potente, es utilizar Acegi. Acegi es un framework para gestionar todo el mecanismo de login, autentificación y autorización, muy flexible y que se integra facilmente con  Spring. JA! Es un infierno integrar Acegi, no lo entiende ni el tato. Yo lo utilicé en un proyecto (lo integró el arquitecto de entonces) y lo he vuelto a reintentar integrarlo en este y ha sido imposible. Tampoco le dediqué demasiado tiempo, es verdad, pero cuando el tutorial de Acegi te dice que más o menos el proceso de aprendizaje dura una semana, se te quitan todas las ganas de seguir. Eso es sencillo? Además, tampoco veo claras las enormes ventajas de utilizarlo. De todas formas, si alguien sabe manejarlo agradecería que intentara integrarlo en este proyecto, ya que debería ser muy sencillo, y de esta forma aclararnos un poco su uso.

La tercera solución, que es la que he utilizado es una solución AOP, basada en Spring. Se basa en crear un interceptor que se active cuando se trata de entrar en las páginas protegidas. Para ello creamos un nuevo UrlMapping (puede haber más de uno!):

    <bean id="secureUrlMapping" class=" org.springframework.web.servlet.handler.SimpleUrlHandlerMapping">    
        <property name="interceptors">
            <list>
                <ref bean="signonInterceptor"/>
            </list>
        </property>
        <property name="mappings">
            <props>               
                <prop key=" /edit.htm">editAccountController</prop>
            </props>
        </property>
    </bean>

    <bean id="signonInterceptor" class=" com.bcurtu.web.SignonInterceptor"/>

¿Qué significa? Pues que cuando queramos acceder a /edit.htm, se ejecutará el código de SigonInterceptor. Esta clase (hereda de org.springframework.web.servlet.handler.HandlerInterceptorAdapter) implementa el método preHandle, que simplemente mira a ver si existe una variable Account en la Session. Si existe, todo sigue su curso y se carga el formulario edit.htm. Si no existiera, cargaría el formulario de login. En ambos casos, el código resultante ya es código normal de la aplicación, por lo que no requiere más explicación.

Comparando esta solución (añadir un bean más a la aplicación y tratar el login programáticamente) con el uso de Acegi, esta solución es infinitamente más sencilla. Pero hay que decirlo todo, el nivel de seguridad de esta aplicación, uso de un único perfil y demás, es muy sencillo. Para problemas más complicados de uso de perfiles, Acegi podría ser interesante. Para aplicaciones sencillas, viva Spring y sus interceptores!

1.- Bájate la distribución de spring 2.0 (actualmente RC3)
2.- Lo descomprimes
3.- Reemplaza tu spring.jar de la version 1.2.x con el nuevo spring.jar de la version 2.0
4.- Reinicia tu aplicación

Y ya esta! Es evidente que este post es bastante irónico, pero bueno, simplemente es para certificar que Spring 2.0 es completamente compatible hacia atrás. Y también para comentar, que en el proyecto del TempAlias lo he cambiado y a partir de ahora voy a utilizar las nuevas funcionalidades del 2.0, a ver que tal.