...and these corresponding implementations: And the result: Clearly the @Autowired annotation indicates a required dependency by default, but this can easily be switched by adding the 'required' parameter with a value of 'false', such as: The result after this modification: As long as the stub version still does not contain the @Repository annotation, rerunning the tests will now produce the following exception: As you can see, I disabled the 'defaultFilters' and explicitly added my own. In this case, that was not completely necessary since the default includes the @Component and @Repository…

Then, a simple implementation: Since the service depends upon a MessageRepository, define that interface next: And for now, a stub implementation: Obviously this configuration looks a little sparse. As you can probably guess, the 'context' namespace will soon play a role. Try running the tests and notice that they fail with a NullPointerException. This is to be expected since the GreetingServiceImpl has not been provided a MessageRepository. In the next two steps, you will add annotations to drive the dependency injection and initialization respectively. Then, add the 'annotation-config…

Several months ago, I posted a blog entry introducing Spring 2.0's support for Message Driven POJOs. While many people are now familiar with that feature, Spring 2.0's JMS remoting features have received less attention. Essentially, this remoting functionality provides a JMS-based version of Spring's general approach to remoting as exhibited in its support for RMI, Hessian/Burlap, and its own HttpInvoker. For those unfamiliar with Spring remoting, the general idea is to configure a non-invasive exporter on the server-side and a proxy generator (a Spring FactoryBean) on the client-side. I will…

Spring 2.0.1 introduced an AbstractRoutingDataSource. I believe that it deserves attention, since (based on frequent questions from clients) I have a hunch that there are quite a few 'home-grown' solutions to this problem floating around. That combined with the fact that it is trivial to implement yet easy to overlook, and now I have several reasons to dust off my corner of the team blog. The general idea is that a routing DataSource acts as an intermediary - while the 'real' DataSource can be determined dynamically at runtime based upon a lookup key. One potential use-case is for ensuring…

I'm creating all of these classes in a "blog.mdp" package by the way. The first class is the RegistrationRequest: Next is the RegistrationReply: And the RegistrationService: As you can see, this is merely providing an example. In reality, something would probably be done with the registrations map. Also, you see that 20% of registration attempts will be denied (given a -1 confirmationId) - not a very practical way to process registration requests, but it will provide some variety to the reply messages. Again, the important thing is that this service class has NO ties to Spring or JMS…

The motivation behind this blog entry is to provide a simple step-by-step guide for getting started with JPA in a standalone environment with the Spring Framework. While the JPA specification originated as the persistence mechanism for EJB 3.0, it was fortunately recognized that any such mechanism should in fact be able to persist simple POJOs. Therefore, with a handful of JARs in your classpath and a few Spring-configured beans, you can begin experimenting with JPA code within your favorite IDE. I will be using Glassfish JPA - which is the reference implementation and is based upon Oracle's…

While the material in this post is quite simple, it will actually offer a glimpse of some rather significant new features in Spring 2.0. I hope that with a little imagination, you will be able to apply what you see here to far less trivial use cases of your own. I am going to show 2 examples actually. The first will use a rather simple logger: I will be using AOP to apply logging to a string concatenation service. Here is the interface: Öand an implementing Class: Alright - nothing is very exciting about this so far, but the most important thing to notice is that I am only dealing with POJOs…