Announcement Announcement Module
Collapse
No announcement yet.
Neither singleton nor prototype Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Neither singleton nor prototype

    Hi,

    I'm designing a web application with its own set of view classes using Spring and WebWork/Xwork. I use the existing Spring-WebWork integration project to get action instances from Spring. Xwork requires these actions to be prototypes, so that's how I've got them configured.

    However, my view classes also need to come from Spring. They need to be wired with the model, being the actions. However, I cannot ask for the same action instance twice since they are configured as prototypes. This means my view classes receive a new action instance that has not been properly executed by Xwork and thus does not contain any data.

    I came up with a solution which involves registering the action after it has been properly executed as a ThreadLocal variable by a custom Xwork result class that is picked up by a factory bean configured in Spring. When the view class is being retrieved by the same result class, the factory bean returns the thread variable. The advantage of this setup is that the view classes can be wired with other view-related classes using Spring. The disadvantage hides in the fact that the factory bean method that returns the action can only return an object of type com.opensymphony.xwork.Action. This means the setter method that accepts the action needs to cast it to the proper type.

    My first question is if this casting is a Bad Thing or not. For one thing, any other solution would require a setter method accepting the correct type. Although the casting may not seem so bad then, it does hide the actual required class type from the view class API, which seems like bad design to me. In the end, Spring was born to address this sort of anti-pattern.

    My second question is whether Spring offers any mechanism to implement this properly. I've been thinking about developing a thread-based lifecycle addition to Spring. It would store prototypes returned by Spring in a ThreadLocal variable. Consecutive retrievals of the same bean (name) from within the same thread would return the same instance. If it could be propertly implemented and well documented on when to use it it may benefit some other projects as well.

    Thanks for your feedback.

  • #2
    Have you looked at ThreadLocalTargetSource? I think this does what you want. Although I must say I've seldom found a convincing use case for it.

    Comment


    • #3
      singleton per thread

      Originally posted by Rod Johnson
      Have you looked at ThreadLocalTargetSource? I think this does what you want. Although I must say I've seldom found a convincing use case for it.
      Thanks for your feedback Rod, ThreadLocalTargetSource seems perfect for my requirement. Just for my understanding, can you tell me if you regard passing the model to the view as I described as a valid use case for ThreadLocalTargetSource?

      It looks save to me as the lifecycle of the model and view beans is managed by the controller (WebWork/Xwork). For example, the view classes will only be fetched from the bean factory if the view actually needs to be rendered.

      Comment

      Working...
      X