Yeah!, there’s the code to create transformers!!!,… but transformers created with that function are autobots or decepticons? I wanted to find an answer so I went to the magic function createTransformer().

Transformer factory! It isn’t at Cibertron as everyone would expected, the TransformerFactory class is part of J2SE and you can see its javadoc here,…. LOL!

Pero que sucede si nos encontramos con el siguiente problema:

Estamos usando Spring MVC en una aplicación web pero nos vemos obligados a implementar un Servlet. Dentro de este Servlet tenemos que invocar a un Service que ya esta siendo administrado por el contexto de Spring.

El consejo del bug killer puede llevarnos por dos caminos en este escenario:

• No buscar en internet a profundidad, ni preguntar y usar la solución más rápida que se te venga a la mente.
• Seguir el buen diseño y obtener una referencia al Service administrado por Spring.

En el primer caso tendríamos un Servlet implementado de la siguiente manera:

public class DummyServlet extends HttpServlet {
 private static final long serialVersionUID = 1L;

 public DummyServlet() {
   super();
 }

 @Override
 protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException {
   DummyService service = new DummyServiceImpl();
   resp.getWriter().print(bean.getMessage());
 }
}

¡Esta instanciando la implementación del Service directamente!,… esto puede traer serios problemas si se tiene que cambiar el DummyServiceImpl por otro en un futuro próximo o lejano. Lo más probable es que no se actualice el Servlet y se presente un comportamiento no esperado del sistema.

En el segundo caso, usaríamos las mismas clases de Spring para obtener una referencia al Service:

public class DummyServlet extends HttpServlet {
 private static final long serialVersionUID = 1L;

 public DummyServlet() {
   super();
 }

 @Override
 protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException {
   WebApplicationContext applicationContext = ContextLoader.getCurrentWebApplicationContext();
   DummyService service = (DummyService) applicationContext.getBean("DummyService");
   resp.getWriter().print(bean.getMessage());
 }
}

Manteniendo de esa manera el diseño y el patrón de inyección de dependiencias.

Happy Hacking!

UPDATE: Para simplificar el ejemplo de este articulo solo se instancia el Service en el Servlet pero debemos tener en cuenta que el Service puede depender de clases DAO o puede necesitar AOP. Esto agravaría más los problemas de instanciar una clase que ya esta siendo manejada por el contenedor IoC.

1: <bean id="authenticationProcessingFilter"
2:       class="org.acegisecurity.ui.webapp.AuthenticationProcessingFilter">
3:   <property name="authenticationManager"    ref="authenticationManager"/>
4:   <property name="authenticationFailureUrl" value="/login.htm?login_error=1"/>
5:   <property name="defaultTargetUrl"         value="/foobar.htm"/>
6:   <property name="filterProcessesUrl"       value="/j_acegi_security_check"/>
7: </bean>

You usually define a bean like authenticationProcessingFilter and add it to a chain in the FilterChainProxy bean. With this configuration, you attempt to authenticate when a request to /j_acegi_security_check has been made, delegating the authentication to the authenticationManager bean. If everything is OK, the user is redirected to /foobar.htm otherwise to /login.htm?login_error=1

Most of the time, you will be happy with this configuration but what happens if you need to do some additional validations before authentication. You have to extend AuthenticationProcessingFilter

01: package net.modlost.framework.security;
02:
03: import java.io.IOException;
04:
05: import javax.servlet.http.HttpServletRequest;
06: import javax.servlet.http.HttpServletResponse;
07:
08: import org.acegisecurity.AuthenticationException;
09: import org.acegisecurity.ui.webapp.AuthenticationProcessingFilter;
10:
11: /**
12:  * @author Abner Ballardo Urco
13:  *
14:  */
15: public class CustomAuthenticationProcessingFilter extends
16:                 AuthenticationProcessingFilter {
17:
18:         @Override
19:         protected void onPreAuthentication(HttpServletRequest request,
20:                         HttpServletResponse response) throws AuthenticationException,
21:                         IOException {
22:
23:                 if (! validAuthenticationRequest(request,response)) {
24:                         throw new FooBarAuthenticationException();
25:                 }
26:
27:         }
28:
29:         private boolean validAuthenticationRequest(HttpServletRequest request,
30:                         HttpServletResponse response) {
31:                 return false;
32:         }
33:
34: }

Acegi provides a handily method: onPreAuthentication, you just need to override it, do your additional validations and throw an exception when the validation failed. This exception could extend AuthenticationException or IOException.

