Capturar MaxUploadSizeExceededException en Spring Portlet MVC

En el applicationContext.xml

	<bean id="portletMultipartResolver"
		class="org.springframework.web.portlet.multipart.CommonsPortletMultipartResolver">
		<property name="maxUploadSize" value="1000000" />
	</bean>
	
	<bean class="org.springframework.web.portlet.mvc.annotation.AnnotationMethodHandlerExceptionResolver"/>

en el controlado:

	@ExceptionHandler(MaxUploadSizeExceededException.class)
	public ModelAndView handleException1(RenderRequest req, RenderResponse res, Object handler, Exception exception)
	{
		ModelAndView modelAndView = new ModelAndView("uploadFile");
		modelAndView.addObject("message", exception.getMessage());
		return modelAndView;
	}

Conversion con/de Enumerados

El problema: el API de Factura electronica tiene un enumerado llamado FacturaeVersion. Este contiene el siguiente string «FACTURAE_32», segun la version, varian los ultimos digitos, estos pueden ser: 30, 31, 32. Cuando necesitas usar las clases que validan el xml, o la contabilidad, o la firma del xml necesitas indicar la version de la siguiente manera: «3.0», «3.1», «3.2». ¿Porque? porque casi solo contemplan que el xml esta en fichero y no como un Stream. La version dentro del xml esta de esta ultima forma. La gran pregunta seria ¿Porque denominar «FACTURAE_31» si luego vas a usar «3.0»?.

La solucion:

public enum FacturaeVersionConverter {

	v30("3.0", FacturaeVersion.FACTURAE_30),
	v31("3.1", FacturaeVersion.FACTURAE_31),
	v32("3.2", FacturaeVersion.FACTURAE_32);

	private FacturaeVersion facturaeVersion;
	private String strVersion;

	FacturaeVersionConverter(String strVersion, FacturaeVersion facturaeVersion){
		this.facturaeVersion = facturaeVersion;
		this.strVersion = strVersion;

		EnumHelper.correspondencesMap.put(strVersion, this);
	}

	public String getStringVersion(){
		return strVersion;
	}

	public FacturaeVersion getFacturaeVersion(){
		return facturaeVersion;
	}

    public static FacturaeVersionConverter convert(String strVersion) {
        return EnumHelper.correspondencesMap.get(strVersion);
    }

    public static FacturaeVersionConverter convert(FacturaeVersion facturaeVersion) {
    	for(Entry entry: EnumHelper.correspondencesMap.entrySet()){
    		if(entry.getValue().getFacturaeVersion().name().equals(facturaeVersion.name())){
    			return entry.getValue();
    		}
    	}

        return null;
    }

	private static final class EnumHelper {

        static final Map correspondencesMap =
                new HashMap();
    }
}

La llamada a la solucion:

String strVersion = FacturaeVersionConverter.convert(FacturaeVersion.FACTURAE_30).getStringVersion();
FacturaeVersion facturaeVersion = FacturaeVersionConverter.convert("3.1").getFacturaeVersion();

Spring MVC Portlet JSR-303 (Validation)

En el applicationContext de spring:
	<!-- Portlet annotations support -->
	<bean id="parameterMappingInterceptor"
		class="org.springframework.web.portlet.handler.ParameterMappingInterceptor" />

	<bean
		class="org.springframework.web.portlet.mvc.annotation.DefaultAnnotationHandlerMapping">
		<property name="interceptors">
			<list>
				<ref bean="parameterMappingInterceptor" />
			</list>
		</property>
	</bean>

	<!-- mvc:annotation-driven @Valid JSR-303 -->
	<mvc:annotation-driven validator="validator" />
	<bean id="validator"
		class="org.springframework.validation.beanvalidation.LocalValidatorFactoryBean" />
	<bean id="annotationMethodHandlerAdapter"
		class="org.springframework.web.portlet.mvc.annotation.AnnotationMethodHandlerAdapter">
		<property name="webBindingInitializer">
			<bean id="configurableWebBindingInitializer"
				class="org.springframework.web.bind.support.ConfigurableWebBindingInitializer">
				<property name="validator">
					<ref bean="validator" />
				</property>
			</bean>
		</property>
	</bean>

	<bean id="messageSource"
		class="org.springframework.context.support.ReloadableResourceBundleMessageSource">
		<property name="basenames">
			<list>
				<value>classpath:Language</value>
				<value>classpath:ValidationMessages</value>
			</list>
		</property>
		<property name="defaultEncoding" value="UTF-8" />
	</bean>


 En el pom.xml:  
		<!-- Validation -->
		<dependency>
			<groupId>javax.validation</groupId>
			<artifactId>validation-api</artifactId>
			<version>1.0.0.GA</version>
		</dependency>
		<dependency>
			<groupId>org.hibernate</groupId>
			<artifactId>hibernate-validator</artifactId>
			<version>4.3.0.Final</version>
		</dependency>
		<dependency>
			<groupId>org.hibernate</groupId>
			<artifactId>hibernate-validator-annotation-processor</artifactId>
			<version>4.3.0.Final</version>
		</dependency>

 Hibernate Validator anotaciones ejemplo

			

CRUD (create, read, update and delete)

El software debe permitir al usuario:

1. Crear o añadir nuevas entradas
2. Leer, recuperar, buscar, o ver las entradas existentes
3. Actualizar o editar las entradas existentes
4. Eliminar / desactivar entradas existentes

 

Operation                          SQL              HTTP(Rest)

Create                             INSERT               POST
Read (Retrieve)          SELECT                GET
Update (Modify)        UPDATE       PUT / PATCH
Delete (Destroy)         DELETE            DELETE 

SOLID

S (Single Responsibility Principle / Principio de Responsabilidad Única )
Establece que cada clase debe tener una responsabilidad individual, y que la responsabilidad debe ser completamente encapsulado por la clase. Todos los servicios deben estar estrechamente alineados con esa responsabilidad.

O (Open/Closed Principle / Principio de Abierto/Cerrado)
Las entidad de software (classes, módulos, funciones, etc.) deben estar abiertas para la extensión, pero cerradas para la modificación.

L (Liskov Substitution Principle / Principio de sustitución de Liskov)
Cada clase que hereda de otra puede usarse como su padre sin necesidad de conocer las diferencias entre ellas. En lenguaje mas formal: si S es un subtipo de T, entonces los objetos de tipo T en un programa de computadora pueden ser sustituidos por objetos de tipo S (es decir, los objetos de tipo S pueden ser sustitutos de objetos de tipo T), sin alterar ninguna de las propiedades deseables de ese programa (la corrección, la tarea que realiza, etc.) Más formalmente, El Principio de Sustitución de Liskov (LSP) es una definición particular de una relación de subtipificación, llamada tipificación (fuerte) del comportamiento

I (Interface-segregation Principle / Principio de segregación de Interfaces)
“Los clientes no deben estar obligados a implementar una interfaces que luego no usarán”
La primer forma de hacer una interfaz pesada es crear una interfaz con mucha funcionalidad que solo usa una implementación y que las otras la heredan pero no hacen nada o como mucho elevan una excepción del estilo “Esto no esta permitido”.
Otra forma de hacer una interfaz “pesada” es que tenga mas información de la que necesita.

D (Dependency Inversion Principle / Principio de Inversión de Dependencias)
Los módulos de alto nivel no deben depender de los módulos de menor nivel. Ambos deben depender de sus abstracciones.
Las abstracciones no deben depender de los detalles, los detalles deben depender de las abstracciones.
Este principio es la guinda del postre. Es decir, no es posible hacer este principio sin cumplir con los anteriores.

Fuentes: wikipedia, danielmazzini.