Re: Unwanted removal of attribute suffix in Tomcat environment
Hello Tim, it did not seem to be that way, as the values of the HashMap did not get changed after initial setup - but I will look into it. Thanks for the hint! Regards, Lutz
Re: Unwanted removal of attribute suffix in Tomcat environment
Hello Thierry, I have finally managed to get rid of my problem - I am still not entirely sure why I encountered it in the first place, but anyway: In the simple demo app, I used to declare the template paths directly as static strings. In the more complex live app, the paths came from a HashMap - I have no clue why, but when I changed that and put in the paths as constant values at compile time, the problem ceased to exist. I am aware that this seems strange but if someone else encounters a similar problem - who knows, maybe this will help. At any rate - I have said it before, but cannot overemphasize it - thanks a great deal for your interest and your support in this matter! Best regards, Lutz
Re: Unwanted removal of attribute suffix in Tomcat environment
If the HashMap you were using was shared by multiple threads without appropriate synchronization, that might explain why you had problems in that setting but not with constant values. --tim On Sun, Jul 13, 2008 at 9:22 AM, Lutz Harder [EMAIL PROTECTED] wrote: Hello Thierry, I have finally managed to get rid of my problem - I am still not entirely sure why I encountered it in the first place, but anyway: In the simple demo app, I used to declare the template paths directly as static strings. In the more complex live app, the paths came from a HashMap - I have no clue why, but when I changed that and put in the paths as constant values at compile time, the problem ceased to exist. I am aware that this seems strange but if someone else encounters a similar problem - who knows, maybe this will help. At any rate - I have said it before, but cannot overemphasize it - thanks a great deal for your interest and your support in this matter! Best regards, Lutz
Re: Unwanted removal of attribute suffix in Tomcat environment
Hello Lutz, originally the extension filter was turned on by default. Since this behaviour is quite disturbing for unaware people, we decided to turn it off by default. As far as I know, two services rely on the metadataService (the one that declares the list of known extension) : tunnelFilter (via the filtering of extensions) and Directory (via the FileClientHelper). Could you try to update the metadataService (this is a property of Application instances) and empty the list of known extensions (application.getMetadataService().clearExtensions())? best regards, Thierry Boileau Hi Thierry, you were perfectly right, using the 1.1 libraries and sending the requests properly as described by you did the trick in the test application. Unfortunately, in the more complex real app, I am still having the original problem - so far I have not been able to find out where the decisive difference is: the resource returns the name of the given variable without the ending when it is a known mime-type. I will have to keep looking. Just to give me another clue - what has changed in terms of tunnelService and the extension filter that you mentioned in your first response? What happens in processing before the original request is passed on through the framework? At any rate - thanks a lot for your help and the time you have spent on this! Best regards, Lutz
Re: Unwanted removal of attribute suffix in Tomcat environment
Hi Thierry, you were perfectly right, using the 1.1 libraries and sending the requests properly as described by you did the trick in the test application. Unfortunately, in the more complex real app, I am still having the original problem - so far I have not been able to find out where the decisive difference is: the resource returns the name of the given variable without the ending when it is a known mime-type. I will have to keep looking. Just to give me another clue - what has changed in terms of tunnelService and the extension filter that you mentioned in your first response? What happens in processing before the original request is passed on through the framework? At any rate - thanks a lot for your help and the time you have spent on this! Best regards, Lutz
Re: Unwanted removal of attribute suffix in Tomcat environment
Hi Lutz,
when requesting manually (i.e. by typing the URI in my browser) the
three URIs in any order, it should works correctly (I mean it works for me).
Can you confirm this?
However, I've noticed the following thing.
When clicking on the back link of the third page, I go back to
http://myserver/myapp/test/foo/; instead of
http://myserver/myapp/test/; (because of the ending /). You can note
that the base URI is not the same, it ends with /test/foo/ instead
of /test/. Then, when clicking on any link, the requested URI is
http://myserver/myapp/test/foo/foo/bar.html;. When applying the
template /foo/{filename}, the value of the filename variable is
foo. I hope this is the cause of the problem.
best regards,
Thierry Boileau
Hello Thierry,
thanks a lot for responding so quickly and for your help - I greatly
appreciate it!
Apparently, you were at least partly right about the libraries - changing
them to the newer version 1.1 (Test) has changed the behavior - but it is
still not the way it should be...
I have prepared a very small WAR file to illustrate the problem - if you
are willing to download it, it should help to clarify the problem ( 500 kB,
Source code and libraries included): http://www.leonidat.de/test.war
Having updated the libraries at first seemed to do the trick - the endings
were accessible. However, once you send a request such as
http://myserver/maypp/test/foo/bar.html/; (with a / at the end), the old
problem is back again. You never get a suffix after one such request with a
trailing / until you restart the server or redeploy the application.
To illustrate that, I have prepared three examples in the WAR, just deploy it
in your tomcat, navigate to http://localhost:8080/test/; and try the three
links I have provided. Examples 1 and 2 will work fine. After clicking the
third link, the other two will have changed their behavior...
Any idea how to avoid that strange behavior? Obviously, I would not like to
rely on the hope that nobody will ever send a wrong request to the
service...
Thanks a great deal for your support!
Cheers,
Lutz
Re: Unwanted removal of attribute suffix in Tomcat environment
Hello Thierry, thanks a lot for responding so quickly and for your help - I greatly appreciate it! Apparently, you were at least partly right about the libraries - changing them to the newer version 1.1 (Test) has changed the behavior - but it is still not the way it should be... I have prepared a very small WAR file to illustrate the problem - if you are willing to download it, it should help to clarify the problem ( 500 kB, Source code and libraries included): http://www.leonidat.de/test.war Having updated the libraries at first seemed to do the trick - the endings were accessible. However, once you send a request such as http://myserver/maypp/test/foo/bar.html/; (with a / at the end), the old problem is back again. You never get a suffix after one such request with a trailing / until you restart the server or redeploy the application. To illustrate that, I have prepared three examples in the WAR, just deploy it in your tomcat, navigate to http://localhost:8080/test/; and try the three links I have provided. Examples 1 and 2 will work fine. After clicking the third link, the other two will have changed their behavior... Any idea how to avoid that strange behavior? Obviously, I would not like to rely on the hope that nobody will ever send a wrong request to the service... Thanks a great deal for your support! Cheers, Lutz
Re: Unwanted removal of attribute suffix in Tomcat environment
Hello Lutz,
I've just tried with Tomcat 6 (fresh install, no configuration) and it
works well for me.
What version of Restlet libraries are you using? It makes me think about
the tunnelService and the extension filter which has been disconnected
by default quite recently
Best regards,
Thierry Boileau
ps : do you know that you can code the GET response in the
represent(Variant) instead of handleGet?
Hi,
being fairly new with Restlet, I have encountered a problem
when trying to run an application in Tomcat via the
com.noelios.restlet.ext.servlet.ServerServlet
that runs fine standalone:
I am routing GET requests such as:
http://myserver/myapp/foo/mypic.gif
to a corresponding FooResource:
Router router = new Router( getContext() );
router.attach( /foo/{filename}, FooResource.class );
In the handleGet() method of FooResource, I need to
access the {filename} attribute:
public void handleGet()
{
String name = ( String ) getRequest().getAttributes().get( filename );
...
}
When running the application standalone, I get name = mypic.gif - everything
as expected.
Running the same code in a Tomcat 5.5 or Tomcat 6.0, however, the code results
in name = mypic - the suffix is omitted.
To my surprise, this is only the case for some endings, e.g. .gif or .html.
Endings which are (apparently) not connected to known mime types, such as
.xyz are passed on correctly.
I use the following web.xml to run the application under Tomcat:
?xml version=1.0 encoding=UTF-8?
web-app id=WebApp_ID version=2.4
xmlns=http://java.sun.com/xml/ns/j2ee;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://java.sun.com/xml/ns/j2ee
http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd;
!-- Application class name --
context-param
param-nameorg.restlet.application/param-name
param-valuede.myapp.MyApplication/param-value
/context-param
!-- Restlet adapter --
servlet
servlet-nameRestletServlet/servlet-name
servlet-classcom.noelios.restlet.ext.servlet.ServerServlet
/servlet-class
/servlet
/web-app
Is there anything I can do to ensure that under Tomcat, too,
I get the complete name including the suffix? I would greatly
appreciate any help anyone can provide.
Thanks in advance,
Lutz
