Grupo3_Iteracion3

Correcciones:

- En web.xml especifican:

<context-param>

<param-name>contextConfigLocation</param-name>

<param-value>/WEB-INF/deploy-context.xml</param-value>

</context-param>

Por otro lado también tienen /WEB-INF/beans.xml y también encuentro esto:

public class ServiceImpl implements ServiceDefn {

ApplicationContext context = new ClassPathXmlApplicationContext("beans.xml");

....

Esto esta mal. Quiere decir que spring se esta configurando por código en lugar de hacerlo automáticamente (e incluso están iniciando dos o más contextos distintos). Además estoy seguro que acá pueden hacer uso de inyección de dependencia utilizando el contexto que ya se encuentra instanciado en forma automática.

Entonces:

1. Eliminen todo lo que es configuración por código de Spring.

2. Si aún quieren mantener los archivos separados (daos y servicios), pueden usar algo como:

<context-param>

<param-name>contextConfigLocation</param-name>

<param-value>classpath:/beans.xml;/WEB-INF/deploy-context.xml</param-value>

</context-param>

3. Usen Autowire o alguna otra técnica de injección de dependencias.Yo les deje un ejemplo de como funciona autowire en el código que les adjunto.

- Les marco de nuevo el hecho de que los packages no respetan las convenciones de java. ar.edu.utn.frba.tacs.MercadoWarnes.Exception debería ser ar.edu.utn.frba.tacs.mercadowarnes.exception. Prueben las opciones de refactor (ALT+SHIFT+R) para esto, no cuesta nada.

- Estas clases parece que no son utilizadas, eliminar de ser necesario.

DbManager.java

Pruebadeservicios.java

StartServer.java

HibernateProxy.java

HibernateUtil.java

SessionClosure.java

- No es necesario definir como abstract los metodos de una interfaz. Ver ServiceDefn.

- Otra vez tuve problemas para compilar el source, debido a la presencia de caracteres que no tienen representacion en UTF-8.

Modifiquen el pom.xml de esta manera para evitar inconvenitentes:

<plugin>

<groupId>org.apache.maven.plugins</groupId>

<artifactId>maven-compiler-plugin</artifactId>

<configuration>

<source>1.6</source>

<target>1.6</target>

<encoding>Cp1252</encoding>

</configuration>

</plugin>

- No hay nada de test automáticos para los servicios. Me gustaria que configuren Jetty y al menos realicen algunos tests con los servicios desplegados. Acá les dejo un link para automatizarlo con maven2 (http://docs.codehaus.org/display/JETTY/Maven+Jetty+Plugin)

- El punto anterior les va a ayudar a simplificar el deploy de su aplicación. De esa manera no requieren configuración extra en el ambiente local.

En la próxima entrega la aplicación debe desplegar con mvn jetty:run

- Al desplegar la aplicación no puede encontrar la base de datos y falla. Por alguna razón no se crea automáticamente.

- Para configurar el contexto de spring se pueden indicar varios archivos al mismo tiempo. Si lo que quieren es diferenciar ambientes de BBDD entre test y producción investiguen sobre ese tema de manera de incluir el datasource adecuado en cada caso pero siempre usar el mismo xml para definir daos y demas. No esta bueno duplicar ese tipo de configuración.

En el peor de los casos usen un solo archivo de configuración.

- En el caso de que la BBDD esté vacía los servicios como /piezas arrojan NullPoinerException. El servicio no debería fallar, sino indicar que no hay partes disponibles.

- Traten de mejorar el logueo y manejo de errores:

try {

categoria = categoriaDAO.getCategoriaPorNombre(strCategoria);

piezas = piezasDAO.getPiezasPorCategoria(categoria);

} catch (Exception e) {

e.printStackTrace();

}

en lugar de e.printStackTrace podrían loguear el error ( logger.error(message, t) ).

- Si el servicio de /pedido/crear falla, esta falla no es reportada al usuario. Sin embargo parece que funcionara correctamente (incluso otorga un número de pedido). Cuando se van a consultar los pedidos el mismo no existe. Imaginen el problema que puede causar esto si el cliente piensa que está todo ok cuando en realidad se estan perdiendo pedidos.