Tags: java

au pilori !

Hibernate migration to 3.2 from 3.1

This change on hibernate 3.2 can cause hibernate to not detect change in custom type on a collection property. e.g. if you want to map a comma separated list of string to a Set :


"String1, String2, String3" <=> { "String1", "String2", "String3" }.



After an update the loadedState gonna reference the set in the entity. So a change in this Set by the application gonna change also the Set in the loaded state as they are the same. So hibernate is not gonna be able to check if the Entity is dirty properly.

Solution stay in 3.1 or mark your object as hasUpdateGeneratedProperties, which might not be good for performances ...

--- Update
Issue posted
au pilori !

Struts2 and spring

I read the release notes of struts 2.0.2. Webwork made the choice to use spring as the DI Framework, but apparently in struts2 they decide not to depend on spring


Spring Plugin: Integrate Spring with your application using a plugin (WW-1499). Or, if you prefer, use the Plexus Plugin instead.



And


Dependency Injection: The framework now uses its own dependency injection container, based on Google Guice. Applications are free to use Spring, Plexus, or even a local copy of Guice for any dependency injection needs. Actions can still be instantiated via the Spring configuration, when desired (WW-1499), but Spring is entirely optional now.



There an explanation of that in an email from Don Brown on the mailing list.


You might be wondering why Guice, why not Spring, or why a dependency injection container at all. First, the dependency injection engine is solely for XWork, Struts, and its plugins. It is not meant, nor would it be a good fit, for the end user application. Guice has a very minimal feature set that is perfect for the Struts framework, but wouldn't be sufficient for a Struts application. Second, an internal DI container is important as it doesn't force a Struts application to use a certain DI container for their application. If we used Spring, the framework would not only require all Struts applications to have Spring, but also require a certain version. Guice is not only a very small, fast, DI container, but it also has been imported into the XWork source repository and package structure, so that if a Struts application wanted to use a different version of Guice down the road, it wouldn't be a problem.



The spring version makes perfect sense, if Struts2 is not couple to spring you can choose what ever version you want as soon as Struts2 use a ObjectFactory that is pluggable easily. I'm quite confident it is.
au pilori !

Migration from Spring 1.2.7 to Spring 2.0.1

- Spring do some convertion when assigning a property, it is able to extract the generic type
- InitializingBean.afterPropertiesSet() now throw an Exception
- AbstractDependencyInjectionSpringContextTests.getAutowireMode is final, got to set the type in the constructor
- ProxyFactoryBean does some autodetect for interfaces, can be desactivated by setting the autodetectInterfaces to false
- ehCache 1.1 is no longer supported
au pilori !

Spring 2, backward compatibility ProxyFactoryBean

	/**
	 * Set whether to autodetect proxy interfaces if none specified.
	 * 

Default is "true". Turn this flag off to create a CGLIB * proxy for the full target class if no interfaces specified. * @see #setProxyTargetClass */ public void setAutodetectInterfaces(boolean autodetectInterfaces) { this.autodetectInterfaces = autodetectInterfaces; }

au pilori !

Getting Interrupted ?

Interesting paper in the Java Theory and Practice Section.

to resume :

The most common response to InterruptedException is to swallow it -- catch it and do nothing (or perhaps log it, which isn't any better) -- as we'll see later in Listing 4. Unfortunately, this approach throws away important information about the fact that an interrupt occurred, which could compromise the application's ability to cancel activities or shut down in a timely manner.