batBot:Action

From WikiJava

After each request it should be performed a configurable action on the returned HTML

Contents 1 Manager 2 Feature Groups 2.1 configuration 2.1.1 add the command element in the config.xml 2.1.2 make the fileHelper manage the command Element 2.2 call the action 2.2.1 create a dummy action 2.2.2 extract interface from the dummy action 2.2.3 create the new bean in the applicationcontext.xml 2.2.4 create getAction in BatBotResourceFactory.java 2.3 make the action do something 2.3.1 convert the HTTPHelper Class to return a response object 2.3.2 make the Action Interface get a Response Object as parameter 2.3.3 Create a new Action printing the output from the request into a File 2.4 modify the config.xml 2.4.1 Remove the beans from the application context 2.4.2 Split the action from its executor 2.4.3 the Request creates and starts the executor 2.5 make sure that each request can call only one Action per time 2.5.1 More tasks here 3 See also

Manager

User:DonGiulio is the manager for this requirement. Send DonGiulio an email

Feature Groups

configuration

the action to be performed should be assigned for each request, so that each request has it's own action.

add the command element in the config.xml

make the fileHelper manage the command Element

call the action

the request should call the action right after receiving the response to the request. The action should be executed on a separate thread.

create a dummy action

the action just does nothing, but it does it in multithreading with synchronized methods .

extract interface from the dummy action

the interface is necessary so we can generate many dummy actions and implement the command pattern

create the new bean in the applicationcontext.xml

We want to create these objects via Spring

create getAction in BatBotResourceFactory.java

so we get the factory method for obtaining actions note that the action is specified in the request object via a String. a first approximation should be that that string is given to the getAction(String actionName) method, who uses that string straight away as the name for the Bean in Spring. in this way we already don't need to re-compile each time we create a new action, adding it to the beans will suffice

make the action do something

convert the HTTPHelper Class to return a response object

all the info about the response obtained should be packed in the Response Object.

make the Action Interface get a Response Object as parameter

using the object the Action will be able to run and perform its tasks

Create a new Action printing the output from the request into a File

just another more complex dummy action to show that we can actually do whatever we like.

modify the config.xml

Add to the action in the configuration the parameters for configuring the action. the action has no alias in the XSTREAM so the element is mentioned using the fully qualified name.

Remove the beans from the application context

if we use xstream for deserializing the object then we don't need Spring to take care of it.

Split the action from its executor

the serialiser tries to persist all the fields inherited from Thread generating a CircularReferenceException. The object persisted can't be the one executing the thread. we must implement the executor in a separate class..

the Request creates and starts the executor

passing to the executor the Action object, which contains all the info (and the methods) about the action requested.

make sure that each request can call only one Action per time

using synchronization. it depends on the action if forget about successive call while it was running and consider only the last call, or forget about everything. this is for another featureGroup. What we want now is just to make sure that calls to the action while the action was running are queued. and passed to the action after it's done.

More tasks here

===

See also

• Project Main page
• Contributions page