> If you have time to help with the RFE, maybe by providing a patch, it could 
> still go into the upcoming 1.1 release :) 

I posted a fairly non-invasive patch and additional class to the RFE. I'm sure 
you could improve upon it. 

http://restlet.tigris.org/issues/show_bug.cgi?id=157 

It adds a LoopbackDispatcher class that is aware of both the client and server 
routers in the component and can loopback certain request roots only if 
explicitly told to do so by an attribute set in the ComponentContext: 

List<String> loopbacks = new ArrayList<String>(); 
loopbacks.add("https://localhost:8443/usrv";); 
component.getContext().getAttributes().put("loopback.list",loopbacks); 

This seems to work as one would expect, with the expected performance gain and 
negligible cost. 

I explored down the road of attempting to transparently poll server routes 
before dispatching to any client routes. (If a valid HostRoute attached to the 
server router could handle the request, prefer it to using a Client.) This 
doesn't work well, because the host routes are generally greedy, and there is 
probably a default host that will claim it can handle anything, even things it 
shouldn't. I suspect that transparently magical loopback behavior is going to 
cause massive confusion for somebody at some point, especially if their 
Restlets are running inside a larger container. I even confused myself :-) 

This explicitly coded approach seems to do what I need it to do, without 
breaking anything that currently exists ... thoughts? 

- Rob 

Reply via email to