Re: Command line to STOP Restlet server

[Leshek Fiedorowicz]

All good, helpful hints, but... by Restlet designed (the best practice?) way 
to stop Restlet internal HTTP server?

Leshek
Ps. I have re-registered with tigris, thank you Jerome!

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1023582

RE: Looking for a way to access Date header

[Carlos Alexandre Moscoso]

Hi Jerome,

Thanks for the feedback, Restlet 1.2 looks pretty interesting, there is a date 
set for this release?

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1023335

RE: improving Protocol.valueOf()

[Carlos Alexandre Moscoso]

You're right!

thanks for the tip!

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1023309

Re: Re: Re: Tomcat appears to swallow Allow: header

[Rob Heittman]

Much weeping and gnashing of teeth later ... I took out the entity
hacks from GoGoEgo, ran on Restlet 1.1, observed the Tomcat problems
under GWT hosted mode, ported to Restlet 1.2 snapshot, took out the
entity hacks, and am not seeing the adverse behavior.  Barring a more
scientific analysis ... I think this fix really solves the problem!
Sweet!

Unrelated - did you know that when you download snapshot ("development
version - unstable") from www.restlet.org/downloads you get redirected
to the 1.1 snapshot?  This is a bit confusing  :-)  I had to guess the
URL for the 1.2 snapshot.

On Tue, Jan 13, 2009 at 5:31 PM, Jerome Louvel
 wrote:
> The latest snapshot (Restlet 1.2) already contains the fix:
> http://www.restlet.org/documentation/snapshot/changes

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1023299

Where is status header in Response.getAttributes?

[Carlos Alexandre Moscoso]

It seems that the status header associated with a Response does not appear in 
the list (Form) of attributes obtained by calling getAttributes.

I would like to know if this is the expected behavior for you.

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1023042

RE: Solr integration

[Jerome Louvel]

Hi Rémi,
 
Great! I've updated the team page (http://www.restlet.org/about/team) and 
granted you the commit rights (only for the Lucene extension module and 
directly related libraries).
 
See you in the c...@restlet.tigris.org mailing list for further design 
discussions :)
 
Usage of Lucene in the context of the semantic web sounds like a great idea!
 
Best regards,
Jérôme Louvel
--
Restlet ~ Founder and Lead developer ~   
http://www.restlet.org
Noelios Technologies ~ Co-founder ~   
http://www.noelios.com

  _  

De : remidewi...@gmail.com [mailto:remidewi...@gmail.com] De la part de Rémi 
Dewitte
Envoyé : lundi 12 janvier 2009 16:38
À : discuss@restlet.tigris.org
Objet : Re: Solr integration


Jérôme,

Why not to lead the Lucene extension ! I'll do my best.

I think that Lucene integration will be really handy with Semantic Web for 
example to index relations.

Cheers,
Rémi


On Sun, Jan 11, 2009 at 20:37, Jerome Louvel  wrote:


Rémi,
 
Sounds good! 
 
Also, if you are interested (and have enough available time) to lead the whole 
Lucene extension, I would be happy to have you as the extension committer, with 
commit rights, etc. 
 
See details about development process here:
http://wiki.restlet.org/developers/179-restlet/51-restlet.html?branch=docs-1_1 

 &language=en
 


Best regards,
Jérôme Louvel
--
Restlet ~ Founder and Lead developer ~   
http://www.restlet.org
Noelios Technologies ~ Co-founder ~   
http://www.noelios.com

  _  


De : remidewi...@gmail.com [mailto:remidewi...@gmail.com] De la part de Rémi 
Dewitte

Envoyé : dimanche 11 janvier 2009 19:17 

À : discuss@restlet.tigris.org
Objet : Re: Solr integration


Jérôme,

I'll try to contribute some documentation as soon as possible and possibly look 
at the Tika stuff too.

Have a nice week !

Rémi


On Sun, Jan 11, 2009 at 17:41, Jerome Louvel  wrote:


Hi Rémi,
 
Sorry for the slow reply! 
 
1) Solr support
 
First, let me thank you for contributing this class.
 
I went ahead and created the "org.restlet.ext.lucene" module in SVN trunk with 
the necessary/minimal library dependencies (for Lucene, Tika, Solr). The build 
has been updated to include this extension in the Restlet 1.2 distribution.
 
You will also note that I've moved the internal classes in SolrClientHelper up 
one level to facilitate reuse. I've also completed the Javadocs.
 
So, we are almost there. What is now missing is some proper user documentation. 
I've created a new developer page on the wiki where you and others can provide 
this info:
 
"Lucene extension"
http://wiki.restlet.org/developers/172-restlet/215-restlet.html
 
Once we get the User Guide ready for Restlet 1.2, we'll migrate the user 
related content there.
 
2) Tika support
 
In addition to the Solr client connector, I have also added a 
TikaRepresentation to facilitate the extraction of metadata from any 
representation supported by Tika parsers. Hope this helps!
 


Best regards,
Jérôme Louvel
--
Restlet ~ Founder and Lead developer ~   
http://www.restlet.org
Noelios Technologies ~ Co-founder ~   
http://www.noelios.com
 


  _  

De : remidewi...@gmail.com [mailto:remidewi...@gmail.com] De la part de Rémi 
Dewitte
Envoyé : mardi 30 décembre 2008 13:16 

À : discuss@restlet.tigris.org
Objet : Re: Solr integration


Hi !

Basically it allows you to interact with solr with solr:// references the same 
way you would do it through http : 
http://wiki.apache.org/solr/SolrRequestHandler

It can be seen as a way to deploy solr as a Restlet application instead of in a 
servlet container.

I have uploaded the SolrClientHelper.java on 
http://restlet.tigris.org/issues/show_bug.cgi?id=697.

About creating an extension, I still struggle a bit on how define dependencies 
to 3rd party jars.
Is there a tool to create all the boilerplate in librairies/ directory from 
this maven dependency ?

org.apache.solr
solr-core
1.3.0
 

Regards,
Rémi


On Sun, Dec 28, 2008 at 13:17, Jerome Louvel  wrote:


Hi all,
 
Providing Lucene-based search/indexing features sounds like a generic and very 
useful feature. 
 
