executing a HTML directly.
Hi,
I need to execute a HTML file from the classpath using CLAP. for
that i have written the following code, which is not working. can any one
please help me... when a request come for a HTML page, i need to execute
that directly. that is the requirement.
*in Application class createRoot() *
router.attach(/,new StaticPageService(getContext()));
*The StaticPageService is a sub class of restlet. *
public void handle(final Request request, final Response response) {
Directory directory = new
Directory(getContext(),clap://class/HTML);
try {
Response resp =
directory.get(request.getResourceRef().getPath());
if (resp.getStatus().isSuccess()) {
response.setEntity(resp.getEntity());
}
---
---
my assumption here is that response.setEntity will execute that requested
page from HTML folder in class path and sends that as response. -- if it is
not correct process can any one tell me what is the better way of executing
html with restlet?
Application and Resource lifecycle
Dear all, I am using Restlet with an IoC container (i.e., Plexus) and I would like to ask some questions about the lifecycle of some Restlet objects in order to decide which policy I have to choose for their instantiation and how to handle them. 1) Is ServletServer.createApplication() called only once during application lifetime? 2) Is Application.createRoot() called only once during application lifetime? (Probably a positive answer to 1 will also answer this) 3) Are resource re-usable? I mean, if I have an instance of a Resource, may I call init() in order to make the same instance serve different requests? Thanks for your help. -Fabio -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1007325
Redirect broken on Tomcat 5.0.x
Ok, I know Tomcat 5.0.x is a really, really old servlet container and that people with brains should have upgraded long back. ..but I keep an instance around that I fire up every now and then just to test compatibility. The other day I was testing Nexus, the excellent Maven repository manager from Sonatype. On Tomcat 5.0.30, the front page failed to display, I only got a blank page. After a bit of digging around I that the blank page was because of HTTP 301 redirects in Noelios engine didn't work on Tomcat 5.0.x The reason is that Noelios adds a Content-Length header with a value of 0 before adding other headers and eventually setting the status code. Setting the Content-Length to 0 on Tomcat 5.0.x effectively prevents any other headers or status coded being set because the response is considered to be committed according to the servlet spec. I'll admit that supporting Tomcat 5.0.x is a small gain here, but then fixing it shouldn't be all that hard either. Setting the Content-length header after setting status code and adding all other headers should work. Other containers might also have the same issue since the spec isn't very clear on this. I reported this in Sonatype's issue tracker, but they probably won't be able to fix this unless it's fixed by you guys upstream. https://issues.sonatype.org/browse/NEXUS-1303 Thanks, Eirik. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1006267
Re: Application and Resource lifecycle
Yes, Yes, No. Classes that extend Restlet (e.g. Application) are wired in, long lived elements of the web application plumbing. They need to be thread safe, as multiple requests in different threads will traverse them. Classes that extend Resource are instantiated per request. They need not be thread-safe. On Tue, Jan 6, 2009 at 6:23 AM, fabio.mancine...@gmail.com wrote: 1) Is ServletServer.createApplication() called only once during application lifetime? 2) Is Application.createRoot() called only once during application lifetime? (Probably a positive answer to 1 will also answer this) 3) Are resource re-usable? I mean, if I have an instance of a Resource, may I call init() in order to make the same instance serve different requests?
Re: Redirect broken on Tomcat 5.0.x
Cool. From what I understand the restlet engine will always add a Content-type: 0 header with no-entity responses, so that certainly sounds plausible if GWT hosted uses Tomcat 5.0.x. I started working on a patch but then I kind of put it aside when because of the long roundtrip and IDE trouble. It would be easier and more appealing for people like me to contribute if you guys had used Maven. Something to consider with your recent discussion around build systems on this list. Thanks, Eirik. On Tue, Jan 6, 2009 at 2:07 PM, Rob Heittman rob.heitt...@solertium.com wrote: This is almost certainly the same as the known bug in GWT hosted mode with no-entity responses. If the order of writing this header fixes the problem transparently, it would be awesome to do it! On Mon, Jan 5, 2009 at 5:45 PM, Eirik Bjørsnøs eir...@gmail.com wrote: Setting the Content-Length to 0 on Tomcat 5.0.x effectively prevents any other headers or status coded being set because the response is considered to be committed according to the servlet spec.
RE: Exception-resistant filters
Did it with a custom StatusService. I have some code duplication in the filter for successful requests and in the StatusService for handling exceptional cases. I don't think it's possible to do otherwise, but I am open to suggestions :) Thanks. -Fabio -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1008161