01: package net.modlost.framework.security;
02:
03: import org.acegisecurity.AuthenticationException;
04:
05: /**
06:  * @author Abner Ballardo Urco
07:  *
08:  */
09: public class FooBarAuthenticationException extends AuthenticationException {
10:
11:         public FooBarAuthenticationException() {
12:                 super("FooBar Authentication Exception");
13:         }
14:
15: }

If onPreAuthentication doesn’t throw an exception, the normal authentication process continues. This isn’t the end of the story, what happens if you need to show different views according to the exception?. This step is a peace of cake!

01: <bean id="authenticationProcessingFilter"
02:       class="org.acegisecurity.ui.webapp.AuthenticationProcessingFilter">
03:   <property name="authenticationManager"    ref="authenticationManager"/>
04:   <property name="authenticationFailureUrl" value="/login.htm?login_error=1"/>
05:   <property name="defaultTargetUrl"         value="/foobar.htm"/>
06:   <property name="filterProcessesUrl"       value="/j_acegi_security_check"/>
07:   <property name="exceptionMappings">
08:   <props>
09:     <prop key="net.modlost.framework.security.FooBarAuthenticationException">/foobarError.jsp</prop>
10:   </props>
11:   </property>
12: </bean>

Defining the property exceptionMappings in authenticationProcessingFilter you can add all the exceptions (from Acegi and yours) and the urls to redirect to. If the exception is not found in exceptionMappings the default authenticationFailureUrl will be used.

¿Qué es Spring Framework?

Es un framework open source para el desarrollo de aplicaciones que busca hacer al desarrollo de software en J2EE más simple. Rod Johnson escribió las primeras líneas de código de Spring Framework y publicó sus ideas en dos libros:

• Expert One-on-One J2EE Design and Development, Wrox Press
• Expert One-on-One J2EE Development without EJB, Wrox Press

Las propuestas de Spring Framework fueron bien recibidas por la comunidad java (en la mayoria) y comenzó toda una fiebre por este framework. Se han publicado varios libros, se han desarrollado varias aplicaciones empresariales usandolo y proyectos como JetSpeed-2 lo usan en su core, etc.

Primeros pasos

A mediados del 2004 llevé el curso de “Desarrollo de Programas 2″ en la PUCP, en este curso todo el salón tiene como meta implementar un ERP. El salón se divide en grupos y cada uno se encarga de un módulo del ERP. Luego de una elección entre “varios candidatos”, fui elegido como jefe de proyecto.

El jefe de proyecto no tenía que ver la arquitectura pero quise apoyar en escoger las tecnologías que usaríamos. Ya conocía algunos frameworks en Java como: Apache Struts, iBatis, Log4J, etc. pero decidí dedicar unos días a investigar sobre otras opciones para el desarrollo de aplicaciones web en Java. Así fue como llegué a la página web de Spring Framework, leí la introducción de su manual de referencia y quede muy impresionado por el uso del patrón de Inversión de Control / Inyección de Dependencias.

Tuve muchas ganas de ver como funcionaba este framework pero decidí no usarlo en el proyecto porque ya eran suficientes temas nuevos para un grupo de personas que por primera vez intentarían implementar una aplicación web (decisión muy acertada a mi parecer). Como ya existía suficiente documentación sobre Apache Struts y además iBatis no exigía un cambio muy drástico de trabajo frente a Hibernate, comenzamos el desarrollo usando estos dos frameworks.

Pude darme algo de tiempo ese ciclo para realizar algunas pruebas con Spring Framework y cada vez me sorprendía más y más. Durante el 2005 pude dedicarle más tiempo de investigación y debo reconocer que luego de comprender las propuestas de este framework, mi manera ver el desarrollo de software ha cambiado.

De la teoría a la práctica

A mediados del 2005 tuve la oportunidad de ver el funcionamiento de un framework desarrollado por AgileWorks basado en Spring Framework y Hibernate. Quede completamente sorprendido por la forma de trabajo de este framework. Pude verlo en acción en un proyecto, encontrando una larga serie de problemas en gran parte por la inexperiencia (con los conceptos, patrones, que proponen estos frameworks) de los que formamos parte de ese proyecto.