If the best way to facilitate this integration in Restlet is to leverage Solr, 
then we should definitely consider a new Restlet extension. I've created a RFE 
to track this idea:
 
"Add support for Lucene/Solr"
http://restlet.tigris.org/issues/show_bug.cgi?id=697
 
Rémi, could you describe how your client connector works? Which use cases does 
it handle?
 


Best regards,
Jérôme Louvel
--
Restlet ~ Founder and Lead developer ~   
http://www.restlet.org
Noelios Technologies ~ Co-founder ~   
http://www.noelios.com

  _  

De : Ben Johnson [mailto:ben.john...@jand

Re: SpringBeanRouter issues

[Rhett Sutphin]

> However, I'm not sure however about injecting the SpringBeanFinder  
> because we need one instance per target resource bean...

This could be achieved by injecting the bean name (instead of an  
instance) and then using the application context to retrieve instances  
as needed.

That said, I much prefer the current style -- it allows you to change  
the finder type by subclassing SpringBeanRouter and overriding  
createFinder -- especially since you're going to have to modify the  
prototype finders anyway (to give them the resource bean name).

Rhett

On Jan 13, 2009, at 4:00 PM, Jerome Louvel wrote:

> Hi Daniel,
>
> Thanks for sharing your experience and for the enhancement suggestion.
>
> I've just made the SpringBeanRouter implement  
> ApplicationContextAware, using the context received to instantiate  
> the finders. Changes are checked in SVN trunk.
>
> However, I'm not sure however about injecting the SpringBeanFinder  
> because we need one instance per target resource bean...
>
> Could you test the next snapshot and let me know if it work fine?
>
> Best regards,
> Jérôme Louvel
> --
> Restlet ~ Founder and Lead developer ~ http://www.restlet.org
> Noelios Technologies ~ Co-founder ~ http://www.noelios.com
>
>
> -Message d'origine-
> De : Daniel Woo [mailto:daniely...@hotmail.com]
> Envoyé : vendredi 9 janvier 2009 17:26
> À : discuss@restlet.tigris.org
> Objet : *SPAM(1.8)* RE: Re: SpringBeanRouter issues
>
> one more thing, if you want to intercept  
> MyResource.represent(Variant), that won't work with Spring AOP (jdk  
> proxy or cglib). Because this method is called by Resource.handleGet()
>
> You have to intercept Resource.handleGet()/Put()/Post()/Delete(), or  
> use static waver like aspectJ.
>
>> I think you can make SpringBeanRouter implement  
>> ApplicationContextAware. I made it this way, the AOP interceptor  
>> successfully executed.
>>
>> I changed very little to your SpringBeanRouter and SpringBeanFinder:
>>
>> SpringBeanRouter: make it ApplicationContextAware, and holds an  
>> ApplicationContext. Each time createFinder() will pass that app  
>> context to SpringBeanFinder.
>>
>> SpringBeanFinder：now the constructor accepts an application  
>> context instead of a beanFactory. Moreover, you actually can also  
>> make the beanFinder ApplicationContextAware, in that way, you don't  
>> have to hard code "new  SpringBeanFinder(appContext, beanName)"  
>> anymore, you can even inject SpringBeanFinder to SpringBeanRouter,  
>> hence the SpringBeanFinder can be replaced by subclass written by  
>> the end user.
>>
>> What do you think? It's at least useful to me because this solves  
>> my transaction and security issue with Spring.
>
> --
> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1014009
>
> --
> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1022914

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1023023

RE: routes with URIs

[Jerome Louvel]

Hi Benjamin,

Restlet shouldn't do any automatic/magic decoding of your reference. So, if you 
can produce your URI with an encoded var, you should
be able to match it with a variable on the server-side.

If you generate those URIs dynamically on the client-side, you can probably 
used some Javascript to properly encode the embedded
URI. 

Best regards,
Jerome Louvel
--
Restlet ~ Founder and Lead developer ~ http://www.restlet.org
Noelios Technologies ~ Co-founder ~ http://www.noelios.com
 

-Message d'origine-
De : Benjamin Dai [mailto:benjamin@stanford.edu] 
Envoye : vendredi 9 janvier 2009 20:34
A : discuss@restlet.tigris.org
Objet : RE: routes with URIs

Hi Clif,

Yes, this is the exact same issue we are encountering with our RESTlet
efforts.  The fundamental requirement is that we need the ability to specify
an encoded RESTlet variable.  In our case, the variable can be a URI.  Or,
it could include include other kinds of characters that require encoding. 
Here are some sample REST URLs patterns that would require encoded variable
support:

/abc/{number}/{encodedvar}
/abc/{number}/{encodedvar}/foo

Any obvious workarounds?  Of course, if Firefox and IE can't handle encoded
URIs, a server-side RESTlet solution may be moot.

Thanks.

Benjamin Dai


