Re: SESSIONS.ser error in tomcat 6.0 with restlet 2.0
Hello Iván,
it seems this is a configuration issue with Tomcat about persistent
connections (see here [0], for example). A Restlet based application is
totally unaware of such feature.
Best regards,
Thierry Boileau
[0] http://wiki.webratio.com/index.php/Avoiding_Persistent_Tomcat_Sessions
Hello,
I have a problem with a very simple application when I deploy it in tomcat
6.0.
The deploy process is right and the application is working, but sometime
after the application has been deployed it doesn't work anymore.
The application is the following:
public class MMApplication extends Application {
public MMApplication() {
}
public MMApplication(Context parentContext) {
super(parentContext);
}
@Override
public synchronized Restlet createInboundRoot() {
Router router = new Router(getContext());
router.attach(/users/{username}, UserResource.class);
router.attach(/messages, MessagesResource.class);
return router;
}
In tomcat log I can see the following error:
INFO: Repliegue (undeploy) de la aplicación web que tiene como trayectoria
de contexto /MM
13-mar-2010 9:54:22 org.apache.catalina.session.StandardManager doUnload
GRAVE: IOException al salvar sesiones persistidas:
java.io.FileNotFoundException:
/home/foss/apache-tomcat-6.0.20/work/Catalina/localhost/MM/SESSIONS.ser (No
such file or directory)
java.io.FileNotFoundException:
/home/foss/apache-tomcat-6.0.20/work/Catalina/localhost/MM/SESSIONS.ser (No
such file or directory)
at java.io.FileOutputStream.open(Native Method)
at java.io.FileOutputStream.init(FileOutputStream.java:179)
at java.io.FileOutputStream.init(FileOutputStream.java:70)
at
org.apache.catalina.session.StandardManager.doUnload(StandardManager.java:489)
at
org.apache.catalina.session.StandardManager.unload(StandardManager.java:463)
at
org.apache.catalina.session.StandardManager.stop(StandardManager.java:667)
at
org.apache.catalina.core.StandardContext.stop(StandardContext.java:4573)
at
org.apache.catalina.core.ContainerBase.removeChild(ContainerBase.java:924)
at
org.apache.catalina.startup.HostConfig.checkResources(HostConfig.java:1103)
at org.apache.catalina.startup.HostConfig.check(HostConfig.java:1271)
at
org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:296)
at
org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119)
at
org.apache.catalina.core.ContainerBase.backgroundProcess(ContainerBase.java:1337)
at
org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1601)
at
org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1610)
at
org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(ContainerBase.java:1590)
at java.lang.Thread.run(Thread.java:619)
13-mar-2010 9:54:22 org.apache.catalina.session.StandardManager stop
GRAVE: Excepción descargando sesiones a almacenamiento persistente
java.io.FileNotFoundException:
/home/foss/apache-tomcat-6.0.20/work/Catalina/localhost/MM/SESSIONS.ser (No
such file or directory)
at java.io.FileOutputStream.open(Native Method)
at java.io.FileOutputStream.init(FileOutputStream.java:179)
at java.io.FileOutputStream.init(FileOutputStream.java:70)
at
org.apache.catalina.session.StandardManager.doUnload(StandardManager.java:489)
at
org.apache.catalina.session.StandardManager.unload(StandardManager.java:463)
at
org.apache.catalina.session.StandardManager.stop(StandardManager.java:667)
at
org.apache.catalina.core.StandardContext.stop(StandardContext.java:4573)
at
org.apache.catalina.core.ContainerBase.removeChild(ContainerBase.java:924)
at
org.apache.catalina.startup.HostConfig.checkResources(HostConfig.java:1103)
at org.apache.catalina.startup.HostConfig.check(HostConfig.java:1271)
at
org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:296)
at
org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119)
at
org.apache.catalina.core.ContainerBase.backgroundProcess(ContainerBase.java:1337)
at
org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1601)
at
org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1610)
at
org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(ContainerBase.java:1590)
at java.lang.Thread.run(Thread.java:619)
The web.xml file is:
?xml version=1.0 encoding=UTF-8?
web-app xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
Re: Access to HttpSession from Restlet ...
FYI, Bruno's patch has just been applied to SVN trunk. Best regards, Jerome Le 03/03/2010 12:27, Bruno Harbulot a écrit : Hi, I've just submitted a patch: http://restlet.tigris.org/issues/show_bug.cgi?id=1050 It can be useful for some applications to have access to the TLS session ID. (This could possibly be used by some ongoing FOAF+SSL work for example.) Regarding the use of SSL session ID for maintaining session, this discussion should be of interest: https://issues.apache.org/bugzilla/show_bug.cgi?id=22679 Basically, nothing even guarantees that the same session ID will be used for multiple requests (it's not just about those 10-15 minutes). In addition, what RFC2818http://tools.ietf.org/html/rfc2818 says about (TLS) sessions is: - Note that an implementation which does this MAY choose to reuse the session. [...] - It MAY resume a TLS session closed in this fashion. - Servers SHOULD be willing to resume TLS sessions closed in this fashion. - As specified in [RFC2246], any implementation which receives a connection close without first receiving a valid closure alert (a premature close) MUST NOT reuse that session. It's quoted out of context, but they're all MAYs and SHOULDs (except about invalidating the session), which implies very little in terms of what can be expected from the session ID, regarding application session management. Best wishes, Bruno. Stefan Meissner wrote: Ok Bruno, thanks for your assessement. I'll forward your expert's opinion to the architect who gave me this task :) But generally 10-15 minutes life-time of the session would be sufficient for my use-case. best regards Stefan -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2452215 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2454411 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2459829
Strange problem with redirection
Gentlemen, first of all: congratulations to the restlet team for making available such an excellent framework! Restlet is true fun to work with! Still, I currently have a strange problem that someone might be able to give me a hint for: I'm running restlet 2.0M7 JavaSE edition directly with the internal web server. I am creating a standard Engine with a simple Component containing a very simple Application whose inboundRoot is a Router with a route mapping / to a Redirector to file://c/xyz/home.html. When I access the root URL I get a port out of range exception because for some reason the redirector redirects to an HTTP client instead of a FILE client. This is my log (on level FINE): 18:26:55.648 [main] DEBUG o.r.e.c.ComponentClientDispatcher - The connector has been instantiated without any protocol. 18:26:55.648 [main] DEBUG o.r.e.c.ComponentServerDispatcher - The connector has been instantiated without any protocol. 18:26:55.648 [main] DEBUG o.r.e.c.ChildClientDispatcher - The connector has been instantiated without any protocol. 18:26:55.664 [main] DEBUG o.r.e.c.ChildClientDispatcher - The connector has been instantiated without any protocol. 18:26:55.664 [main] DEBUG o.r.e.c.ChildClientDispatcher - The connector has been instantiated without any protocol. 18:26:55.664 [main] DEBUG o.r.e.c.ChildClientDispatcher - The connector has been instantiated without any protocol. 18:26:55.664 [main] DEBUG o.r.e.c.ChildClientDispatcher - The connector has been instantiated without any protocol. 18:26:55.679 [main] DEBUG o.r.e.c.ChildClientDispatcher - The connector has been instantiated without any protocol. 18:26:55.679 [main] DEBUG o.r.e.c.ChildClientDispatcher - The connector has been instantiated without any protocol. 18:26:55.679 [main] DEBUG o.r.e.c.ChildClientDispatcher - The connector has been instantiated without any protocol. 18:26:55.695 [main] DEBUG o.r.e.c.ChildClientDispatcher - The connector has been instantiated without any protocol. 18:26:55.695 [main] INFO o.r.PricingEngineComponent.Client - Starting the default HTTP client 18:26:55.961 [main] INFO o.r.PricingEngineComponent.Server - Starting the default HTTP server 18:26:55.992 [main] DEBUG org.restlet.PricingEngineApplication - The connector has been instantiated without any protocol. 18:26:55.992 [main] DEBUG org.restlet.PricingEngineApplication - The connector has been instantiated without any protocol. 18:26:55.992 [main] INFO com.xyz.tariffs.PricingEngine - PricingEngine SERVER ONLINE after 1.391 sec 18:26:59.320 [Restlet-213274] DEBUG o.r.PricingEngineComponent.LogFilter - The connector has been instantiated without any protocol. 18:26:59.320 [Restlet-213274] DEBUG o.r.P.ServerRouter - The default host was selected. 18:26:59.320 [Restlet-213274] DEBUG o.r.P.ServerRouter - New base URI: http://coxxp:8182 18:26:59.320 [Restlet-213274] DEBUG o.r.P.ServerRouter - New remaining part: / 18:26:59.320 [Restlet-213274] DEBUG org.restlet.VirtualHost - This route was selected: - com.discovergy.tariffs.pricingengineapplicat...@8e32e7 18:26:59.320 [Restlet-213274] DEBUG org.restlet.VirtualHost - New base URI: http://coxxp:8182 18:26:59.320 [Restlet-213274] DEBUG org.restlet.VirtualHost - New remaining part: / 18:26:59.320 [Restlet-213274] DEBUG org.restlet.VirtualHost - Delegating the call to the target Restlet 18:26:59.320 [Restlet-213274] DEBUG org.restlet.PricingEngineApplication - This route was selected: / - org.restlet.routing.redirec...@1d62270 18:26:59.320 [Restlet-213274] DEBUG org.restlet.PricingEngineApplication - New base URI: http://coxxp:8182/ 18:26:59.320 [Restlet-213274] DEBUG org.restlet.PricingEngineApplication - New remaining part: 18:26:59.320 [Restlet-213274] DEBUG org.restlet.PricingEngineApplication - Delegating the call to the target Restlet 18:26:59.320 [Restlet-213274] INFO org.restlet.PricingEngineApplication - Redirecting via client dispatcher to: file://c/xyz/home.html 18:26:59.320 [Restlet-213274] DEBUG o.r.P.ClientRouter - This client was selected: [HTTP] 18:26:59.320 [Restlet-213274] DEBUG o.r.P.ClientRouter - New base URI: 18:26:59.320 [Restlet-213274] DEBUG o.r.P.ClientRouter - New remaining part: file://c/xyz/home.html 18:26:59.320 [Restlet-213274] DEBUG o.r.P.ClientRouter - Delegating the call to the target Restlet 18:26:59.398 [Restlet-1152907] ERROR o.r.PricingEngineComponent.Client - Thread: Restlet-1152907 terminated with exception: port out of range:-1 java.lang.IllegalArgumentException: port out of range:-1 at java.net.InetSocketAddress.init(InetSocketAddress.java:118) [na:1.6.0_14] at org.restlet.engine.http.connector.BaseClientHelper.handleOutbound(BaseClientHelper.java:547) [org.restlet.jar:na] at org.restlet.engine.http.connector.ControllerTask$4.run(ControllerTask.java:139) [org.restlet.jar:na] at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [na:1.6.0_14] at
A GET with query parameters?
Hi,
I'm using restlet with google app engine, but think this is just a general
restlet question.
I want to support a GET method where the user can supply some query parameters
like:
http://mysite.com/farms/size=n
so the user can do a GET on the farms list but only return a list of farms that
have a size of N. What's the proper way to do this with restlet?
I've got this:
router.attach(/farms/{size}, Farm.class);
public class Farm extends ServerResource {
@Get
public String represent() {
Request request = getRequest();
String params = getRequest().getAttributes().get(size);
}
}
that works, I'll get size=12 etc. Is this the right way to do it, or is there
some more structured approach to parameters? If I have like 12 parameters, I
have to explode the string etc etc to get the param names and their values and
all that fun stuff. No big deal, just want to know if this is the right way to
go.
Thanks
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2460126
Re: A GET with query parameters?
Hi,
Any specific reason why you don't want to use a normal query like this?
http://mysite.com/farms?size=n
You could then get the query parameters with:
Form queryParams = getRequest().getResourceRef().getQueryAsForm();
String size = queryParams.getFirstValue(size);
Best wishes,
Bruno.
dj wrote:
Hi,
I'm using restlet with google app engine, but think this is just a general
restlet question.
I want to support a GET method where the user can supply some query
parameters like:
http://mysite.com/farms/size=n
so the user can do a GET on the farms list but only return a list of farms
that have a size of N. What's the proper way to do this with restlet?
I've got this:
router.attach(/farms/{size}, Farm.class);
public class Farm extends ServerResource {
@Get
public String represent() {
Request request = getRequest();
String params = getRequest().getAttributes().get(size);
}
}
that works, I'll get size=12 etc. Is this the right way to do it, or is
there some more structured approach to parameters? If I have like 12
parameters, I have to explode the string etc etc to get the param names and
their values and all that fun stuff. No big deal, just want to know if this
is the right way to go.
Thanks
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2460126
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2460147
Content type negotiation with annotations
Hi,
Firstly, I'd like to write a ServerResource that uses @Get(xml) and
@Get(html) for content negotiation on GET but not on POST (where it
would return a different content-type depending on what the method does,
or do the negotiation internally).
Secondly, I'd like to be able to post some
application/x-www-form-urlencoded content and get another type in return.
public class MyResource extends
ServerResource {
@Override
protected void doInit() throws ResourceException {
super.doInit();
setNegotiated(true);
getVariants().add(new Variant(MediaType.TEXT_HTML));
getVariants().add(new Variant(MediaType.APPLICATION_XHTML));
getVariants().add(new Variant(MediaType.APPLICATION_RDF_XML));
}
@Get(html)
public Representation toHtml() throws ResourceException {
...
}
@Get(xml)
public Representation toXml() throws ResourceException {
...
}
@Post
public Representation accept(Representation entity) throws
ResourceException {
...
}
}
At the moment, if I turn off the content-type negotiation
(setNegotiated(false)), then 'accept' is being called up receiving a
POST request. If content-negotiation is on (setNegotiated(true)), I get
a 405 (method not allowed) error.
It looks like this is due to the logic in doNegotiatedHandle(), which
I'd rather not override.
I'm not entirely sure it's because of the content-type negotiation on
the returned type, but it might be due to the input type too. (Hence the
second part of this problem.)
I've tried this @Post(html), @Post(xml) and @Post(html|xml), but
they're never called anyway, so it doesn't seem to have much to do with
the negotiated return type (the browser accepts */* by the way).
What's posted is of type application/x-www-form-urlencoded. It looks
like the @Post annotation make the negotiation on the input type too.
If I tweak client to send the same content as text/html, the
@Post(html) is called. This seems a bit wrong (posting
x-www-form-urlencoded forms and getting HTML in return seems quite
common, and that doesn't seem feasible if content-type negotiation is on).
Did I miss something? Any workarounds?
Best wishes,
Bruno.
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2460162
Restlet Framework 2.0 RC1 released
Hi all, The first 2.0 release candidate is finally ready. Please help us with bugs reports, patches and wiki contributions, to ship a rock solid 2.0.0 version! http://blog.noelios.com/2010/03/15/restlet-framework-2-0-rc1-released/ Best regards, Jerome Louvel -- Restlet ~ Founder and Technical Lead ~ http://www.restlet.org Noelios Technologies ~ http://www.noelios.com -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2460201
