RE: Command line to STOP Restlet server
Hi Leshek,
Here is a way that should work in Restlet 1.0:
public static void main(String[] args) {
try {
Component component = new Component();
component.getServers().add(Protocol.HTTP, 8182);
MyApplication myApp = new MyApplication(component.getContext());
myApp.getContext().getAttributes().put("component", component);
component.getDefaultHost().attach(myApp);
component.start();
Note that if you are in Restlet 1.1, you shouldn't pass the parent component's
context directly. Instead, do something like:
public static void main(String[] args) {
try {
Component component = new Component();
component.getServers().add(Protocol.HTTP, 8182);
MyApplication myApp = new MyApplication();
// Will automatically set the right context on myApp
component.getDefaultHost().attach(myApp);
myApp.getContext().getAttributes().put("component", component);
component.start();
Hope this will help.
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 : jeudi 15 janvier 2009 00:21
A : discuss@restlet.tigris.org
Objet : Re: Command line to STOP Restlet server
> When you stop the parent Component, it stops all the child connectors.
Sounds like a simple, nice, soft stop for me, but...
What I am thinking is to respond to URI request like PUT .../shutdown
(limit to localhost request and run through authentication guard as all
the other requests).
How in the resource do I get to parent component when I started Restlet HTTP
server using main in my application as follows, or am I doing something
silly here? :
public static void main(String[] args) {
try {
Component component = new Component();
component.getServers().add(Protocol.HTTP, 8182);
component.getDefaultHost().attach(new
MyApplication(component.getContext()));
component.start();
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1025076
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1026048
Re: Patch to parameterize port numbers in JUnit tests
hello Jerome,
i've attached a new version done with kdesvn instead of Eclipse (previous
version).
On Thu January 15 2009 06:59:06 Jerome Louvel wrote:
> Hi Raif,
>
> That sounds like a useful thing to do. I was trying to apply the patch
> but got issues with the paths of the patched files.
>
> Could you try to use SVN instead to generate it, starting at the root of
> the SVN trunk instead?
>
> For Spring it should be possible to inject the static value into the bean
> property. I don't remember the exact syntax, but we can figure this out.
> Any Spring wizard listening?
>
> 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 10 janvier 2009 07:48
> A : discuss@restlet.tigris.org
> Objet : Patch to parameterize port numbers in JUnit tests
>
> hello there,
>
> the JUnit tests (in org.restlet.test) have hard-wired port numbers which
> may not suit every developer's environment. this patch introduces a new
> property in the main build.xml, and injects at as a system environment
> variable.
>
> when more than one port is required, the property value is used as a
> base; i.e. second port number is valueOf(property) + 1, etc.
>
> the only test i was not able to parametrize was the Spring test (and its
> .xml file).
>
>
> cheers;
> rsn
>
> --
> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=10
>24775
cheers;
rsn
Index: build/build.properties
===
--- build/build.properties (revision 4122)
+++ build/build.properties (working copy)
@@ -58,7 +58,8 @@
# Indicates if the NSIS tool should be run over the
# distribution files
-nsis: true
+#nsis: true
+nsis: false
nsis-makensis-path: /usr/bin
# Verbose flag currently used during Java compilation
@@ -73,3 +74,6 @@
# Indicates if the final packaging phase should be done.
package: true
+
+# Port number to use for JUnit tests
+port-number: 3
Index: modules/org.restlet.test/src/org/restlet/test/ComponentXmlTestCase.java
===
--- modules/org.restlet.test/src/org/restlet/test/ComponentXmlTestCase.java
(revision 4122)
+++ modules/org.restlet.test/src/org/restlet/test/ComponentXmlTestCase.java
(working copy)
@@ -42,9 +42,9 @@
*/
public class ComponentXmlTestCase extends TestCase {
-private final int port = 8182;
+private final int port = RestletTestSuite.PORT;
-private final int port2 = 8183;
+private final int port2 = port + 1;
public void testComponentXMLConfig() throws Exception {
final StringBuilder builder = new StringBuilder();
Index: modules/org.restlet.test/src/org/restlet/test/RangeTestCase.java
===
--- modules/org.restlet.test/src/org/restlet/test/RangeTestCase.java
(revision 4122)
+++ modules/org.restlet.test/src/org/restlet/test/RangeTestCase.java
(working copy)
@@ -178,7 +178,7 @@
@Override
protected void setUp() throws Exception {
component = new Component();
-component.getServers().add(Protocol.HTTP, 8182);
+component.getServers().add(Protocol.HTTP, RestletTestSuite.PORT);
component.getClients().add(Protocol.FILE);
component.getDefaultHost().attach(new TestRangeApplication());
component.start();
@@ -199,13 +199,14 @@
Client client = new Client(Protocol.HTTP);
// Test partial Get.
Request request = new Request(Method.GET,
-"http://localhost:8182/testGet";);
+"http://localhost:"; + RestletTestSuite.PORT + "/testGet");
Response response = client.handle(request);
assertEquals(Status.SUCCESS_OK, response.getStatus());
assertEquals("1234567890", response.getEntity().getText());
assertEquals(10, response.getEntity().getSize());
-request = new Request(Method.GET, "http://localhost:8182/testGet";);
+request = new Request(Method.GET, "http://localhost:";
++ RestletTestSuite.PORT +"/testGet");
request.setRanges(Arrays.asList(new Range(0, 10)));
response = client.handle(request);
assertEquals(Status.SUCCESS_PARTIAL_CONTENT, response.getStatus());
@@ -268,7 +269,7 @@
// PUT on a file that does not exist
Request request = new Request(Method.PUT,
-"http://localhost:8182/testPut/essai.txt";);
+"http://localhost:"; + RestletTestSuite.PORT
+"/testPut/essai.txt");
request.setEntity(new StringRepresentation("1234567890"));
request.setRanges(Arrays.asList(new Range(0, 10)));
Response response = client.handle(request);
@@ -280,7 +281,7 @@
RE: POST/PUT requests take more than 2 seconds
Hi Olivier, Which version of Restlet are you using? Did you try Restlet 1.1.1? 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 : Olivier Bruchez [mailto:oliv...@bruchez.org] Envoye : jeudi 15 janvier 2009 00:59 A : discuss@restlet.tigris.org Objet : POST/PUT requests take more than 2 seconds I actually have the same problem as Avi here: http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=930917 Almost the same configuration, Mac OS 10.5.6. Internal HTTP server. When handling POST/PUT requests, the Entity.getText() method takes 2 seconds to return a string. Is there any solution to this problem, other than not using the internal HTTP server? Thanks, Olivier -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1025166 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1026071
thinking about standard rest service api's
Hi all, We've been doing some framework stuff on top of restlet and named that kauri (see http://kauriproject.org/) During that work we're seeing some recurring issues popping up that could be reflected in recurring or even "standardized" URI pattern designs. Guessing we might not be alone in this feeling we're looking for other people that are likely to share sentiments, feelings, insights, critiques on this. Some first thoughts are listed on our wiki at: http://kauriproject.org/wiki/g2/319-kauri.html Any feedback here, on our list at http://groups.google.com/group/kauri-discuss is welcomed. regards, -marc= -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1026556
Re: POST/PUT requests take more than 2 seconds
And which HTTP server connector are you using? -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1026632
RE: POST/PUT requests take more than 2 seconds
Hi Jérôme, Yes, I'm already using Restlet 1.1.1. I realized I have his problem only when I use RESTClient from Google (http://code.google.com/p/rest-client/). I don't have it when using cURL. Apparently. I need to investigate more. Olivier > Hi Olivier, > > Which version of Restlet are you using? Did you try Restlet 1.1.1? > > 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 : Olivier Bruchez [mailto:oliv...@bruchez.org] > Envoye : jeudi 15 janvier 2009 00:59 > A : discuss@restlet.tigris.org > Objet : POST/PUT requests take more than 2 seconds > > I actually have the same problem as Avi here: > > http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=930917 > > Almost the same configuration, Mac OS 10.5.6. Internal HTTP server. > > When handling POST/PUT requests, the Entity.getText() method takes 2 seconds > to return a string. > > Is there any solution to this problem, other than not using the internal HTTP > server? > > Thanks, > Olivier > > -- > http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1025166 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1026658
RE: Re: POST/PUT requests take more than 2 seconds
> And which HTTP server connector are you using? I don't use any connector. I think. I use the internal Restlet HTTP server: Component component = new Component(); component.getServers().add(Protocol.HTTP, 8182); component.getDefaultHost().attach(new TestApplication()); component.start(); Olivier -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1026672
Re: thinking about standard rest service api's
Hi Marc I'll be interested to read through your wiki. A small comment - you've got a typo on 'RestService API Allignment'. 'Allignment' should be 'Alignment'. Regards Ben Johnson -- From: "Marc Portier" Sent: Thursday, January 15, 2009 3:10 PM To: Subject: thinking about standard rest service api's > Hi all, > > We've been doing some framework stuff on top of restlet and named that > kauri (see http://kauriproject.org/) > > During that work we're seeing some recurring issues popping up that > could be reflected in recurring or even "standardized" URI pattern > designs. > > Guessing we might not be alone in this feeling we're looking for other > people that are likely to share sentiments, feelings, insights, > critiques on this. > > Some first thoughts are listed on our wiki at: > http://kauriproject.org/wiki/g2/319-kauri.html > > Any feedback here, on our list at > http://groups.google.com/group/kauri-discuss is welcomed. > > regards, > -marc= > > -- > http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1026556 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1026696
Re: thinking about standard rest service api's
Ben Johnson wrote: > Hi Marc > > I'll be interested to read through your wiki. A small comment - you've got a > typo on 'RestService API Allignment'. 'Allignment' should be 'Alignment'. > thx, fixed, looking forward to your feedback -marc= -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1026750
RE: media type adaptor
Jérôme,
Some more thoughts
from experience
1. Need a flag to determine if alternate representations are acceptable
(Requester asked for HTML, but I dont have that, and wish to return XML).
2. If alternate is acceptable, need a prioritized (ordered) list of
acceptable variants (look for XHTML, then look for HTML, then look for XML).
You should probably have a default, but it should be easy to override.
3. If you feel like getting into the browser nonsense (and Id
understand if you didnt), bypass/translate to another type. For example,
IE doesnt behave kindly to XHTML return type. Of course, any behavior here
must be customizable (overridable).
Cliff Binstock
Coyote Reporting
_
From: Jerome Louvel [mailto:jerome.lou...@noelios.com]
Sent: Wednesday, January 14, 2009 10:14 AM
To: discuss@restlet.tigris.org
Subject: RE: media type adaptor
Hi all,
We have a similar plan in the tube!
"Faciliate Resource to Representation mapping"
http://restlet.tigris.org/issues/show_bug.cgi?id=303
The idea is to dynamically dispatch the represent(*),
acceptRepresentation(*) and storeRepresentation(*) to the more specific
versions if available like:
representXml(?) for an XML representation ("xml" being mapped in
MetadataService like for file extensions)
representJson(?) for a JSON representation
...
This would handle the dispatching automatically while still allowing a
manual dispatching by overriding the generic represent(*) method when more
appropriate (and for backward compatibility).
How does it sound?
Best regards,
Jérôme Louvel
--
Restlet ~ Founder and Lead developer ~
Re: media type adaptor
Jerome,
that sounds good to me. The extent to which Restlets solves content negation
puts it head and shoulders above servlets and other web thingies.
My two cents is that's an area of priority, in comparison with all the planned
integrations (lucene, semweb, etc.). Also, Cliff's comments are good ones,
sounds like they've been doing a lot of this and went through the weeds already.
Taylor
From: Cliff Binstock
To: discuss@restlet.tigris.org
Sent: Thursday, January 15, 2009 12:30:52 PM
Subject: RE: media type adaptor
Jérôme,
Some more thoughts … from experience
…
1. Need a flag to determine if alternate representations are acceptable
(Requester asked for HTML, but I don’t have that, and wish to return XML).
2. If alternate is acceptable, need a prioritized (ordered) list of
acceptable variants (look for XHTML, then look for HTML, then look for XML).
You should probably have a default, but it should be easy to override.
3. If you feel like getting into the browser nonsense (and I’d
understand if you didn’t), bypass/translate to another type. For example, IE
doesn’t behave kindly to XHTML return type. Of course, any behavior here must
be customizable (overridable).
Cliff Binstock
Coyote Reporting
From:Jerome Louvel
[mailto:jerome.lou...@noelios.com]
Sent: Wednesday, January 14, 2009
10:14 AM
To: discuss @restlet.tigris.org
Subject: RE: media type adaptor
Hi all,
We have a similar plan in the tube!
"Faciliate Resource to Representation mapping"
http://restlet.tigris.org/issues/show_bug.cgi?id=303
The idea is to dynamically dispatch the represent(*), acceptRepresentation(*)
and storeRepresentation(*) to the more specific versions if available like:
representXml(?) for an XML
representation ("xml" being mapped in MetadataService like for file
extensions)
representJson(?) for a JSON
representation
...
This would handle the dispatching automatically while still
allowing a manual dispatching by overriding the generic represent(*)
method when more appropriate (and for backward compatibility).
How does it sound?
Best regards,
Jérôme Louvel
--
Restlet ~ Founder and Lead developer ~ http://www.restlet.org
Noelios
Technologies ~ Co-founder ~ http://www.noelios.com
De :Cliff Binstock [mailto:cliff.binst...@coyotereporting.com]
Envoyé : mardi 13 janvier
2009 17:43
À : discuss @restlet.tigris.org
Objet : RE: media type
adaptor
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=1027059
RE: Solr integration
Hi Jerome Yes, I will get back to you on this. thanks ilango --- On Wed, 1/14/09, Jerome Louvel wrote: From: Jerome Louvel Subject: RE: Solr integration To: discuss@restlet.tigris.org Date: Wednesday, January 14, 2009, 1:21 PM Hi Ilango, Could you describe some concrete integration scenarios where this would be useful? How would you mix the technologies? Best regards, Jérôme Louvel -- Restlet ~ Founder and Lead developer ~ http://www.restlet.org Noelios Technologies ~ Co-founder ~ http://www.noelios.com De : ilango [mailto:ilango...@yahoo.com] Envoyé : mercredi 14 janvier 2009 15:55 À : discuss@restlet.tigris.org Objet : Re: Solr integration Jerome I worked with Nutch in the past. I think Nutch and Lucene integrated into restlet would be good ilango --- On Mon, 1/12/09, R�mi Dewitte wrote: From: R�mi Dewitte Subject: Re: Solr integration To: discuss@restlet.tigris.org Date: Monday, January 12, 2009, 10:38 AM 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
Returning data after PUT/POST
Hello everyone, I'm currently working on my first restlet application and have one big question. Typically when I want to persist some data I will not know certain information about it (i.e. the ID of the data). Instead of creating the object and searching for it I usually design my DAO to return the same object with the missing information filled in once it's been submitted to the persistence layer. I have noticed in building my restlet app that the storeRepresentation method does not return any type of data, only a status. Some of the clients that will be using the service would greatly benefit from the DAO style of data creation. So, how can I mimick this behavior in restlet so that a successful PUT returns the data back to the client as representation? Thanks for your time, Jean-Philippe -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1027657
WADL and JAX-RS
I was wondering if there are any plans to add auto WADL generation for JAX-RS applications? Or is this already implemented in a newer version than 1.1? In general what is the current status of the JAX-RS support is it experimental or more ready for prime time? -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1027511