Cliff Binstock wrote:
> 
> Intriguing.  Never even occurred to me that something as simplistic as NOT
> encoding might work.
> 
> This is great, but doesn't mesh nicely with the rest of REST, since of
> course what I really want is:
> 
> /urls/{url}/foo/bar
> 
> And there would be no way to know where the end of the embedded URL was,
> and
> the beginning of the rest of the route (/foo/bar) was:
> 
> http://localhost:9876/toto?url=http://www.example.com/foo.xml/foo/bar?a=1&b=
> 2
> 
> 
> Cliff
> 
> 
> 
>> -Original Message-
>> From: Jerome Louvel [mailto:jerome.lou...@noelios.com]
>> Sent: Monday, November 10, 2008 2:25 AM
>> To: discuss@restlet.tigris.org
>> Subject: RE: routes with URIs
>> 
>> 
>> Hi Cliff,
>> 
>> I have just done a simple test, typing this URI in Firefox 3:
>> http://localhost:9876/toto?url=http://www.example.com/foo.xml?a=1&b=2
>> 
>> On the server, I just return as an entity the URI entered, which
>> displayed
>> exactly the same value in the browser.
>> 
>> Then, I tried this:
>> http://localhost:9876/toto/url/http://www.example.com/foo.xml?a=1&b=2
>> 
>> And it displayed the same value again, both in FF3 and IE7. See attached
>> server code.
>> 
>> I guess you are encountering encoding issue at other levels. Maybe in
>> your
>> HTML page that is initially sent to your browser.
>> 
>> Best regards,
>> Jerome Louvel
>> --
>> Restlet ~ Founder and Lead developer ~ http://www.restlet.org
>> Noelios Technologies ~ Co-founder ~ http://www.noelios.com
>> 
>> 
>> -Message d'origine-
>> De : Cliff Binstock [mailto:cliff.binst...@coyotereporting.com]
>> Envoye : vendredi 31 octobre 2008 21:30
>> A : discuss@restlet.tigris.org
>> Objet : routes with URIs
>> 
>> To all,
>> 
>> Wondering if anyone has any experience or great ideas:
>> 
>> I have a need to specify URLs (not the uri-pattern) when fetching
>> Resources.
>> 
>> A simple degenerate case is this:
>> 
>> /urls/{url}
>> 
>> Where {url} points to some random place on the web.  While I have thought
>> of
>> a number of workarounds, I can't come up with an elegant solution.  As a
>> point of reference, a URL encoded URL doesn't seem to work with most
>> browsers.  You might, for example, think that this:
>>  http://www.example.com/foo.xml
>> Might turn into this:
>>  http%3A%2F%2Fwww.example.com%2Ffoo.xml
>> or more precisely, for the aforementioned route:
>>  /urls/http%3A%2F%2Fwww.example.com%2Ffoo.xml
>> 
>> But again, most browsers (at least IE and Firefox) aren't happy about
>> this.
>> 
>> So far I've thought of solutions like:
>>* POST
>>* Require something besides "/" delimiter
>>* Pre-cache using something else (with POST), like /specify-url ...
>>* Use some sort of (non-standard) encoding
>> 
>> Has anyone had to do anything similar?  Or any ideas on a user-friendly
>> solution?
>> 
>> 
>> Thanks in advance,
>> 
>> Cliff
> 
> 
> 

-- 
View this message in context: 
http://n2.nabble.com/routes-with-URIs-tp1438398p2134871.html
Sent from the Restlet Discuss mailing list archive at Nabble.com.

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1014251

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1023016

RE: Re: Re: Tomcat appears to swallow Allow: header

[Jerome Louvel]

Hi all,
 
I haven't ported the fix to Restlet 1.1 yet. I would like to get more feed-back 
on SVN trunk first due to potential impact if this
approach has flaws.
 
The latest snapshot (Restlet 1.2) already contains the fix:
http://www.restlet.org/documentation/snapshot/changes
 
It can be downloaded from this page:
http://www.restlet.org/downloads/
 
Best regards,
Jerome Louvel
--
Restlet ~ Founder and Lead developer ~   
http://www.restlet.org
Noelios Technologies ~ Co-founder ~   
http://www.noelios.com

  _  

De : Rob Heittman [mailto:rob.heitt...@solertium.com] 
Envoye : mardi 13 janvier 2009 23:17
A : discuss@restlet.tigris.org
Objet : Re: Re: Re: Tomcat appears to swallow Allow: header


Jerome committed a candidate fix to trunk today and mentioned it in the 
previously referenced thread.  I can't test it until
tomorrow, but if you can build trunk or use tomorrow's snapshot, you may be 
able to verify the fix before I can.

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1022985

RE: Command line to STOP Restlet server

[Jerome Louvel]

Hi Leshek,

Due to a Tigris.org update, the discussion lists behavior changed. I looked at 
the subscribers list and couldn't find your
name/email. 

I suggest that you check your subscriptions on this page:
http://restlet.tigris.org/ds/manageSubscriptions.do

Note that you can subscribe in "My start page only" mode to be able to send 
mails to the list without receiving them (if you read
them via another channel).

Best regards,
Jerome Louvel
--
Restlet ~ Founder and Lead developer ~ http://www.restlet.org
Noelios Technologies ~ Co-founder ~ http://www.noelios.com


-Message d'origine-
De : news [mailto:n...@ger.gmane.org] De la part de Leshek
Envoye : mardi 13 janvier 2009 00:48
A : discuss@restlet.tigris.org
Objet : Command line to STOP Restlet server

I want to have stop and exit restlet server command line interface.
The start is simple (java -jar myRest.jar).

I know from within I can do getContext().getApplication().stop()
I could to it in response to http request .../STOP, but... I want to keep 
control on the server only.

So I am looking for something like starting a new Java application

java -jar myRest.jar STOP

to tell the other application to STOP cleanly.

Leshek
Ps. Posting it over web interface, regular reader post did not go through...

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1020497

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1022980

Re: Re: Re: Tomcat appears to swallow Allow: header

[Rob Heittman]

Jerome committed a candidate fix to trunk today and mentioned it in the
previously referenced thread.  I can't test it until tomorrow, but if you
can build trunk or use tomorrow's snapshot, you may be able to verify the
fix before I can.

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1022966

RE: Re: Re: Tomcat appears to swallow Allow: header

[postmaster]

Well, I compared HttpServerConverter#commit code in restlet 1.0.10 and restlet 
1.1.1, and the 1.0.10 version did not check for content length or response code 
before adding the headers. Surely this needs to be fixed in restlet 1.1.1.

HttpServerConverter#commit code in restlet 1.0.10  was as follows:

public void commit(HttpResponse response) {
try {
// Add the response headers
addResponseHeaders(response);

// Send the response to the client
response.getHttpCall().sendResponse(response);
} catch (Exception e) {
getLogger().log(Level.INFO, "Exception intercepted", e);

response.getHttpCall().setStatusCode(Status.SERVER_ERROR_INTERNAL.getCode());
response.getHttpCall().setReasonPhrase(
"An unexpected exception occured");
}
}

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1022684

RE: Servlet Filter using request.getParameter loses Form data

[Jerome Louvel]

Hi there,

Looking at the Servlet API, the behavior that you describe seems normal:
http://java.sun.com/javaee/5/docs/api/javax/servlet/ServletRequest.html#getParameter(java.lang.String)

If you call this method in your Servlet filter, it will consume the request 
input stream and the Restlet won't have a way to read it
again. Can't you implement the same filter as a Restlet filter instead?

