Working with Spring-AOP there are moments when you want to access the class type of the incoming method call. In my example I’ve implemented a MethodInterceptor to capture method invocations on a class of type net.solidsyntax.MyProxiedClass.
While generating binding classes with JAXB I’ve recently encountered the following problem:
The problem occurred while trying to generate binding classes from an xsd (MySchema.xsd) which included CommonTypes.xsd and EvenMoreCommonTypes.xsd. Both CommonTypes.xsd and EvenMoreCommonTypes.xsd contain a type called “AnXSDType”. By default JAXB generates binding files with the same name as the type. Two source files with the same name in the same package is not possible so JAXB throws generates an exception.
How can we fix this ?
I finally found the time to read Java Application Architecture: Modularity Patterns with Examples Using OSGi written by Kirk Knoernschild.
With such an impressive and lengthy title I expected a difficult read. But as it turns out Kirk was able to explain some rather abstract concepts in a very understandable and accessible manner.
Lately I’ve been playing around with Groovy and I tought I might try converting a Java project to Groovy. The example application which I’ve created to demonstrate Hibernate FetchMode strategies seems ideal for the task. It contains a few Hibernate entities, which are basically just Java beans. And it has a small piece of ‘application logic’. You may download the original code here. For those who can’t wait for the result the final code can be found here.
Now let’s get started ..
Trying to optimize OneToOne mappings by setting the fetch mode to lazy does not always work as expected. I’ve created a guide about how to optimize OneToOne mappings. This guide takes a closer look at how lazy fetching is affected by the owner of a relation.