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.