Note that if you need the query parameters, then you can still call 
getResourceRef().getQueryAsForm();

Best regards,
Jerome Louvel
--
Restlet ~ Founder and Lead developer ~ http://www.restlet.org
Noelios Technologies ~ Co-founder ~ http://www.noelios.com


-Message d'origine-
De : postmas...@tigris.org [mailto:postmas...@tigris.org] 
Envoye : samedi 10 janvier 2009 22:58
A : discuss@restlet.tigris.org
Objet : Servlet Filter using request.getParameter loses Form data

We added servlet filter to our application which calls 
request.getParameter("name"). That breaks Restlet Form handling.
request.getEntityAsForm() will return empty form.

It seems that getParameter interferes with getInputStream in the case form data 
is sent using POST. To me this sounds to be a bug in
Restlet framework. We are using Restlet 1.1.1.

This simple filter will break getEntityAsForm:

public void doFilter(ServletRequest request, ServletResponse response, 
FilterChain chain) throws IOException, ServletException {
  request.getParameter("name");
  chain.doFilter(request, response);
}

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1015889

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1022941

RE: improving Protocol.valueOf()

[Jerome Louvel]

Hi Carlos,

I don't consider "http://www.restlet.org/"; to be a protocol name, so I would 
expect false.

In order to achieve what you want, I would use this code:

Reference ref = new Reference("http://www.restlet.org/";);
Protocol.HTTP.equals(ref.getSchemeProtocol());

Best regards,
Jerome Louvel
--
Restlet ~ Founder and Lead developer ~ http://www.restlet.org
Noelios Technologies ~ Co-founder ~ http://www.noelios.com


-Message d'origine-
De : Carlos Alexandre Moscoso [mailto:moscoso@gmail.com] 
Envoye : dimanche 11 janvier 2009 10:24
A : discuss@restlet.tigris.org
Objet : improving Protocol.valueOf()

Hi,

I think the behavior of Protocol.valueOf() could be improved. What do you think 
of
Protocol.valueOf("http://www.restlet.org/";).equals(Protocol.HTTP) resulting in 
true?

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1016889

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1022928

Re: SpringBeanRouter issues

[Jerome Louvel]

Hi Daniel,

Thanks for sharing your experience and for the enhancement suggestion. 

I've just made the SpringBeanRouter implement ApplicationContextAware, using 
the context received to instantiate the finders. Changes are checked in SVN 
trunk.

However, I'm not sure however about injecting the SpringBeanFinder because we 
need one instance per target resource bean...

Could you test the next snapshot and let me know if it work fine?

Best regards,
Jérôme Louvel
--
Restlet ~ Founder and Lead developer ~ http://www.restlet.org
Noelios Technologies ~ Co-founder ~ http://www.noelios.com
 

-Message d'origine-
De : Daniel Woo [mailto:daniely...@hotmail.com] 
Envoyé : vendredi 9 janvier 2009 17:26
À : discuss@restlet.tigris.org
Objet : *SPAM(1.8)* RE: Re: SpringBeanRouter issues

one more thing, if you want to intercept MyResource.represent(Variant), that 
won't work with Spring AOP (jdk proxy or cglib). Because this method is called 
by Resource.handleGet()

You have to intercept Resource.handleGet()/Put()/Post()/Delete(), or use static 
waver like aspectJ.

> I think you can make SpringBeanRouter implement ApplicationContextAware. I 
> made it this way, the AOP interceptor successfully executed.
> 
> I changed very little to your SpringBeanRouter and SpringBeanFinder:
> 
> SpringBeanRouter: make it ApplicationContextAware, and holds an 
> ApplicationContext. Each time createFinder() will pass that app context to 
> SpringBeanFinder.
> 
> SpringBeanFinder：now the constructor accepts an application context instead 
> of a beanFactory. Moreover, you actually can also make the beanFinder 
> ApplicationContextAware, in that way, you don't have to hard code "new  
> SpringBeanFinder(appContext, beanName)" anymore, you can even inject 
> SpringBeanFinder to SpringBeanRouter, hence the SpringBeanFinder can be 
> replaced by subclass written by the end user.
> 
> What do you think? It's at least useful to me because this solves my 
> transaction and security issue with Spring.

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1014009

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1022914

RE: Re: Re: Restlet 1.1-RC1 in OSGi

[Jerome Louvel]

Hi guys,

Note that in Restlet 1.2, the Restlet API and core engine are merged in the 
same bundle.

This should simplify OSGi integration by not having to specify bundle loading 
order.

Best regards,
Jerome Louvel
--
Restlet ~ Founder and Lead developer ~ http://www.restlet.org
Noelios Technologies ~ Co-founder ~ http://www.noelios.com
 

-Message d'origine-
De : >Eneko Taberna [mailto:eneko.tabe...@gmail.com] 
Envoye : lundi 12 janvier 2009 14:24
A : discuss@restlet.tigris.org
Objet : RE: Re: Re: Restlet 1.1-RC1 in OSGi

That worked! Thanks Michael, I really apreciate your help. 
regards,

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1019049

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1022348

RE: Looking for a way to access Date header

[Jerome Louvel]

Hi Carlos,

We currently only set the Date header on outgoing responses. There is indeed a 
need to access this date from the Restlet API!

I've added a comment about it in this RFE:

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

This will be added to 1.2 M2.

Best regards,
Jerome Louvel
--
Restlet ~ Founder and Lead developer ~ http://www.restlet.org
Noelios Technologies ~ Co-founder ~ http://www.noelios.com


-Message d'origine-
De : Carlos Alexandre Moscoso [mailto:moscoso@gmail.com] 
Envoye : jeudi 8 janvier 2009 15:20
A : discuss@restlet.tigris.org
Objet : Looking for a way to access Date header

Hi,

The link below is not clear whether this header is currently supported by the 
Restlet API:

http://wiki.restlet.org/docs_1.1/13-restlet/27-restlet/130-restlet.html

I tried to look in response.getDate but without success, so how are you guys 
doing to get the date associated with the server
response?

Thanks,

CA

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1011777

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1022276

RE: media type adaptor

[Cliff Binstock]

Taylor,

 

