RE: Add http header for static files

[Jerome Louvel]

Hi all,

Also, note that the Last-Modified header is already supported by the Restlet
API via the Representation#modificationDate property. 

For details on mapping between HTTP headers and Restlet API see:
http://wiki.restlet.org/docs_1.1/g1/43-restlet/130-restlet.html 

We are planning to support more caching headers in Restlet 1.2, see RFE:

"Support caching HTTP headers"
http://restlet.tigris.org/issues/show_bug.cgi?id=213

Best regards,
Jerome


-Message d'origine-
De : Davide Angelocola [mailto:[EMAIL PROTECTED] 
Envoyé : lundi 30 juin 2008 14:00
À : discuss@restlet.tigris.org
Objet : Re: Add http header for static files

Hi, 

On Monday 30 June 2008 12:30:25 Thierry Boileau wrote:
> you can create a class that inherits from Directory and override the
> handle(Request, Response) method. If the response is successfull
> (response.getStatus().isSuccess()), then you can set the cache-control
> header just as Stephan said.

It could be also useful defining a strategy: during development I generally 
turn off caching; during production I turn on caching with various 
customizations. 

It would be nice to support these strategies directly in the restlet API.

-- 
Best Regards,
-- Davide Angelocola

Re: Delivering static files from Restlet-Servlet

[Thierry Boileau]

Hello Christian,

the configuration of a component in the context of a servlet container 
is only available with Restlet 1.1.
Could you try with Restlet 1.1M4 or the latest snapshot 
(http://www.restlet.org/downloads/)?


best regards,
Thierry Boileau



Hi,

I've read several comments on this mailing list (like this one: http://
thread.gmane.org/gmane.comp.java.restlet/4423) regarding delivering static 
files via Restlet, but I simply did not get it right. Is there anybody out 
there be so kind telling me what is wrong with my setup?


I'm using Restlet 1.0.10 with Tomcat 5.5.
web.xml looks like this:

=
...

  org.restlet.application
  de.denic.zone.nast.application.rest.NastApplication


  org.restlet.component
  de.denic.zone.nast.application.rest.MetaFileDeliveringComponent

...
=

The configured application works nicely providing all resources as desired.
My component looks like this:

=
public final class MetaFileDeliveringComponent extends Component {

  private static final class MyApplication extends Application {

private MyApplication(final Context context) {
  super(context);
}

@Override
public Restlet createRoot() {
  final Directory directory = new Directory(getContext(), "file:///d:/
Temp/");
  directory.setDeeplyAccessible(true);
  directory.setListingAllowed(true);
  return directory;
}
  }

  public MetaFileDeliveringComponent() {
super();
getClients().add(Protocol.FILE);
getDefaultHost().attach("/meta", new MyApplication(getContext()));
  }
=

But accessing the /{root-of-webapp}/meta path via GET requests gets code 404 
all the time.


Thanks in advance

Christian


  

Re: Unwanted removal of attribute suffix in Tomcat environment

[Thierry Boileau]

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:


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";>



 org.restlet.application
 de.myapp.MyApplication




  RestletServlet
  com.noelios.restlet.ext.servlet.ServerServlet
  




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 



  

Unwanted removal of attribute suffix in Tomcat environment

[Lutz Harder]

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:


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";>



 org.restlet.application
 de.myapp.MyApplication




  RestletServlet
  com.noelios.restlet.ext.servlet.ServerServlet
  




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 

Re: OSGi Extender for Restlet -- Fwd: OSGi manifests support

[Jerome Louvel]

Forwarding reply from Hendy below...
 
 -- Forwarded message --
From: Hendy Irawan <[EMAIL PROTECTED]>
Date: Fri, Jun 27, 2008 at 10:59 PM
Subject: Re: OSGi Extender for Restlet -- Fwd: OSGi manifests support
To: discuss@restlet.tigris.org



On Tue, Jun 17, 2008 at 1:43 PM, Jerome Louvel <[EMAIL PROTECTED]> wrote:


Hi all,
 
We already use the "META-INF/services" scanning mechanism to normally
(outside OSGi environments) register the NRE with the Restlet API and the
connectors or authentication helpers with the NRE. So, your solution would
be quite natural.
 
If we want to use a similar mechanism with OSGi, I guess that the scanning
requires usage of some OSGi APIs. This could be done in the NRE JAR/bundle
using the existing OSGi activator. This way, we wouldn't need any other
bundle activator and could reuse existing "META-INF/services" descriptor
files.
 
I've added a note about this solution here:
 
"OSGi integration"
http://wiki.restlet.org/docs_1.1/g1/43-restlet/124-restlet.html

Hendy, do you have a pointer regarding the OSGi API for classpath scanning
of "META-INF/services"? Also, if you want to work on a patch to remove the
unnecessary bundle activators using this mechanism, you are welcome.
 
Best regards,
Jerome


Ah, glad I looked into this thread again.

BTW, I have actually implemented that concept (Extender) with JSR223 and
OSGi. I'm working with the JSR223 guys to make the JARs OSGi-compliant, but
that's not the end. I also wanted the JSR223 engines to "register
automatically" with OSGi.

JSR223 uses exactly the same mechanism as "legacy Restlet", which is using
SPI or META-INF/services.

So I started a project, Pax-Script here:
http://wiki.ops4j.org/confluence/display/ops4j/Pax+Script

It monitors/extends installed JSR223 JARs and register OSGi services for
them automatically.

Feel free to look at the code or do anything (it's Apache Licensed) with it.
I may not be able to do much with actual Restlet work but I think it's a
good starting point:

http://scm.ops4j.org/browse/OPS4J/laboratory/users/ceefour/pax-script/trunk/
src/main/java/org/ops4j/pax/script/internal/ExtenderActivator.java
 

 

  _  

De : Mark Derricutt [mailto:[EMAIL PROTECTED] 
Envoyé : mardi 10 juin 2008 23:31
À : discuss@restlet.tigris.org
Objet : Re: OSGi Extender for Restlet -- Fwd: OSGi manifests support


Interesting..  This is exactly what I've implemented here at SMX.  I have my
rest bundle which wraps restlet, and monitors other bundles for the header
"SMX-Restlet-Provider" which points to an implementation of a
"RestletProvider" interface.

The restlet bundle tracks these these provider bundles come and go and
register/unregister restlets as required.  Works quite well.


On Wed, Jun 11, 2008 at 2:53 AM, Hendy Irawan <[EMAIL PROTECTED]>
wrote:


I just got into this discussion on JSR223 list regarding OSGi, and the
approach proposed by Felix (no pun intended) is very interesting.

For Restlet, which are already having proper OSGi manifests by now, it needs
not have Bundle Activator that registers Restlet services to OSGi. But we
can implement extender pattern that scans for bundles having
META-INF/services and register that as services (in JSR223 case,
ScriptEngineFactory).

On further thought this is very generic and can be applied for all Java
services (i.e. JARs containing META-INF/services), not just Restlet.

BTW this is only if the user restlets want to attach/find Restlet services
themselves, i.e when not using whiteboard pattern to register user restlets
to the OSGi "whiteboard".

One of the downsides (?) of the above approach is that it's not possible to
provide OSGi service properties, since META-INF/services only provide the
interface name and the concrete class, but no way of specifying OSGi service
properties, which might be useful for implementing whiteboard pattern as
well.

The upside is, the Java services extender can be an external bundle, like
the one in Apache Sling (I haven't looked into it yet) and not necessarily
an integral part of Restlet (but can be bundled i.e. for convenience with
OSGi users).



-- Forwarded message --
From: Hendy Irawan <[EMAIL PROTECTED]>
Date: Tue, Jun 10, 2008 at 9:46 PM
Subject: Re: OSGi manifests support
To: [EMAIL PROTECTED]



On Tue, Jun 10, 2008 at 6:56 PM, Felix Meschberger
<[EMAIL PROTECTED]> wrote:


Hi,

Am Dienstag, den 10.06.2008, 01:25 +0700 schrieb Hendy Irawan:

> Dear JSR223 developers,
>
> Learning from the success of OSGi-fying Groovy
> (http://jira.codehaus.org/browse/GROOVY-2876) I'd like to propose if
> OSGi-friendly manifest can be incorporated into JSR223 packages.
>
> This can be done straightforward using Peter Kriens' Bnd tool at
> http://www.aqute.biz/Code/Bnd
>
> If possible, it'd be preferable to register JSR223 scripting engine
> factories on OSGi runtimes using bundle activators so that they're
> directly usable using whiteboard pattern... This should also be
> unintrusive for non-OSGi usage (i.

SSL + Virtual Hosts and Issue #489?

[Alex Milowski]

I ran into a problem just yesterday with wildcard SSL certificates.  I
had a new keystore with
two wildcards certificates in it and, by default, restlet seemed to
pick the wrong one.  When I
deleted the wrong wildcard from the keystore, everything worked fine.

I'll confess that the interaction between keystores, SSL, and Restlet
is something I
just don't quite understand.

Now, looking at issue #489, I see that there are some changes coming that
should help me.  Can some detail how I'll be able to use this new SSL
context factory
to handle associating certifcates (or aliases in a keystore) with a
virtual host?

--Alex Milowski

Delivering static files from Restlet-Servlet

[Christian Möller]

Hi,

I've read several comments on this mailing list (like this one: http://
thread.gmane.org/gmane.comp.java.restlet/4423) regarding delivering static 
files via Restlet, but I simply did not get it right. Is there anybody out 
there be so kind telling me what is wrong with my setup?

I'm using Restlet 1.0.10 with Tomcat 5.5.
web.xml looks like this:

=
...

  org.restlet.application
  de.denic.zone.nast.application.rest.NastApplication


  org.restlet.component
  de.denic.zone.nast.application.rest.MetaFileDeliveringComponent

...
=

The configured application works nicely providing all resources as desired.
My component looks like this:

=
public final class MetaFileDeliveringComponent extends Component {

  private static final class MyApplication extends Application {

private MyApplication(final Context context) {
  super(context);
}

@Override
public Restlet createRoot() {
  final Directory directory = new Directory(getContext(), "file:///d:/
Temp/");
  directory.setDeeplyAccessible(true);
  directory.setListingAllowed(true);
  return directory;
}
  }

  public MetaFileDeliveringComponent() {
super();
getClients().add(Protocol.FILE);
getDefaultHost().attach("/meta", new MyApplication(getContext()));
  }
=

But accessing the /{root-of-webapp}/meta path via GET requests gets code 404 
all the time.

Thanks in advance

Christian

Re: More on port 80 - VirtualHost.resourcePort property

[Mark Cornelius]

Ok, the weird thing is, I don¹t get a stack trace at all. I simply get a
blank screen whenever I run the application with the weblogic port set to
80. It works fine when the port is set to any other value.

What I ended up doing to fix this was overriding your getHostPort() method
in your HttpServerCall class with the following:

Public int getHostPort(){
if (getRequestHeaders().getFirstValue()(HttpConstants.HEADER_HOST,
true).indexOf(³:²)==-1)
return 80;
if(!hostParsed){
parseHost();
return super.getHostPort();
}

And then overriding the constructor in HTTPRequest to always append the port
number to the stringbuffer. (removing the IF logic surrounding it)

When I did that, it worked whether I used a port number or not.

The thing I don¹t get though, is why does the port number even matter, if
this code is not executed until the servlet container has received the
request anyway. (In which case the url would have to have specified the
correct port number). Why do you need to worry about them at all?


In my situation, in our environment there is a front end apache which routes
requests to our servlet container, so the incoming url won¹t be the actual
url of the servlet container itself, and incoming url will always be on port
80. Thus, I need this to work.

I know there has to be something I¹ve overlooked.

From: Jerome Louvel <[EMAIL PROTECTED]>
Reply-To: 
Date: Tue, 1 Jul 2008 13:27:01 +0200
To: 
Subject: RE: More on port 80 - VirtualHost.resourcePort property

 
Mark,
 
We need more details to help you out like stack traces and design details. I
noticed you use ServerServletConverter but what do you have behind, a
component, an application?


Best regards,
Jerome


De : Mark Cornelius [mailto:[EMAIL PROTECTED]
Envoyé : lundi 30 juin 2008 18:37
À : discuss@restlet.tigris.org
Objet : More on port 80 - VirtualHost.resourcePort property

I read in an earlier thread someone having trouble with port 80 needed to
set this property, but when/where do you do it?


-- 

Mark E. Cornelius

Re: Redirector.MODE_DISPATCHER example

[Thierry Boileau]

Hello Marc-Elian,

Do you have declared the required client connectors 
(http://www.restlet.org/documentation/1.1/api/org/restlet/Redirector.html#MODE_DISPATCHER)?
In such mode, the redirector becomes a client, gets the response ant 
sends it back to its own client.


In the following sample code,  requests are redirected to 
http://www.restlet.org, which means that the component needs to add the 
HTTP protocol to its list of supported client protocols.


   Component component = new Component();
   component.getServers().add(Protocol.HTTP, 8182);
   component.getClients().add(Protocol.HTTP); // mandatory

   component.getDefaultHost().attachDefault(
   new Redirector(component.getContext(),
   "http://www.restlet.org";, 
Redirector.MODE_DISPATCHER));


Best regards,
Thierry Boileau


Hi,

While having a lot of fun using Restlet, I'm looking for a Redirector example
using Redirector.MODE_DISPATCHER.  It works well for client redirect, but I
can't get the mode dispatcher to work.

Thanks,

Meb



  

RE: More on port 80 - VirtualHost.resourcePort property

[Jerome Louvel]

 
Mark,
 
We need more details to help you out like stack traces and design details. I
noticed you use ServerServletConverter but what do you have behind, a
component, an application?


Best regards,
Jerome

  _  

De : Mark Cornelius [mailto:[EMAIL PROTECTED] 
Envoyé : lundi 30 juin 2008 18:37
À : discuss@restlet.tigris.org
Objet : More on port 80 - VirtualHost.resourcePort property


I read in an earlier thread someone having trouble with port 80 needed to
set this property, but when/where do you do it? 


-- 

Mark E. Cornelius

RE: Problem with port number using restlet engine

[Jerome Louvel]

Hi Mark,
 
This looks like a bug. Do you have a stack trace with the
NumberFormatException?
 
Otherwise, feel free to open a bug report:
 
http://www.restlet.org/community/issues
 
Best regards,
Jerome
 

  _  

De : Mark Cornelius [mailto:[EMAIL PROTECTED] 
Envoyé : jeudi 26 juin 2008 21:20
À : discuss@restlet.tigris.org
Objet : Problem with port number using restlet engine


We have implemented the noelios restlet engine, but are having a strange
problem. In our test environment, we forward requests to BEA WebLogic using
an apache front end. The port numbers of the weblogic servers change weekly.

However the front end (Apache) listens on port 80, so no port number is
required. This causes us to get NumberFormatExceptions when the
ServerConverter object is invoked, unless we use a firefox plugin to append
a dummy port number on the request. We get a 404 error on every request that
doesn’t have a port number attached, and it can be any port number but 80.
This I find to be bizarre.

Why does this not work  unless the URL contains a port number?
___
Mark Cornelius, MBA
Candidate for MS in Software Engineering
[EMAIL PROTECTED]

Sent from a Mac, join the revolution
 http://www.apple.com

Redirector.MODE_DISPATCHER example

[Marc-Elian Bégin]

Hi,

While having a lot of fun using Restlet, I'm looking for a Redirector example
using Redirector.MODE_DISPATCHER.  It works well for client redirect, but I
can't get the mode dispatcher to work.

Thanks,

Meb