aspose file tools*
The moose likes Spring and the fly likes Question on object instantiation that requires state Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Frameworks » Spring
Bookmark "Question on object instantiation that requires state" Watch "Question on object instantiation that requires state" New topic
Author

Question on object instantiation that requires state

Madhur Tanwani
Greenhorn

Joined: Sep 25, 2006
Posts: 9
Hello all,
I'm designing a "task chain" system and need to instantiate a "task chain" & "tasks" that form the chain and then run them (no - i'm not using any BPEL/ BPM techniques).

I think the "chain" and its constituents ("tasks") fit into Spring's object creation functionality - configurable, IOC, lists etc.. are all built in.

The problem I'm seeing now is that creation of some of these "tasks" objects requires "state" information. The state is available with the code portion creating (and using) the "chain". Every "task" (lets say) will also be passed the "state" when it is invoked.

What would be a good way to do this? I have a few thoughts, but would want to review them with the folks here :
1.> Instantiate and invoke a wrapper "task" that delegates the actual processing to a correct "task" object depending on the "state" passed to it.

2.> Lazy load the stateful-task using custom factories. Ensure that the factory gets the "state" in a ThreadLocal (or something)

Does that sound ok? Anything better? Please comment and let me know.

--
Madhur Tanwani
Mark Spritzler
ranger
Sheriff

Joined: Feb 05, 2001
Posts: 17257
    
    6

Off the top of my head, because I didn't put much thought into this.

But what about the Command pattern.

Also, is this a Spring question? If it is, then I will take tasks as being Services, and Services, Controllers, EndPoints, Repositories should never ever hold state that can change by user. State that doesn't change once it is instantiated is ok.

Mark


Perfect World Programming, LLC - Two Laptop Bag - Tube Organizer
How to Ask Questions the Smart Way FAQ
Hong Anderson
Ranch Hand

Joined: Jul 05, 2005
Posts: 1936
Could you please to give some example code of what you're trying to do?


SCJA 1.0, SCJP 1.4, SCWCD 1.4, SCBCD 1.3, SCJP 5.0, SCEA 5, SCBCD 5; OCUP - Fundamental, Intermediate and Advanced; IBM Certified Solution Designer - OOAD, vUML 2; SpringSource Certified Spring Professional
Madhur Tanwani
Greenhorn

Joined: Sep 25, 2006
Posts: 9
Kengkaj Sathianpantarit wrote:Could you please to give some example code of what you're trying to do?

Sure. Glad you asked.

I'm implementing this TaskChain as a chain of responsibility pattern :
T1 -> T2 -> T3 -> ... -> Tn
Each task does a specific processing on its inputs (say BillingInfo).

I'm outsourcing all the configuration of the task (Tn) objects, chain list piping and configuration to Spring. Thus, a task would be a bean configured via spring to form the chain.

Now, lets say there is a task that needs to performed on the basis of some state that the executor of this chain will initialize. Lets say this state information is "account type". Depending on the account type the tasks process inputs differently. Hence, there could be a task which needs to do this :
1.> if the account type is X, validate BillingInfo to not have Y
2.> if the account type is A, validate BillingInfo to have B & C

Now one solution is to implement a single task, and do the above if-then-else in it. I dont quite like this.
Other solution is to implement 2 separate tasks that just do the above and instantiate the correct one (and pipe it in the chain) depending the state (account type). That's what this question is about.

Thanks for reading & helping!
BTW the use cases above are not what I'm actually going to do - its just to convey my intention
Madhur Tanwani
Greenhorn

Joined: Sep 25, 2006
Posts: 9
Mark Spritzler wrote:Off the top of my head, because I didn't put much thought into this.

But what about the Command pattern.

Also, is this a Spring question? If it is, then I will take tasks as being Services, and Services, Controllers, EndPoints, Repositories should never ever hold state that can change by user. State that doesn't change once it is instantiated is ok.

Mark

That's correct, its not an ever changing state. The executor initializes the state and the tasks use it.

Command Pattern : Yes that's exactly what I was referring to with the "wrapper" class in option 1 - sorry my description was not very explicit.
Hong Anderson
Ranch Hand

Joined: Jul 05, 2005
Posts: 1936
I'm not sure do you mean you want Spring to instantiate task objects? If so why?
I think the application code should instantiate task objects. You can use Factory Method pattern.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Question on object instantiation that requires state