I have implemented a solution like this and I highly recommend it.  I
actually have taken it one step further and bound the routes (and the
implementation) dynamically:  there is very little Java code, mostly just
XML-based configuration.  In the cases where configuration does not make
sense, then I have subclasses that provide an implementation as your message
implies.

 

I can tell you that you will want to pass in the request to the callback:
you don't always need it, but sometimes you need some contextual information
(see previous post about wanting the original route URI, for example).

 

Cliff Binstock
Coyote Reporting

  _  

From: Taylor Cowan [mailto:taylor_co...@yahoo.com] 
Sent: Tuesday, January 13, 2009 7:12 AM
To: discuss@restlet.tigris.org
Subject: media type adaptor

 

I'm new to restlets and would like some feedback from the community on some
experimentation.  Instead of if/else'ing through the list of variant types
and calling the appropriate logic, I'd like reslets to do that for me.

The example "MediaType" below is similar to the restlet version, except that
each enumeration overrides a call back, for example, the text/html type
calls back to handleTextHTML().


TEXT_HTML("text/html", "HTML document") {
@Override
public Representation callBack(VariantHandler arg0) {
return arg0.handleTextHTML();
}
},

The application developer then extends a resource from BaseResource, and
implements the methods they'd like to handle.  (like the AWT MouseEvent
adaptors of old) The examples are not complete, I only implmented 4 media
types.  The BaseResource gets the media type, converts to the appropriate
extended MediaType, and the invokes the callback.

@Override
public Representation represent(Variant variant) throws
ResourceException {
String mediaType = variant.getMediaType().getName();
return MediaType.value(mediaType).callBack(this);
}


So to handle HTML, the developer just does this:

@Override
public Representation handleTextHTML() {
   // here's where we respond to HTML clients.
}



http://restlets.s3.amazonaws.com/VariantHandler.java
http://restlets.s3.amazonaws.com/BaseResource.java
http://restlets.s3.amazonaws.com/MediaType.java

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1022252

RE: StatusService not invoked

[Jerome Louvel]

Hi Ganesh,

The StatusService#getStatus() method is only called when an exception is raised 
by your code and caught by the engine. Here this
related code from the engine's StatusFilter:

@Override
public int doHandle(Request request, Response response) {
// Normally handle the call
try {
super.doHandle(request, response);
} catch (Throwable t) {
response.setStatus(getStatus(t, request, response));
}

return CONTINUE;
}

In your case, I'd better override the StatusService#getRepresentation() method 
which is always invoked when your Response has an
error status.

Best regards,
Jerome Louvel
--
Restlet ~ Founder and Lead developer ~ http://www.restlet.org
Noelios Technologies ~ Co-founder ~ http://www.noelios.com



-Message d'origine-
De : Ganesh [mailto:narayanas...@gmail.com] 
Envoye : mercredi 7 janvier 2009 16:24
A : discuss@restlet.tigris.org
Objet : StatusService not invoked

Hi,

   i am trying to add a custom StatusService to my application, that should 
go to given error page when the resource not
found.for the known resources it is going fine..if it is an unknown resource 
the getStatus is not called!! can any one look at my
code and suggest where i am missing? or any code to help is more appreciated :)

Application 
--
public MYApplication(final Context context) {
super(context);
setStatusService(new ErrorStatusService());
}

