Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 356279

Summary: Attach startup request parameters to every request
Product: [RT] RAP Reporter: Stephan Leicht Vogt <stephan.leichtvogt>
Component: RWTAssignee: Project Inbox <rap-inbox>
Status: RESOLVED WONTFIX QA Contact:
Severity: enhancement    
Priority: P3 CC: chris
Version: 1.5   
Target Milestone: ---   
Hardware: All   
OS: All   
Whiteboard:

Description Stephan Leicht Vogt CLA 2011-08-31 03:24:07 EDT 
To call up a RAP Application url parameters can be put to the request. Those can be read with RWT.getRequest().getParameterMap().

I have for my application a filter on level application server who wants to read these parameters. But those are not on every request: req.getParameterMap().

Example:
http://<serverURL>:8080/rap.test/rap?urlParameter=testParameter

This parameter can be found with RWT.getRequest().getParameterMap(). But in the filter, which is before RWT, this parameter isn't on every call.

In the first request the parameter can be found.
In the second request only following parameters can be found:
- custom_service_handler
- hash

We need the custom parameters on every request.
Comment 1 Chris Fairhall CLA 2011-09-01 01:00:56 EDT 
> We need the custom parameters on every request.
If your application server has access to the http session then you can store the url parameter in there with RWT.getSessionStore().getHttpSession().setAttribute(...)
Comment 2 Rüdiger Herrmann CLA 2011-11-17 05:46:00 EST 
The parameters are meant as *startup* parameters, thus they should only be available at startup. If I would have to do it again today, I would rather pass them as an argument to the IEntryPoint#createUI() method. Much like the main(String[]) method in standalone Java programs.
If you really need the parameters throughout the whole application lifecycle, you can store them in the session like, e.g. like suggested in comment #1.
Comment 3 Stephan Leicht Vogt CLA 2011-11-17 05:50:29 EST 
Thats alright for us. Thanks for the insight.