Using Spring JavaConfig on Google App Engine
Posted by Andrew Phillips at around evening time: January 17th, 2010
Recently, I put together a Spring demonstration for jclouds, the Java cloud library. This quickly turned into unexpected multi-dimensional experiment in integrating Guice, Google App Engine and Spring, but after much trial-and-error I finally came across a configuration that does the trick - or at least works1 as well as seems possible on GAE. (more...)
Latching and mocking in concurrent tests
Posted by Iwein Fuld mid-afternoon: November 3rd, 2009
Concurrent testing is hard, but not as hard as you think. If you use the right tricks it can be done. This blog shows you one particular trick that uses a latch and a mock to ensure a test scenario is completed before running the verifications.
While working on Spring Integration in Action, I experimented with a neat solution for concurrent tests. When I showed it to some colleagues I was pleasantly surprised by the reaction that I got. Judge for yourself if it's worth the blog.
The main idea is to use a latch and let your mock count it down. It sounds trivial (and to be honest it is).
(more...)
Spring JMS and WebSphere
Posted by Kris Geusebroek in the early morning: September 28th, 2009
Using Spring JMS in our application which needs to be running on WebSphere proved to be somewhat of a challenge. And since googling provided a lot of information but just a small ‘easy to miss’ piece of text to put the pieces together, i decided to write up this blog.
JPA implementation patterns: Testing
Posted by Vincent Partington around lunchtime: July 11th, 2009
In the previous blog in the JPA implementation patterns series, I talked about the three default ways of mapping inheritance hierarchies using JPA. And introduced one non-standard but quite useful method. This week I will discuss various approaches to testing JPA code.
What to test?
The first question to ask is: what code do we want to test? Two kinds of objects are involved when we talk about JPA: domain objects and data access objects (DAO's). In theory your domain objects are not tied to JPA (they're POJO's, right?), so you can test their functionality without a JPA provider. Nothing interesting to discuss about that here. But in practice your domain objects will at least be annotated with JPA annotations and might also include some code to manage bidirectional associations (lazily), primary keys, or serialized objects. Now things are becoming more interesting...
(more...)
@Composite – Macro Annotations for Java
Posted by Andrew Phillips in the early morning: June 23rd, 2009
Some months ago I attended a presentation at which Wilfred Springer demonstrated his very cool Preon binary codec library. Defining binary file formats in Preon requires quite a lot of fairly repetitive sets of annotations, and during a chat after the talk Wilfred mentioned (in fact, he blogged about it) how much more convenient it would be if one could just define "shortcuts":
@RequiredEnumProperty(column = "AGENT")
for
@NotNull @Column(name = "AGENT") @Enumerated(EnumType.STRING)
for instance - and use those instead. Sort-of "macro annotatations" for Java, if you like.
A thought that has presumably also occurred to many frequent users of Hibernate, JAXB or other annotation-heavy frameworks.
Well, it took me rather longer than the couple of days it would probably have taken a developer of Wilfred's skill, but finally @Composite is here! (more...)
JPA implementation patterns: Service Facades and Data Transfers Objects
Posted by Vincent Partington at around evening time: May 11th, 2009
In my previous blog on JPA implementation patterns, I touched upon the subject of the DTO and Service Facade patterns. In this blog I will explore why we would even need such patterns and put these patterns and the DAO pattern into the broader context of JPA application architecture.
If there is one thing that I learned when implementing JPA for the first time is that some of the "old school" enterprise application architecture patterns still apply, even though some people have proclaimed them to be no longer necessary:
- The DAO has been declared dead because you might just as well invoke the EntityManager directly. It provides a nice enough interface and switching from JPA to a different persistence implementation is not something the DAO abstraction would make much easier.
- DTO's have been deemed superfluous because you can also use your domain objects directly in the presentation layer. This is made possible by a combination of the open EntityManager in view pattern, tag libraries to display your domain objects in JSP's and data-binding utilities to map HTTP request parameters back to domain objects.
- And finally Service Facades also seem to have gone out of fashion. Instead you can have the controller directly invoke the services it needs or, even simpler, directly contain the business logic.
JPA implementation patterns: Lazy loading
Posted by Vincent Partington at around evening time: April 27th, 2009
In the previous three blogs about JPA implementation patterns, I covered the basis operations of saving entities, retrieving entities, and removing entities. In this blog I will continue along a different angle, exploring the subject of how entities are lazily loaded and how that affects your application.
Anybody that has been working with Hibernate for a while has probably seen a LazyInitializationException or two, usually followed by a message such as "failed to lazily initialize a collection of role: com.xebia.jpaip.order.Order.orderLines, no session or session was closed" or "could not initialize proxy - no Session". Even though these message may baffle new users of Hibernate, they are a lot better than the NullPointerExceptions OpenJPA gives you in these cases (at least when using runtime bytecode enhancement).
To use JPA to its full potential it is imperative to understand how lazy loading works, as it allows you to model your complete database with all its relations without loading that whole database as soon as you access just one entity.
(more...)
JPA implementation patterns: Data Access Objects
Posted by Vincent Partington mid-afternoon: March 9th, 2009
The JPA, short for Java Persistence API, is part of the Java EE 5 specification and has been implemented by Hibernate, TopLink, EclipseLink, OpenJPA, and a number of other object-relational mapping (ORM) frameworks. Because JPA was originally designed as part of the EJB 3.0 specification, you can use it within an EJB 3.0 application. But it works equally well outside of EJB 3.0, for example in a Spring application. And when even Gavin King, the designer of Hibernate, recommends using JPA in the second edition of Hibernate in Action, a.k.a. Java Persistence with Hibernate, it's obvious that JPA is here to stay.
Once you get over your fear of annotations 
, you find that there is plenty of literature out there that explains the objects and methods within the API, the way these objects work together and how you can expect them to be implemented. And when you stick to hello-world-style programs, it all seems pretty straight forward. But when you start writing your first real application, you find that things are not so simple. The abstraction provided by JPA is pretty leaky and has ramifications for larger parts of your application than just your Data Access Objects (DAO's) and your domain objects. You need to make decisions on how to handle transactions, lazy loading, detached object (think web frameworks), inheritance, and more. And it turns out that the books and the articles don't really help you here.
(more...)
Maybe annotations aren’t that bad after all
Posted by Vincent Partington at around evening time: January 19th, 2009
Two years ago I blogged about annotations and that I considered them to be A Bad Thing. It seems I will have to eat my words. I am actually using them to the hilt in my current project.
We use JPA and specific Hibernate annotations on our entities. See for example these annotations on a field:
@OneToMany(mappedBy = "changePlan", cascade = CascadeType.ALL, fetch = FetchType.LAZY)
@org.hibernate.annotations.Cascade(value = org.hibernate.annotations.CascadeType.DELETE_ORPHAN)
@org.hibernate.annotations.Sort(type = org.hibernate.annotations.SortType.COMPARATOR,
comparator = PositionableComparator.class)
private SortedSet
(more...)
Spring 2.x schema based configuration and the PropertyPlaceholderConfigurer
Posted by Vincent Partington in the early evening: January 1st, 2009
Spring 2.0 and later versions offer schema based configuration that allows us to have a more expressive and concise way to specify our configuration. For example, Spring Security 1.0 configuration used to be quite hairy, but became a lot simpler with Spring 2.0.
One disadvantage is that the documentation of the namespaces is not as good as that for regular beans. For regular beans, I can have a look at Javadoc, while for the namespaces that come with Spring the documentation is not up to the same level of detail. Until a Javadoc-like tool can generate this documentation from the schemas, the best documentation is the schemas themselves.
One little problem
But ignoring that issue, I recently ran into a very practical problem with using schema based configuration in combination with a PropertyPlaceholderConfigurer.
(more...)
Archives
Xebia Sites
Categories
- Java (282)
- Agile (109)
- General (50)
- Testing (42)
- Performance (42)
- Hibernate (36)
- Scrum (33)
- Podcast (31)
- Architecture (31)
- Spring (28)
- SOA (24)
- Maven (22)
- Project Management (22)
- Middleware (23)
- Deployment (14)
- Flex (17)
- JPA (17)
- Eclipse (15)
- Xebia Labs (15)
- Quality Assurance (14)