Develop Reference

Spring #Transactional and long-running business logic

I am having some problems with Spring #Transactional and hope to find a solution here. I have a method in the service labeled as #Transactional which works by calling a method to request data via HTTP protocol (I'm using Apache HttpClient now), parsing the response and writing the result to the database. Since it all works in one method I'm afraid that this may cause transaction cancellation, because my project has a transaction time limit and request from external API may be really long.
Here I would like an answer on how to most correctly separate HTTP request+response parsing and database operations in such a case. As an option it is possible to have two methods one for transaction and the other for the rest of the logic, but I already have an assumption that there is a generally accepted design pattern for such tasks.

Different types of I/O in single #Tranactional method could cause trouble. If the API call responds very slowly for a while, this method would hold the borrowed Connection while waiting for the response.
You must break the single method.
Method1 will make the rest call. Response received with http status code 200 OK. Store it in suitable collection.
Method 2 will process records from method 1. You can explore on TransactionTemplate.
Refer - Sample code for reference, Sample code here

Java listener for a REST Call

I have to write a java listener service for a response of a rest call. Then I am going to read the response json and do my own logic depend on the response fields.
Since i am going to use a external rest service, i am finding hard to think how pattern like observe and observable can apply this kind of situation.
How can i listen to the rest response?

XSS prevention for REST calls

We are facing problems with XSS attacks to our application. We are preventing this by using normal filters for GET requests.
We are using RESTEasy REST webservice calls to our application. Our filter not filtering the data inside form GET/POST/DELETE/PUT requests.
The basic requirment is we need to check the XSS attacks on all the fields,headers and cookies as well.
How do we get the posted values before invoking the method. Just like filters what we did for normal requests.
I am using resteasy2.0 version for our app.
Is there anyway to update the request wrapper before going to invoke rest method.
Please give us some suggestions on this. Thanks in advance.
Thanks,
Govind.

Resteasy 2.0 allows you to use Interceptors on JAX-RS invocations and route them through listener-like objects.
You can declare an interceptor to check your request body and/or header before a JAX-RS resource method is invoked.
You can give a look to the docs here : Resteasy Interceptors Documentation
An example on how use it : Resteasy Interceptors Example

If I have understood it properly you want a filter like in Servlet so that you can handle each request before it hit the REST function. It will also keep your implementation common for all REST alls. Correct me if I am wrong.
One simple solution coming in my mind though I never worked with resteasy2.0.
You can write a common function and call that function from your REST methods first line. Check for scripting elements in that function and if found throw error or do something else.

ServletRequest/ServletResponse manipulation

I want to implement an advanced Java servlet filter for processing batch requests on API server. Something similar to the Facebook batch request API. The idea is:
setup servlet filter on given url
override doFilter(request, response), here:
parse list of partial requests from body, for each:
prepare partial request
call chain.doFilter(partialRequest, partialResponse)
remember partial response
render response with list of partial responses
I am able to construct HttpServletRequestWrapper for each partial request, and create HttpServletResponseWrapper with some output stream cheating, but this is a bit hard, I have to change almost all parts, path, body, headers etc.
Are there any good library for request/response manipulation, or better request/response wrapper class?

I understand that you want to consolidate as many requests as possible into one, but I don't think you would de-consolidate them on the back-end.
I think your approach complicates things, and I'm not even sure if it's possible to spawn new HttpRequest objects on the back-end.
Drop the filters, stick with one request (on the front-end and back-end), and spawn a new Thread for each task in your request.

Retrospective update for those you interested:
Finally I have dived for one full day into HttpServletRequestWrapper and HttpServletResponseWrapper dark forest and have done fully functional batch filter providing multiple requests to servlet and aggregating responses.
Unfortunately this filter must be the last filter in a row just before servlet, because subsequent filters are called only once.

Way to design app that uses http requests

In my app I have, for example, 3 logical blocks, created by user in such order:
FirstBlock -> SecondBlock -> ThirdBlock
This is no class-inheritance between them (each of them doesn't extends any other), but logical-inheritance exists (for example Image contains Area contains Message). Sorry, I'm not strong in terms - hope you'll understand me.
Each of blocks sends requests to server (to create infromation about it on server side) and then handles responses independently (but using same implementation of http client). Just like at that image (red lines are responses, black - requests).
http://s2.ipicture.ru/uploads/20120121/z56Sr62E.png
Question
Is it good model? Or it's better to create a some controller-class, that will send requests by it's own, and then handle responses end redirect results to my blocks? Or should implementation of http client be controller itself?
P.S. If I forgot to provide some information - please, tell me. Also if there a errors in my English - please, edit question.

Here's why I would go with a separate controller class to handle the HTTP requests and responses:
Reduce code duplication (do you really need three separate HTTP implementations?)
If/when the communication protocol between your app and server changes, you have to rewrite all your classes. Say for example you add another field to your response payload and your app isn't built to handle it, you now have to rewrite FirstBlock, SecondBlock, and ThirdBlock. Not ideal.
Modify your Implementation of HTTP client controller class such that:
All HTTP requests/responses go through it
It is responsible for routing the responses to the appropriate class.
Advantages?
If/when you change the communication protocol, all the relevant code is in this controller class and you don't have to touch FirstBlock, SecondBlock, or ThirdBlock
Debugging your HTTP requests!

I would suggest that your 3 blocks not deal with HttpClient directly. They should each deal with some interface which handles the remote connection sending of the request and processing of the results. For example:
public interface FirstBlockConnector {
public SomeResultObject askForSomeResult(SomeRequestObject request);
}
Then the details of the HTTP request and response will be in the connector implementations. You may find that you only need one connector that implements all 3 RPC interfaces. Once you separate out the RPC mechanisms then you can find common code in the implementations that actually deal with the HttpClient object. You can also swap out HTTP with another RPC mechanism without changing your block code.
In terms of controllers, I think of them being a web-server side term and not for the client but maybe you meant a connector like the above.
Hope this helps.