Package private beans

Thinking about separation in my code the question of package private beans popped up. The general pattern here is to have interfaces defined. The implementing classes however are package private. Instances are generated through a factory. I looked around to find some documentation how this can be done with a Spring context, but found none, so here it is. Special interest is the Spring configuration with Java.

The package private beans are annotated and the classpath is scanned. These classes are discovered, as this basically involves reflection. The beans however cannot be instantiated in the configuration, as the beans are not visible in the package of the configuration class. This is where the factory comes in. The factory resides in the same package as the beans however is a public @Service and so is available in the application context.

I tried this out with two beans:

package ch.sahits.spring.bean.internal;

import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Component;

import java.util.Random;

class PackagePrivateBean {
    private Random rnd;

    public Random getRnd() {
        return rnd;
package ch.sahits.spring.bean.internal;

import org.springframework.context.annotation.Scope;
import org.springframework.stereotype.Component;

@Scope(value = "prototype")
class PackagePrivatePrototype {
    private final int a;

    public PackagePrivatePrototype(int a) {
        this.a = a;

    public int getA() {
        return a;

The configuration looks like this:


package ch.sahits.spring;

import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.ComponentScan;
import org.springframework.context.annotation.Configuration;

import java.util.Random;

@ComponentScan(basePackages = {"ch.sahits.spring.bean.internal"})
public class PackagePrivateSpringConfiguration {
    public Random rnd() {
        return new Random();


The factory:

package ch.sahits.spring.bean.internal;

import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.context.ApplicationContext;
import org.springframework.stereotype.Service;

public class PackagePrivateBeanFactory {

    private ApplicationContext context;

    public PackagePrivateBean getBean() {
        return context.getBean(PackagePrivateBean.class);

    public PackagePrivatePrototype getBean(int i) {
        Object[] args = new Object[]{Integer.valueOf(i)};
        return (PackagePrivatePrototype)context.getBean("packagePrivatePrototype", args);

I tested this with a Test-Case:

package ch.sahits.spring;

import ch.sahits.spring.bean.internal.PackagePrivateBeanFactory;
import org.junit.Test;
import org.junit.runner.RunWith;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.test.context.ContextConfiguration;
import org.springframework.test.context.junit4.SpringJUnit4ClassRunner;

import static org.junit.Assert.assertNotNull;

@ContextConfiguration(classes=PackagePrivateSpringConfiguration.class, loader=AnnotationConfigContextLoader.class)
public class PrivatePackageConfigurationTest {
    private PackagePrivateBeanFactory factory;

    public void factoryShouldNotBeNull() {

    public void packagePrivateComponentShouldNotBeNull() {
        Object o = factory.getBean();

    public void packagePrivatePrototypeShouldNotBeNull() {
        Object o = factory.getBean(47);

The curious thing is that the PackagePrivateBean is by default of scope Singleton and thereby has to be created on application context startup. As this happens through reflection of the default constructor this is even possible even though the bean itself is not visible and can therefore not be defined through the configuration class. This is a case, where you get an instance through the package scan that cannot be done through explicit definition. This applies in the same manner for XML configuration. Defining a package private bean in XML would cause a runtime exception when reading the XML application context.

Shutting down Spring backed JavaFX application

This is just another short tip on how to combine JavaFX and the Spring Framework. These two technologies do not work perfectly together, but they can be made to cooperate. One of the two is the lead, meaning one is initialized first from the main method and therefore controls the lifecycle of the application. In my case this is the Spring framework as the user interface is optional. However I still want to handle the case where the user interface is closed (or the menu point quit is selected) and this should also shut down the application context of Spring.

There are three steps that should be taken:

  • Register the shutdown hooks for your application context. This has nothing to do with canceling the application in a controlled manner. This case covers things like Ctrl+C or kill -9.
  • Override the stop method of Application. When closing the application window, the stop method is called. You will want to hook into this method to signal the spring context that his end has come.
    public void stop() throws Exception {
        System.out.println("Stopping the UI Application");


In my case I used Guava’s EventBus to signal the context.

  • Finally in your code handling the context end it.

That’s it, folks!

Custom Spring scope done right

You can define your own Spring Scope. One thing to consider is that the beans that are defined in a scope must somehow be backed by a store. For the singlton scope this is the application context itself, for a session scope it is the session, for a request scope it is the request. With this setup the beans lifecycle is bound to the lifecycle of the backing store, e.g. when a session terminates it is deleted and with it all the corresponding beans.

There are other examples out there that implement a custom scope by implementing the store in the scope. This then requires that the lifecycle has to be managed from the outside. So let’s do this the right way:

  • We want a scope that matches the lifecycle of a dialog. The dialog is opened some content is displayed, some work is done and finally the dialog is closed.
  • The application code should not be polluted with logic to manage the bean life cycle of the scope.

„Custom Spring scope done right“ weiterlesen

Replicable State with Spring

Recently I have come across a problem, which does not have an elegant solution. Imagine you have a setup like this:

  • Nice little (or not so little) application based on the Spring-Framework
  • Lots of utilities and services that are waiting to be injected into something
  • Services/Components which represent singletons and do have state, all managed through Spring
  • Application State uses these services
  • Application State is replicated: for example loaded from a file before injected with the Spring Beans
  • Application State is ‚updated‘: the state is changed from the outside after it is created (think repeated loading replacing the old state)

If it were not for the last point the preferred solution would be to implement you own BeanFactory, create a new Spring context into which the newly created beans are pushed into and make it a child context of the already existing context. The BeanFactory would use the existing context to do the wiring on the newly created beans.

However when this replicating happens repeatedly you would end up with a huge context hierarchy, over which you have no control. What you want instead is some Hot soaping of the state in the existing context, but we all know how well these things work.

In my concrete use case the application consists of multiple parts, which do not run necessarily in the same VM, however share the same state. Another approach would be to have the state not managed by Spring. This however would complicate the application code considerably as the whole state would have to be passed around everywhere and each part would have to navigate through the model hierarchy to retrieve their required components.

So here is what I have come up with:

„Replicable State with Spring“ weiterlesen

ServletFilter with Spring Dependency Injection

Recently I stumbled upon the task to implement a ServletFilter in our Spring MVC web application. The filter should use one of the services we defined as bean, so it was natural to find a way to implement a servletFilter as a Spring bean so DI can be leveraged.

I got lucky, as I stumbled on this post in German, detailing what has to be done. Basically there are three things to do:

  1. Implement the filter (implementing the javax.servlet.Filter interface)
  2. Define it as a Spring bean either through annotation, XML or Java configuration
  3. Use org.springframework.web.filter.DelegatingFilterProxy as the filter class in your web.xml. The filter-name must match the name of your bean.

If your filter implements an init or destroy method, which actually do something, you also have to specify the init-param targetFilterLifecycle with the value true, to force the proxy to call these methods on the underlying bean.


That's it.