3

In a Jetty-hosted webapp, I use a servlet filter to pull information out of URLs and sometimes route requests to non-Restlet servlets. For Restlet servlets, I want to be able to pass information to my ServerResource subclasses, and I think I should be able to do this by storing information in attributes on the HttpServletRequest. (Does Restlet support a different mechanism to achieve this? I couldn't find anything in "Restlet in Action" or here on stackoverflow.)

ServletAdapter copies servlet request attributes into Restlet HttpRequest's attributes, but its constructor takes a ServletContext parameter, and not a Context parameter like superclass (and default adapter) ServerAdaptor -- which doesn't copy over servlet request attributes -- so I can't use ServletAdapter to solve the problem.

The javadoc for HttpServerHelper, instantiated by ServerServlet.createServer(), claims that setting a context parameter named "adapter" to the class name of a ServerAdapter subclass will cause HttpServerHelper to use the specified class, but in my debugging, I can see that the "adapter" context parameter isn't present in the child context passed into the HttpServerHelper constructor via the pseudo-Server in ServerServlet.createServer(), though it is in the parent context. This looks to me like a bug: AFAICT, since child contexts don't carry their parent's attributes or parameters, HttpServerHelper as currently implemented will never see the parameter directing it use a non-default adapter. Maybe HttpServerHelper.getHelpedParameters() should add the "adapter" parameter from its "helped" server's context's parent context if it's not present in the child context? (This fix would also apply to the other parameter mentioned in the HttpServerHelper javadoc: "useForwardedForHeader".)

As a workaround, I've extended ServerServlet.createServer() to copy the "adapter" parameter into the child context it passes into HttpServerHelper. This works.

I've also subclassed ServerAdapter to copy servlet request attributes to the uniform request: a straight copy/paste from ServletAdaptor.toRequest(). This works too.

Steve Rowe
  • 136
  • 4

2 Answers2

1

Perhaps a workaround could be to implement another servlet filter that provides a global context for both servlet and restlet environment. This context could be stored within a ThreadLocal. In your restlet resources, you can have access to this context and your parameters...

Hope it helps you.

Thierry

Thierry Templier
  • 198,364
  • 44
  • 396
  • 360
  • FYI, an issue was entered by Thierry and recently fixed in branch 2.3 (see upcoming 2.3 M2): https://github.com/restlet/restlet-framework-java/issues/741 – Jerome Louvel Apr 01 '14 at 15:25
0

This is caused by issue 741 a fix will be available in Restlet Framework 2.3m2.

rds
  • 26,253
  • 19
  • 107
  • 134
Thierry Boileau
  • 866
  • 5
  • 8