ErrorStatusService
--
public class ErrorStatusService extends StatusService {
public ErrorStatusService() {
super(true);
}
@Override
public Status getStatus(final Throwable throwable, final Request 
request, final Response response) {
response.redirectTemporary("/error.html");
return response.getStatus();
}
please help me.

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1010040

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1022249

RE: Retrieving the UriTemplate associated to a Resource class

[Cliff Binstock]

Fabio,

 

I had asked this question as well.  The answer is to do this:

 

final Router router = new Router(getContext()) {

@Override

public Restlet getNext(final Request request,

   final Response response) {

final Restlet result = super.getNext(request, response);

if (result instanceof Route) {

final Route route = (Route) result;

final String uriPattern =
route.getTemplate().getPattern();

s_logger.log(Level.INFO,"User requested route:  " +
uriPattern);

 
request.getAttributes().put(TEMPLATE_URI_PATTERN_ATTRIBUTE, uriPattern);

}

return result;

}

};

 

 

You can then get the value with request.getAttribute

 

Cliff Binstock

Coyote Reporting

 

 

 

> -Original Message-

> From: Fabio Mancinelli [mailto:fabio.mancine...@gmail.com]

> Sent: Wednesday, January 07, 2009 8:07 AM

> To: discuss@restlet.tigris.org

> Subject: Retrieving the UriTemplate associated to a Resource class

> 

> Dear all,

> 

> I have already implemented this by building additional infrastructure, but

> I was wondering if, from inside a Resource, there is a way for retrieving

> which UriTemplate is associated to a given Resource class.

> 

> To be more explicit:

> 

> In application:

> router.attach("/myResource", MyResource.class)

> 

> In MyResource I would like to have something like:

> getUriTemplateFor(MyResource.class) -> "/myResource"

> 

> I digged a bit into the API but I haven't find anything like this.

> 

> Thanks,

> Fabio

> 

> --

> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=101

> 0096

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1022243

Re: Redirect broken on Tomcat 5.0.x

[Rob Heittman]

Not at the right workstation today, but I can give it a whirl tomorrow!
Thanks Jerome!

On Tue, Jan 13, 2009 at 11:13 AM, Jerome Louvel
wrote:

> Hi Eirik,
>
> Thanks for reporting this issue. I've checked in a fix for this in SVN
> trunk that sets the headers after the status and that ignores
> the "Content-Length" header when sending an error response.
>
> Could you test it (from SVN trunk or from next snapshot) and let us know if
> it works? Rob, maybe you want to give it a try with GWT?
>
> Best regards,
> Jérôme Louvel
> --
> Restlet ~ Founder and Lead developer ~ http://www.restlet.org
> Noelios Technologies ~ Co-founder ~ http://www.noelios.com
>

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1022236

RE: Exception-resistant filters

[Jerome Louvel]

Hi Fabio,

You can do this by overriding the doHandle() method in your filter. Here is an 
excerpt from StatusFilter:

@Override
public int doHandle(Request request, Response response) {
// Normally handle the call
try {
super.doHandle(request, response);
} catch (Throwable t) {
response.setStatus(getStatus(t, request, response));
}

return CONTINUE;
}

Best regards,
Jerome Louvel
--
Restlet ~ Founder and Lead developer ~ http://www.restlet.org
Noelios Technologies ~ Co-founder ~ http://www.noelios.com
 

-Message d'origine-
De : Fabio Mancinelli [mailto:fabio.mancine...@gmail.com] 
Envoye : mardi 6 janvier 2009 19:27
A : discuss@restlet.tigris.org
Objet : 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=4447&dsMessageId=1008161

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1022219

RE: Redirect broken on Tomcat 5.0.x

[Jerome Louvel]

Hi Eirik,

Thanks for reporting this issue. I've checked in a fix for this in SVN trunk 
that sets the headers after the status and that ignores
the "Content-Length" header when sending an error response.

Could you test it (from SVN trunk or from next snapshot) and let us know if it 
works? Rob, maybe you want to give it a try with GWT?

Best regards,
Jérôme Louvel
--
Restlet ~ Founder and Lead developer ~ http://www.restlet.org
Noelios Technologies ~ Co-founder ~ http://www.noelios.com


-Message d'origine-
De : Eirik Bjørsnøs [mailto:eir...@gmail.com] 
Envoyé : mardi 6 janvier 2009 14:21
À : discuss@restlet.tigris.org
Objet : 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  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  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.
>
>

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1022201

RE: executing a HTML page directly.

[Jerome Louvel]

Hi Ganesh,

In theory it should work. Did you try with other CLAP authorities such as 
"system" instead of "class"?

Otherwise, could you send us a small reproducible sample application that we 
could attempt to debug? 

Best regards,
Jerome Louvel
--
Restlet ~ Founder and Lead developer ~ http://www.restlet.org
Noelios Technologies ~ Co-founder ~ http://www.noelios.com


-Message d'origine-
De : Ganesh [mailto:narayanas...@gmail.com] 
Envoye : mardi 6 janvier 2009 10:55
A : discuss@restlet.tigris.org
Objet : executing a HTML page 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 in a restlet, 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?
-- 
View this message in context: 
http://n2.nabble.com/executing-a-HTML-page-directly.-tp2116849p2116849.html
Sent from the Restlet Discuss mailing list archive at Nabble.com.

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1007232

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1022150

RE: restlet 1.1.1, Spring and issue with loosing a connection

[Jerome Louvel]

Hi Eugene, 

We are currently working with Niall Gallagher, the author of Simple to upgrade 
this connector to Simple 4.0.7 in Restlet 1.2. This
might solve your issue in the end. 

If you can't wait for Restlet 1.2, it could be solved if you contact the Simple 
mailing list directly:
https://lists.sourceforge.net/lists/listinfo/simpleweb-support

Best regards,
Jerome Louvel
--
Restlet ~ Founder and Lead developer ~ http://www.restlet.org
Noelios Technologies ~ Co-founder ~ http://www.noelios.com


-Message d'origine-
De : Eugeny N Dzhurinsky [mailto:b...@redwerk.com] 
Envoye : dimanche 4 janvier 2009 20:52
A : discuss@restlet.tigris.org
Objet : Re: restlet 1.1.1, Spring and issue with loosing a connection

On Sun, Jan 04, 2009 at 02:50:53PM +0100, Jerome Louvel wrote:
> Hi Eugeny,
> 
> When you removed the Simple HTTP server, you probably falled-back on the 
> Restlet internal HTTP server which doesn't preemptively
> close such connections.
> 
> In Restlet 1.2, we'll upgrade to Simple 5 which may improve this behavior.

Well, so the issue with a connection reset when using Simple HTTP server can't 
be resolved for now?

-- 
Eugene Dzhurinsky

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1003727

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1022142

RE: help with spring/servlet integration and applicaiton modificaton

[Jerome Louvel]

Hi Matt,

Were you able to solve this?

Did you specify your application class properly in your ServerServlet 
parameters?

 
 org.restlet.application
 com.mycompany.HwApplication
 

Best regards,
Jerome Louvel
--
Restlet ~ Founder and Lead developer ~ http://www.restlet.org
Noelios Technologies ~ Co-founder ~ http://www.noelios.com


-Message d'origine-
De : matt [mailto:mattcam...@gmail.com] 
Envoye : mercredi 31 decembre 2008 21:02
A : discuss@restlet.tigris.org
Objet : help with spring/servlet integration and applicaiton modificaton

Hi There-

I have been using restlet for a few weeks steady now and love it but now have a 
problem with spring and servlets and complete
integration. I am using as a base the spring cvs repository pointed to on the 
wiki and using. Here is my situation, not sure if I am
attacking it correctly or if i can.

I want to make modifications to my 'base application' that is used in my 
servlet with the spring router. For example suppose I have
a base application like this:

// Extends Application
public HwApplication() {
super();
TunnelService ts = new TunnelService(true,true,true,true,true);
ts.setMediaTypeParameter("mt");
this.setTunnelService(ts);
}

Here is one of the variations of my applicationContext-router.xml file that I 
used. I thought this would work from the docs on the
wiki.













What happens is that when com.hw.rest.HwResource is used it does not have a 
handle to my application but a generic restlet
application. I have tried a variety of things from the wiki examples and also 
the CVS repo and nothing seems to work. So in my use
case I am not getting the tunneling or the media conversion i need via my 
custom application..

Somewhere something is not getting bound correctly. This is happening in the 
servlet situation only. I am digging around the code
now the best I can to see where things get switched up. I obviously and more 
sure on the correct binding order.

If anybody has advice or an example from their own work that does this I am 
super appreciative!

matt

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=997142

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1022118

RE: securing Restlet 1.2

[Jerome Louvel]

Hi all,

Let's continue this discussion in the developers mailing list. 

See my reply there:
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=7458&dsMessageId=1022072

Best regards,
Jerome Louvel
--
Restlet ~ Founder and Lead developer ~ http://www.restlet.org
Noelios Technologies ~ Co-founder ~ http://www.noelios.com


-Message d'origine-
De : Raif S. Naffah [mailto:tig...@naffah-raif.name] 
Envoye : samedi 3 janvier 2009 00:19
A : discuss@restlet.tigris.org
Objet : securing Restlet 1.2

hello all,

i went through the 13 "High priority enhancements for Restlet 1.2" in the 
"Requirements" section of "Security re-factoring" found here 
(http://wiki.restlet.org/developers/172-restlet/212-restlet.html) and tried 
to classify them in order to come up with an implementation plan.  here are 
my thoughts:

* the only one comprehensive approach for covering Authentication and 
Authorization needs is JSecurity ([I658] Add support for JSecurity).  if 
implemented, this would IMO also achieve:

  # [I288] Support pre-emptive authentication
  # [I503] Give access to connector authentication
  # [I504] Add notion of realm
  # [I605] Support cookie based authentication

the other requirements, excluding [I505] Re-factor authentication and 
authorization, can be classified as:

* add support for more/other authentication mechanisms.  these could be 
achieved by implementing JSecurity classes (in org.jsecurity.authc packages) 
either in the JSecurity project, or here and contributing them to that 
project:

  # [I444] Support SPNEGO authentication
  # [I446] Support OpenID authentication
  # [I447] Support JAAS authentication

* improving the current mechanisms.  these could be achieved by designing 
the framework to allow (at least the Guard) to inject security constraints 
and have the (Guard) methods delegate the work to the security framework.  
this way the existing (and future) work done on the Guard would not be lost 
or in need of (too much) re-writing:

  # [I485] Support htpasswd encrypted files in Guard
  # [I567] Improve HTTP Digest support
  # [I606] Improve OAuth extension
  # [I634] Guard.checkSecret should accept a Response object


i'm seeking feedback on the following proposed plan:

* adopt JSecurity (http://www.jsecurity.org/) as the base Authentication and 
Authorization provider for Restlet.  their code is published under an Apache 
2.0 Open Source License, and the project itself is in incubation state for 
becoming an Apache product.

* hide as little as possible JSecurity classes in Restlet.  this basically 
means adding a dependency to the Restlet Core on the JSecurity JARs --for 
JDK 5 and later, the following is a minimum (when the security services are 
enabled): jsecurity.jar, commons-logging.jar; for heterogeneous clients, SSO 
support: ehcache.jar, and backport-util-concurrent.jar.

* add one service (SecurityService in org.restlet.service) and enough 
classes in Restlet (mainly org.restlet.security package) to configure, 
enable/disable and use the JSecurity classes.

* re-factor Guard to re-use the above so its existing sub-classes can 
continue to work unchanged.


at a later stage, i think it could be beneficial to look at how we can 
configure and use this security framework separately or in collaboration at 
the Component, VirtualHost and Application levels.


cheers;
rsn

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1000150

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1022074

media type adaptor

[Taylor Cowan]

I'm new to restlets and would like some feedback from the community on some 
experimentation.  Instead of if/else'ing through the list of variant types and 
calling the appropriate logic, I'd like reslets to do that for me.

The example "MediaType" below is similar to the restlet version, except that 
each enumeration overrides a call back, for example, the text/html type calls 
back to handleTextHTML().


TEXT_HTML("text/html", "HTML document") {
@Override
public Representation callBack(VariantHandler arg0) {
return arg0.handleTextHTML();
}
},

The application developer then extends a resource from BaseResource, and 
implements the methods they'd like to handle.  (like the AWT MouseEvent 
adaptors of old) The examples are not complete, I only implmented 4 media 
types.  The BaseResource gets the media type, converts to the appropriate 
extended MediaType, and the invokes the callback.

@Override
public Representation represent(Variant variant) throws ResourceException {
String mediaType = variant.getMediaType().getName();
return MediaType.value(mediaType).callBack(this);
}


So to handle HTML, the developer just does this:

@Override
public Representation handleTextHTML() {
   // here's where we respond to HTML clients.
}



http://restlets.s3.amazonaws.com/VariantHandler.java
http://restlets.s3.amazonaws.com/BaseResource.java
http://restlets.s3.amazonaws.com/MediaType.java

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1022069

Re: Re: Tomcat appears to swallow Allow: header

[Rob Heittman]

Hi Priya,

There's a good chance Eirik Bjørsnøs recently identified the root of
the problem here:

http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1006267

He says "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 think 5.5 suffers from the same issue, though 6.x does not.  I can't
see an easy way to change Restlet to fix this ... Jerome, Thierry,
help?  Eirik seemed to think that just changing the order of Restlet
operations to work, but I can't think of a good way to defer setting
the content length in these cases.

- Rob

On Mon, Jan 12, 2009 at 11:49 AM, Priya Matpadi  wrote:
>
> I have successfully used restlet 1.0.10 with tomcat (5.5) container. I have 
> services that return 204 on HTTP POST and PUT, no content in body, but they 
> return cookies as set in the restlet response object.
>
> When I upgraded to restlet 1.1.1, I found problems in the restlet framework 
> mapping restlet response to tomcat 5.5 httpservletresponse for services that 
> return 204 response code.  This mapping is silently failing, we always get a 
> response code of 200 and the headers (including cookies) get lost. Note that 
> the LogFilter accurately displays that service returns 204, but with tomcat 
> request dumper valve enabled I verified that tomcat neither gets this 
> response code nor the headers.
>
> I followed Rob's suggestion, and added a dummy entity with a 204 response 
> code.
>
>getResponse().setEntity(new StringRepresentation("This entity is 
> not changed", MediaType.TEXT_PLAIN));
> getResponse().setStatus(Status.SUCCESS_NO_CONTENT);
>
> And voila, the response comes out with a 204 response code with the headers 
> as expected. Also, as expected the dummy entity gets stripped out.
>
> We use jetty for development environment only, and this is not reproducible 
> with jetty. However, we are seeing this issue only with restlet 1.1.1. We 
> have not changed our tomcat version or settings.
>
> This behavior is really bizarre. We know that the dummy entity gets stripped 
> out in HttpServerConverter.commit(); then it is not making sense to me as to 
> why setting dummy entity in the response is a fix.
>
>
> > I identified the problem: Tomcat is not properly returning Responses with no
> > entity.  The two acute places this is obvious is with 304 Not Modified
> > responses and with the OPTIONS response.  Tomcat returns a 200 OK with some
> > default headers, instead of passing the correct header set and no entity
> > emerging from Restlet.
> >
> > I verified that the version of Tomcat embedded in GWT 1.4 exhibits the
> > problem, but haven't yet verified it in other places.
> >
> > The workaround (which will cause Restlet 1.1 to gripe, but works) is to emit
> > an entity anyway, when none is called for, e.g. new
> > StringRepresentation("This entity is not changed",MediaType.TEXT_HTML);  In
> > my application, I keyed this to a system property so that the non-compliant
> > behavior can be turned on only when needed.
> >
> > Someone who is more knowledgeable than I am about the Servlet extension may
> > be able to figure out if this is a Restlet bug or not.
> >
> > On Wed, Sep 3, 2008 at 3:56 PM, Rob Heittman 
> > wrote:
> >
> > > In some cases Tomcat appears to swallow the Allow: header that leaves
> > > Restlet in response to an OPTIONS request.  The Allow: header of the
> > > response is populated, and I tracked it all the way down through 
> > > ServletCall
> > > and verified Restlet is doing the right thing.  But, the OPTIONS response
> > > sent to the client from Tomcat is stripped of this and other useful 
> > > headers
> > > (like DAV: 1,2).
> > >
>
> --
> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1019528

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1021950

Re: Command line to STOP Restlet server

[Simon Reinhardt]

Leshek wrote:
> I know from within I can do getContext().getApplication().stop()
> I could to it in response to http request .../STOP, but... I want to keep 
> control on the server only.

Apart from the Service Wrapper already pointed out, you could always restrict 
access to such a resource. Either with HTTP Auth or by restricting the client 
host to localhost or both.

Regards,
  Simon

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1021804

Re: Command line to STOP Restlet server

[Tim Peierls]

Take a look at Java Service Wrapper:
http://wrapper.tanukisoftware.org/

It covers all sorts of possibilities.

--tim

On Mon, Jan 12, 2009 at 12:29 PM, Leshek  wrote:

> I want to have stop and exit restlet server command line interface.
> The start is simple (java -jar myRest.jar).
>
> I know from within I can do getContext().getApplication().stop()
> I could to it in response to http request .../STOP, but... I want to keep
> control on the server only.
>
> So I am looking for something like starting a new Java application
>
> java -jar myRest.jar STOP
>
> to tell the other application to STOP cleanly.
>
> --
>
> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1019583
>

RE: Re: Tomcat appears to swallow Allow: header

[Priya Matpadi]

I have successfully used restlet 1.0.10 with tomcat (5.5) container. I have 
services that return 204 on HTTP POST and PUT, no content in body, but they 
return cookies as set in the restlet response object. 

When I upgraded to restlet 1.1.1, I found problems in the restlet framework 
mapping restlet response to tomcat 5.5 httpservletresponse for services that 
return 204 response code.  This mapping is silently failing, we always get a 
response code of 200 and the headers (including cookies) get lost. Note that 
the LogFilter accurately displays that service returns 204, but with tomcat 
request dumper valve enabled I verified that tomcat neither gets this response 
code nor the headers.

I followed Rob’s suggestion, and added a dummy entity with a 204 response code.

getResponse().setEntity(new StringRepresentation("This entity is 
not changed", MediaType.TEXT_PLAIN));
getResponse().setStatus(Status.SUCCESS_NO_CONTENT);

And voila, the response comes out with a 204 response code with the headers as 
expected. Also, as expected the dummy entity gets stripped out.

We use jetty for development environment only, and this is not reproducible 
with jetty. However, we are seeing this issue only with restlet 1.1.1. We have 
not changed our tomcat version or settings.

This behavior is really bizarre. We know that the dummy entity gets stripped 
out in HttpServerConverter.commit(); then it is not making sense to me as to 
why setting dummy entity in the response is a fix. 


> I identified the problem: Tomcat is not properly returning Responses with no
> entity.  The two acute places this is obvious is with 304 Not Modified
> responses and with the OPTIONS response.  Tomcat returns a 200 OK with some
> default headers, instead of passing the correct header set and no entity
> emerging from Restlet.
> 
> I verified that the version of Tomcat embedded in GWT 1.4 exhibits the
> problem, but haven't yet verified it in other places.
> 
> The workaround (which will cause Restlet 1.1 to gripe, but works) is to emit
> an entity anyway, when none is called for, e.g. new
> StringRepresentation("This entity is not changed",MediaType.TEXT_HTML);  In
> my application, I keyed this to a system property so that the non-compliant
> behavior can be turned on only when needed.
> 
> Someone who is more knowledgeable than I am about the Servlet extension may
> be able to figure out if this is a Restlet bug or not.
> 
> On Wed, Sep 3, 2008 at 3:56 PM, Rob Heittman 
> wrote:
> 
> > In some cases Tomcat appears to swallow the Allow: header that leaves
> > Restlet in response to an OPTIONS request.  The Allow: header of the
> > response is populated, and I tracked it all the way down through ServletCall
> > and verified Restlet is doing the right thing.  But, the OPTIONS response
> > sent to the client from Tomcat is stripped of this and other useful headers
> > (like DAV: 1,2).
> >

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1019528

Command line to STOP Restlet server

[Leshek]

I want to have stop and exit restlet server command line interface.
The start is simple (java -jar myRest.jar).

I know from within I can do getContext().getApplication().stop()
I could to it in response to http request .../STOP, but... I want to keep 
control on the server only.

So I am looking for something like starting a new Java application

java -jar myRest.jar STOP

to tell the other application to STOP cleanly.

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1019583

Command line to STOP Restlet server

[Leshek]

I want to have stop and exit restlet server command line interface.
The start is simple (java -jar myRest.jar).

I know from within I can do getContext().getApplication().stop()
I could to it in response to http request .../STOP, but... I want to keep 
control on the server only.

So I am looking for something like starting a new Java application

java -jar myRest.jar STOP

to tell the other application to STOP cleanly.

Leshek
Ps. Posting it over web interface, regular reader post did not go through...

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1020497