Spring依赖注入可序列化的bean

Question

I have a service class which is not serializable and a bean which must be serializable but must have access to this service class:

class SomeBean implements Serializable
{
    private StuffFactory factory;

    @Autowired
    public SomeBean(StuffFactory factory)
    {
        this.factory = factory;
    }

    public getOther()
    {
        return this.factory.getSomeOtherStuff();
    }
}

This obviously doesn't work because now the SomeBean class is no longer serializable. What is the correct way to solve this in Spring? When I make the factory field transient then I loose the injected factory instance on deserialization, or not? And when I make the StuffFactory also serializable then this class will no longer be a singleton because each SomeBean instance will have it's own factory after deserialization then.

Answer 1

You need some kind of context for this magic to work.

One ugly way I can think of is a static ThreadLocal holding the ApplicationContext - it's how the spring-security works using SecurityContextHolder .

But the best if You'd be able to externalize the logic that requires the StuffFactory to some kind of singleton SomeBeanService , ie:

public class SomeBeanService {
    @Autowired
    private StuffFactory stuffFactory;

    public void doWithSomeBean(SomeBean bean) {
        // do the stuff using stuffFactory here
    }
}

Update:

The whole point in above alternative to ThreadLocal is to get rid of the dependency on StuffFactory from SomeBean completely. This should be possible, but will require changes in architecture. The separation of concerns (one of, not only Spring, basic rules) implies that it might be a good idea to let SomeBean be a simple data transfer object and the business logic to be moved to service layer.

If You'll be unable to achieve this, than the only way is using some kind of static context (as Ralph also said). The implementation of such context may involve using a ThreadLocal . This would allow to access the ApplicationContext to get the StuffFactory , but it's almost as ugly as global variables, so avoid it if possible.

Update2:

I just saw Your comment, that SomeBean is stored in HTTP session, and hence the serialization/deserialization issue. Now even more I advice to change Your design and remove the dependency. Make SomeBean a simple DTO, as small as possible to avoid overloaded sessions. There should be no logic requiring access to singleton Spring beans inside the SomeBean . Such logic should be placed in the controller or service layer.

Answer 2

Maybe have a SomeBeanFactory :

class SomeBeanFactory {
    @Autowired
    private StuffFactory stuffFactory;

    public SomeBean deserialize(...) {
        SomeBean someBean = ...;
        someBean.setStuffFactory(stuffFactory);
        return someBean;
    }
}

Obviously, you'll need to create a setter for factory in SomeBean .

Answer 3

Java provide a way to control the serialization and deserialization by implementing the two methods:

• private void writeObject(ObjectOutputStream out) throws IOException;
• private void readObject(ObjectInputStream in) throws IOException, ClassNotFoundException;

So you can change the write to store the bean without the reference to the service and later one while reading the object "inject" the reference again.

@see http://java.sun.com/developer/technicalArticles/Programming/serialization/

You MUST create the instance in readObject as bean. If you only use a simple new it will not become a bean. Therefore you need access to the Spring Context, for example via a static method. May the best way is to use a bean factory to create the new instance.

---

An other way you can try to make the instance a spring bean is using @Configurable but that requires real AspectJ.

Answer 4

A re-think of your architecture is potentially practical in this scenario. If you can isolate the data that needs to be serialized into a simple data transfer object (DTO), then it should be possible to provide a wrapper to that DTO that itself can contain dependencies to other beans.

For example:

public interface IDataBean {
    void setSomething(String someData);
}

// This is your session bean - just a plain DTO
public class MyDataBean implements IDataBean, Serializable {

   private String someData;

   public void setSomething( String someData ) {
      this.someData = someData;
   }
}

// This is the wrapper that delegates calls to a wrapped MyDataBean.
public class MyDataBeanWithDependency() implements IDataBean {

    private SomeOtherService service;

    private MyDataBean dataBean;

    public SimpleDataBeanWithDependency(MyDataBean dataBean, SomeOtherService service) {
       this.dataBean = dataBean;
       this.service = service;
    }

    public void setSomething(String someData) {
       // Here we make a call to the service to perform some specific logic that may, for example, hit a DB or something.
       String transformedString = service.transformString(someData);
       dataBean.setSomething(transformedString);
    }
}

public class SomeService {

    // This is a Spring session scoped bean (configured using <aop:scoped-proxy/>)
    @Autowired
    private MyDataBean myDataBean;

    // Just a plain singleton Spring bean
    @Autowired
    private SomeOtherService someOtherService;

    public IDataBean getDataBean() {
         return new MyDataBeanWithDependency(myDataBean, someOtherService); 
    }
}

Sorry for all the code! However, let me try to explain what I mean here. If you always retrieve the session bean via a service (in this case SomeService), you have the option of creating a wrapper around the session bean. This wrapper can contain any bean dependencies (autowired into SomeService) that you may wish to use as part of performing logic alongside the session bean.

The neat thing about this approach is that you can program to an interface as well (see IDataBean). This means that, if you, for example, had a controller that obtains the data bean from the service, it makes unit testing/mocking very clean.

Possibly, an even cleaner approach from the code perspective, would be for MyDataBeanWithDependency to be registered in the spring container using "request" scope. So you could just autowire that bean directly into SomeService. This would essentially transparently deal with the instantiation so you don't need to manually instantiate MyDataBeanWithDependency from within the service.

Hopefully I've done enough to explain myself here!