JAX RS ExceptionMappers by MessageBodyWriter
Disclaimer: the behaviour I'm about to describe might be entirely corret and true to the JAX RS specifications, I just haven't been able to confirm it. I'm a big fan of the ExceptionMapper mechanism, but I discovered that they are only triggered when a resource method (annotated by @GET, @POST...) throws an exception. Say that you have a MessageBodyWriter implementation that checks its MediaType argument to try and respect client charset wishes - if a client asks for us-ascii and I can support it, then I might as well rather than use the default utf-8. If the client were to request an unknown encoding (say, zorglub), an UnsupportedCharsetException will be triggered. This exception will not be caught by any ExceptionMapper I might have registered. If it *were* caught, it would allow application developers to not worry about exceptions at all: just throw whatever exception you might need to throw and rely and the mappers to catch them and return the correct HTTP status code to the client. In my example, I know that an UnsupportedCharsetException should always be mapped to UNSUPPORTED_MEDIA_TYPE, and I don't want to duplicate this mapping in all of my MessageBodyWriters or MessageBodyReaders. Is the fact that this doesn't happen a RESTlet issue, or a specification issue (decision I don't agree with but might not understand the reason for) ? Nicolas -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2377287
Server connector parameters ignored when configuring from Spring
Hello, While developing my restlet application i faced following problem. Im using restlet 2.0m3 with Jetty server connector and configuring my server from Spring. This is snippet of XML file bean id=springComponent class=org.restlet.ext.spring.SpringComponent init-method=start property name=clientsList list valuehttp/value /list /property property name=server bean class=org.restlet.ext.spring.SpringServer id=springServer constructor-arg value=http type=java.lang.String/ constructor-arg value=4343 type=int/ property name=parameters map entry key=acceptorThreads value=20/ entry key=acceptQueueSize value=400/ entry key=maxThreads value=800/ /map /property /bean /property property name=defaultTarget ref=springRouter/ /bean The expected behaviour of passing the parameters to underlying jetty instance has not occurred. While debugging and researchign source code i found following in class JettyServerHelper method public SeriesParameter getHelpedParameters() always returns empry parameters because method getHelped() returns null. Can anyone give me a hand and explain if this is a bug or i'm configuring server connector incorrectly ? -- Regards, Evgeny Shepelyuk -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2377285
Hanging StreamServerHelper stop() after serving huge XML files
Hi all,
I encountered a strange issue when trying to stop() a Server using a
StreamServerHelper.
This only occurs after serving large stream of data, e.g. an XML file of more
than 800ko.
I am using Restlet 1.1, and exhibit this problem with the attached java
example, which generates an big XML string on the fly.
Thanks in advance,
Martinpackage net.masagroup.trials.crossbow.server;
import java.io.IOException;
import java.util.List;
import java.util.Vector;
import org.restlet.Application;
import org.restlet.Client;
import org.restlet.Restlet;
import org.restlet.Router;
import org.restlet.Server;
import org.restlet.data.MediaType;
import org.restlet.data.Protocol;
import org.restlet.data.Request;
import org.restlet.data.Response;
public class TestSingleUri {
protected Server server_;
protected Client client_;
protected static final int PORT = 666;
protected static final String HOST = http://localhost:; + PORT;
protected static final String URI = /test;
public static void main(String[] args) {
TestSingleUri test = new TestSingleUri();
try {
System.out.println(expect to read 'successfull stop');
test.init();
test.test();
test.stop();
System.out.println(successfull stop, meaning the server was not hanging);
} catch (Exception e) {
e.printStackTrace();
}
}
protected void init() throws Exception {
Application app = getApp();
ListProtocol protocols = new VectorProtocol();
protocols.add(Protocol.HTTP);
server_ = new Server(protocols, PORT, app);
server_.start();
client_ = new Client(protocols);
}
protected void stop() throws Exception {
client_.stop();
server_.stop();
}
protected Application getApp(){
return new Application(){
public Restlet createRoot() {
Router r = new Router();
r.attach(URI, new Restlet(){
public void handle(Request request, Response response){
response.setEntity(getBigXml(5), MediaType.TEXT_XML);
}
});
return r;
}
public String getBigXml(int size){
StringBuffer xml = new StringBuffer(1000);
xml.append(bigxml\n);
for(int i=0; isize; i++){
xml.append( tralalablablabla/tralala\n );
}
xml.append( /bigxml );
return xml.toString();
}
};
}
public void test() throws IOException{
Response response = client_.get(HOST + URI);
System.out.println(response: + response.getStatus().isSuccess());
//System.out.println(found: + response.getEntity().getText());
}
}
Wrong Resource baseRef when using WadlApplication
Hi, I have a problem concerning wrong resource paths in the WADL output of a WadlApplication. I have a WADL application to which I attach several restlets. When an OPTIONS request is received, it reaches the router of the WADL application. If there is a matching route to a restlet, the request resource baseRef gets adapted to the URI of the resource itself (in Route.beforeHandle()). Then in the target restlet handle() method I set the allowed methods and do a return. The further processing is done in WadlApplication.handle(). There, the request resource baseRef is still the restlet ressource URI and *not* the base URI of the WadlApplication. This results in wrong ressource URIs in the generated WADL. When I submit an OPTIONS request that reaches the WadlApplication, but which is not routed to any restlet after that (like http:[applicationBasePath]/nonExistingPath?method=OPTIONS), the generated WADL has the correct URIs. Any ideas how to fix this? I thought about adapting the request resource baseRef in the restlet handle() method (setting it back to the application baseRef), but that does not seem to be a clean solution. TIA, Carsten -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2376892
Server.stop() hangs eternally after serving huge XML files
Hi all,
The Server I'm using uses a StreamServerHelper that hangs when its stop()
method is called. StreamServerHelper.stop() get frozen when the following call
is made:
handlerService.awaitTermination(Long.MAX_VALUE,TimeUnit.SECONDS);
(where handlerService is an ExecutorService)
The problem becomes very annoying when running testcases where the server
starts and stops several times.
Does anybody have an idea or workaround for solving this problem?
I have provided an example to exhibit the problem (see also attachment). As you
can see, I generate 5 small XML items so that I have a 1.5Mo file as output.
---
public class TestShutdownBug {
protected Server server_;
protected Client client_;
protected static final int PORT = 666;
protected static final String HOST = http://localhost:; + PORT;
protected static final String URI = /test;
public static void main(String[] args) {
TestShutdownBug test = new TestShutdownBug();
try {
System.out.println(expect to read 'successfull stop');
test.init();
test.test();
test.stop();
System.out.println(successfull stop, meaning the
server was not hanging);
} catch (Exception e) {
e.printStackTrace();
}
}
protected void init() throws Exception {
Application app = getApp();
ListProtocol protocols = new VectorProtocol();
protocols.add(Protocol.HTTP);
server_ = new Server(protocols, PORT, app);
server_.start();
client_ = new Client(protocols);
}
protected void stop() throws Exception {
client_.stop();
server_.stop();
}
protected Application getApp(){
return new Application(){
public Restlet createRoot() {
Router r = new Router();
r.attach(URI, new Restlet(){
public void handle(Request request, Response
response){
response.setEntity(getBigXml(5),
MediaType.TEXT_XML);
}
});
return r;
}
public String getBigXml(int size){
StringBuffer xml = new StringBuffer(1000);
xml.append(bigxml\n);
for(int i=0; isize; i++){
xml.append( tralalablablabla/tralala\n );
}
xml.append( /bigxml );
return ml.toString();
}
};
}
public void test() throws IOException{
Response response = client_.get(HOST + URI);
System.out.println(response: +
response.getStatus().isSuccess());
//System.out.println(found: + response.getEntity().getText());
}
}
-
Regards,
Martin
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2377305
Re: JAX RS ExceptionMappers by MessageBodyWriter
Hi Nicolas, where do you want to thrwow this exception? In the method isWriteable it sounds reasoneable to me. But I can't say now, if it is possible, but should be, I think. You can't handle thrown exceptions in the write method, because it is called AFTER the status code and the HTTP headers are send to the net. Than you can't change them. best regards Stephan Nicolas Rinaudo schrieb: Disclaimer: the behaviour I'm about to describe might be entirely corret and true to the JAX RS specifications, I just haven't been able to confirm it. I'm a big fan of the ExceptionMapper mechanism, but I discovered that they are only triggered when a resource method (annotated by @GET, @POST...) throws an exception. Say that you have a MessageBodyWriter implementation that checks its MediaType argument to try and respect client charset wishes - if a client asks for us-ascii and I can support it, then I might as well rather than use the default utf-8. If the client were to request an unknown encoding (say, zorglub), an UnsupportedCharsetException will be triggered. This exception will not be caught by any ExceptionMapper I might have registered. If it *were* caught, it would allow application developers to not worry about exceptions at all: just throw whatever exception you might need to throw and rely and the mappers to catch them and return the correct HTTP status code to the client. In my example, I know that an UnsupportedCharsetException should always be mapped to UNSUPPORTED_MEDIA_TYPE, and I don't want to duplicate this mapping in all of my MessageBodyWriters or MessageBodyReaders. Is the fact that this doesn't happen a RESTlet issue, or a specification issue (decision I don't agree with but might not understand the reason for) ? Nicolas -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2377287 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2377407
A simple URI problem
I've spent several hours reading this nabble and online documentation and
still can't get a simple variation of firstResources for Restlet 2.0 to
work.
In my case, i have a web app running on Tomcat 6.0.14 that i want to
retrofit to include restlets. I have several servlets defined, so using /*
as my servlet-mapping isn't possible. Everyone says you can specify a
mapping that the Restlet API will recognize, but mine fails with a The
server has not found anything matching the request URI message. I
specified the URI via restlet.xml and as shown below. Access to the other
servlets in the application are not affected, i.e. they work.
my mapping in web.xml:
servlet-mapping
servlet-nameRestletServlet/servlet-name
url-pattern/myResource/*/url-pattern
/servlet-mapping
the body of my applications createRoot() includes:
router.attach(/myResource/buildings, BuildingsResource.class);
router.attach(/myResource/buildings/{buildingName},
BuildingResource.class);
//
myLog.info(myResources:+router.get(/myResource/buildings).getEntityAsText());
//
myLog.info(myResource:+router.get(/myResource/buildings/Indiana).getEntityAsText());
Output from catalina.log is good, so i know that the request is being passed
to my restlet:
Jul 31, 2009 10:09:25 AM org.restlet.engine.log.LogFilter afterHandle
INFO: 2009-07-3110:09:25127.0.0.1 - 127.0.0.1
9006GET
/myResource/buildings - 404 330 - 1
http://127.0.0.1:9006 Mozilla/5.0
(Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.0.12)
if i uncomment the getEntityAsText() calls in createRoot(), I get good
results so I know my implementation of BuildingsResource and
BuildingResource are working.
does anyone see what i'm doing wrong?
--
View this message in context:
http://n2.nabble.com/A-simple-URI-problem-tp3363341p3363341.html
Sent from the Restlet Discuss mailing list archive at Nabble.com.
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2377446
Philosophical question: is ServerResource a resource?
Hi, First of all, let me assure that I really don't want to start a flame war ;-) My goal is just to have a better understand of REST and RESTLET. As I am delving into the REST world, which includes using RESTLET to have a concrete grasp on the concepts, I've been noticing that the question on the subject has been haunting me. I like to think that I have a strong modeling background and because of that, I tend to pay a lot of attention on the name used to describe a concept. I know that resource is a very open ended definition. That said, most of the times it seems to be related to the actual thing that is manipulated, regardless of its format, shape, race, religion, ... If this assertion is correct, looking at the First Resource example, I would say that Item is the resource. For argument sake, I think I agree that Items is a resource a well. What about 'ItemResource', though? OK... If everything is a resource, this is a resource as well. But the REST world also describes the concept of a Representation. And the more I think about it, the more I see 'ItemResource', and, ultimately, 'ServerResource' as a 'Representation Consumer/Provider' (or, for a lack of a better term, a 'RepresentaionHandler'). A 'ServerResource' object has a very short lifecycle, should not maintain state, and its sole purpose is to either generate one or more representations (@GET(xml), @GET(json), ...), or to consume representation that will ultimately result in an operation being applied to a resource. So, repeating the subject, is ServerResource a resource? -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2377427
ServerResource or Restlet
Hy everybody, I'have just discovered Restlet. Previously I have writed my own REST Framework (who was abstract servlet and helper classes). But now I need a better framework and Restlet seems to be really better. But I have some difficulties to know if I must extend org.restlet.Restlet or org.restlet.resource.ServerResource. In my current tests I have extended Restlet but now I want to negociate content and it seems that ServerResource are more usefull for that. - Why and when must I choose one class or another ? Thanks (My current test Restlet is attached) -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2377408 FormsResource.java Description: Binary data RestletResource.java Description: Binary data
Support of editions
Hello all, you may have noticed that the distribution for the current snapshot has changed and that a new notion of edition has emerged: http://www.restlet.org/downloads/ An edition is a complete distribution, like the usual one, except that it targets a single platform: Android (mobile devices), Google Web Toolkit (rich internet applications), Google App Engine (cloud computing), Java EE and Java SE (like Java EE but without Servlet integration). The code for Android, GAE and GWT requires adaptations of the classic Java source code because those platforms only support a subset of the JRE APIs. As a result, the former org.restlet.(gwt|gae|android).jar modules had to be ported manually, which consumed a lot of our time and caused troubles due to lack of synchronization with the main trunk. Now, this porting is done automatically using conditional compilation on a single code base. You can find details about the solution here: http://wiki.restlet.org/developers/261-restlet/267-restlet.html Of course your remarks, suggestions and bug reports are very welcome. Please note also that the Maven artifacts will be available under a different group ID. They move from org.restlet to org.restlet.edition. Best regards, Thierry Boileau -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2377457
