Announcement Announcement Module
No announcement yet.
How do I handle transient fields with IoC? Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • How do I handle transient fields with IoC?

    Hi all,
    I just used the FindBugs app on the source from the Spring MVC Step by Step tutorial and it found a couple of easily fixed bugs/problems and one problem that I don't know how to handle.
    The thing is that some of the classes in the tutorial implements, which means that any non-serializable fields in those classes should be marked as transient. This in turn means that you have to set the values of these transient fields yourself in the private void readObject(ObjectInputStream) method. But this "breaks" the IoC paradigm because the class must look up the value of the field by itself.

    This problem occurs with the class db.ProductManagerDaoJdbc which has a javax.sql.DataSource field. The field is not serializable and so must be transient, but how do I get hold of a DataSource object when the class is being deserialized?

    Is there any good solutions to this "problem"?

  • #2
    The DataSource interface itself may not be Serializable but its implementation might be. The class might take care by itself of serializing the field or somebody else (think of a serialization framework which might contain a dataSource transformer) could hydrate/dehydrate the field.


    • #3
      Hi, thanks for the answer.
      In the specific case of a DataSource it may very well exist serializable implementations, but if you look at the problem in a more general way, i.e. how to handle fields of any non-serializable type, it is still a headache to get the field value back when deserializing. I was hoping that someone has found/invented some kind of design pattern to handle this problem. Maybe get the application context/beanfactory to "repopulate" the transient fields?


      • #4
        I am not aware of any silver bullet in this area since there are so many cases that can appear when deserializing a field.
        As you mentioned, one can do a look for the field, can create it manually or even rely on AspectJ and @Configurable annotation to get an object dependencies from Spring.
        As I mentioned before, when persistence framework come into play where an interceptor/listener/userType can add custom behavior and alter the way things are dehydrated/hydrated you get a very divided picture where each piece might require a different strategy.


        • #5
          The same question here, too ...

          Sorry to ask almost the same question, but I want to be absolutely sure there's no answer before I go "inventing the wheel". I have many uses for this in my app.

          For example...

          I have stateful POJO, Person, that I want to be replicatable for clustering, therefore Person would be Serializable. That POJO needs access to PersonMetadata, but I don't want PersonMetadata replicated so I mark the reference to it as transient in the Person. (There's no point to replicate PersonMetadata because end users don't change it and it can easily be retrieved on any server in the cluster.)

          public class Person{
          private transient PersonMetadata personMetadata;
          public void setPersonMetadata(PersonMetadata personMetadata){this.personMetadata = personMetadata;}
          When I initially construct a Person, I use Spring to help me inject the PersonMetadata in to the Person and that works great. But when I replicate Person, is there any "nice" pattern for getting access to the AppContext in order to repeat the process of injecting PersonMetadata in to Person upon deserialization?

          Last edited by ebatzdor; Nov 18th, 2006, 01:27 PM.