Con esa experiencia decidí iniciar un proyecto: iniciar el desarrollo de un framework pequeño que permita la integración de Spring Framework, Hibernate, Acegi Security, DisplayTag, StrutsMenu, XDoclet y Hibernate Tools. Mi objetivo principal era minimizar en lo posible el código que yo implemente pero que establezca una forma de trabajo basada en las propuestas de estos frameworks. Así es como nace STCFramework, el framework usado por STConsulting. Este framework ahora se encuentra en el desarrollo de su versión 2.0.

Spring Framework y su difusión

Ya existía un grupo de amigos que también investigaban y usaban Spring Framework en mi universidad (2004), pero su uso se mantenía en un circulo hacker. Como ya es algo común en mi, comencé a difundir el uso de este framework entre mis compañeros, profesores. Mis comentarios generaban curiosidad en algunos, discusiones (alturadas) con otros y no mucha aceptación por algunos profesores.

Lo más interesante sucedió este año (2006) cuando la popularidad de Spring Framework creció exponencialmente. Cada vez más y más empresas usaban Spring Framework (algunas lo hacían bien y otras no). Conocí más personas que al igual que yo habían comenzado a usar Spring Framework desde el 2004; compartimos ideas, opiniones, etc. y cada uno por su lado siguió fomentando el uso de este framework.

También tuve la oportunidad de dar conferencias sobre Spring Framework en la PUCP, UPeU, ISTPH. Dicte cursos de capacitación en varias empresas y una grata sorpresa más fue enterarme que varias tesis en desarrollo en la PUCP usan Spring Framework (además de la mía).

¿Que más vendrá?

Spring Framework esta aquí para quedarse un buen tiempo. Hasta el momento no he visto ningún framework que brinde la misma funcionalidad o que proponga algo diferente pero que a la vez sea más potente que Spring Framework.

Espero con muchas expectativas el desarrollo de Spring-OSGi, este modulo permitirá a aplicaciones desarrolladas en Spring Framework correr dentro de un framework OSGi. La misma idea que implementa Eclipse (una serie de plug-ins que al final construyen un producto).

Tengo mucha fe en este proyecto y si las expectativas que tengo se cumplen, Spring-OSGi de una u otra manera revolucionará la forma de desarrollo de aplicaciones.

Happy hacking!

Según la regla que sigo: “Mientras menos hago más avanzo”, decidí usar el modulo Xdoclet para generar el archivo portlet.xml.

Definí un controlador con los respectivos tags:

package com.stconsulting.sample.web.portlet.controller;

import javax.portlet.RenderRequest;

import javax.portlet.RenderResponse;

import org.springframework.web.portlet.ModelAndView;

import org.springframework.web.portlet.mvc.AbstractController;

/**

 * @portlet.portlet  name="SamplePortlet"

 *                  portlet-class="org.springframework.web.portlet.DispatcherPortlet"

 *                  display-name="Sample Portlet" expiration-cache="0"

 * 

 * @portlet.portlet-init-param  name="contextConfigLocation"

 *                              value="/WEB-INF/context/sample/applicationPortlet.xml"

 * 

 * @portlet.supports   mime-type="text/html"

 *             modes="view,edit,help"

 * 

 * @portlet.portlet-info title="Sample Portlet" keywords="Sample"

 *                       short-title="Sample"

 * 

 * @author Abner Nazario Ballardo Urco

 */

public class SamplePortlet extends AbstractController {

 public ModelAndView handleRenderRequestInternal(RenderRequest request,

 RenderResponse response) throws Exception {

 return new ModelAndView("sample", "model", "hello");

 }

}

Pero XDoclet no generaba correctamente el archivo (estaba en blanco), en fin,… luego de varias pruebas encontre que el archivo portlet_xml.xdt tenía esta definición

 <XDtClass:forAllClasses type="javax.portlet.GenericPortlet">
  <XDtClass:forAllClassTags tagName="portlet.portlet" superclasses="true">
    <portlet>
      ...............

Como vemos se indica que solo procese las clases que extiendan de javax.portlet.GenericPortlet, para poder usar libremente XDoclet Porlet Module con Spring solo necesitamos modificar el archivo .xdt que se encuentra en:

JAR: xdoclet-portlet-module.jar
Ruta: /xdoclet/modules/portlet/resources/portlet_xml.xdt

 <XDtClass:forAllClasses>
 <XDtClass:ifHasClassTag tagName="portlet.portlet">
  <XDtClass:forAllClassTags tagName="portlet.portlet" superclasses="true">
    <portlet>
      ...............
  </XDtClass:forAllClassTags>
 </XDtClass:ifHasClassTag>
 </XDtClass:forAllClasses>