Re: Restlet Jax-RS extension and OSGi
Hi David,
use
@Context
private StorageServiceResolver serviceResolver;
best regards
Stephan
David Fogel schrieb:
Hi Stephan-
I've been experimenting with the restlet.ext.jaxrs support, trying to
get a small test project working, and I've run into what seems like a
pretty big problem. While I am fairly new to JAX-RS, it is my
understanding that the suggested way of giving your Resource classes
access to other things in their environment (such as a persistence
service, a ServletContext, an osgi BundleContext, etc) is by creating
classes that extend javax.ws.rs.ext.ContextResolver, annotating them
with @Provider, and registering instances of them with the jax-rs
implementation. The container should then be able to inject these
custom objects into Resource classes that annotate a parameter or
field type with @Context.
For example, if I have a service class called StorageService, I would
create a ContextResolver like this:
@Provider
public class StorageServiceResolver extends ContextResolverStorageService {
private StorageService service;
public StorageServiceResolver(StorageService service) {
this.service = service;
}
public StorageService getContext(Class? type) {
return service;
}
}
I would then be able to access the StorageService object within my
Resource classes like this:
@Path(path/to/root/resource)
public class MyResource {
// should be able to do annotate a field:
@Context
private StorageService service;
// OR should be able to annotate a constructor param:
public MyResource(@Context StorageService service) {
this.service = service;
}
@GET
@Produces(text/plain)
public String getStoredThing(@QueryParam(id) String id) {
// and then access the service here:
return service.getValueForID(id);
}
}
But when I create such classes, and register them with your
JaxRsRestlet, the JaxRsRestlet refuses to accept the Resource classes,
claiming that they are missing any valid constructor or that a field
can not be injected with that type.
The problem may be that the methods in WrapperUtil.java don't make use
of the current set of providers, but instead expect only the minimal
set of predefined context types.
Is there some other way I'm missing to give my Resource classes access
to my application environment?
thanks,
-Dave Fogel
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1362709
How to authenticate to many websites seamlessly?
Hi! I want to use the Restlet client in my app along with a notion of Accounts. This means that the user will set up Accounts with logins to a number of websites, and when the application does HTTP requests to those websites the login info should be used automatically. How do I set up Restlet to do this? One way seems to be to subclass Client and override handle(), and on each call check what host is being called, and then add auth info. Is there a better, cleaner way to do it? If so, how? /Rickard -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1360302
Benchmark - Restlet 1.1.3
Hello all, some tests have been done with Restlet 1.1.3. The results are availabe here = http://www.restlet.org/documentation/1.1/benchmark Best regards, Thierry Boileau -- Restlet ~ core developper ~ http://www.restlet.org Noelios Technologies ~ co-fonder ~ http://www.noelios.com -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1363045
Re: Benchmark - Restlet 1.1.3
Hi Thierry- Thanks for posting those benchmarks. Another comparison that I'd be very interested to see added to your current benchmarks is between Restlet and non-Restlet solutions. For example, if the graphs you published were to also show a plain servlet solution on the different engines, as well as maybe a comparison to apache and lighttpd, etc. Obviously a lot depends on what kind of resources are being exposed- static file performance seems unlikely to tell us very much about real-world web application and web service performance. One of our questions in choosing to build our technology stack on top of Restlet is that we're not sure what the additional overhead is, given that Restlet adds some layers on top of, for instance, Jetty or Simple. To put it another way: what is the price in performance that we need to pay for a better more RESTful API? Thanks, -Dave Fogel -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1365644
Re: Restlet Jax-RS extension and OSGi
Stephan-
Maybe I should write shorter messages, so as to encourage people to
actually read them. :-)
As I said in my previous message, I tried to use field injection as
well as constructor param injection. Both attempts failed.
This is the log message I get when I try the annotated field approach
that you recommend:
Mar 20, 2009 12:48:14 PM
org.restlet.ext.jaxrs.internal.wrappers.ResourceClasses addRootClass
WARNING: The root resource class com.example.TestResource has an
illegal annotated and typed field: class com.example.StorageService
must not be annotated with @Context
Here is the method in your class
org.restlet.ext.jaxrs.internal.wrappers.params.ContextInjenctor
static Object getInjectObject(Class? declaringClass,
ThreadLocalizedContext tlContext, Providers providers,
ExtensionBackwardMapping extensionBackwardMapping)
throws IllegalTypeException, ImplementationException {
if (declaringClass.equals(Providers.class)) {
return providers;
}
if (declaringClass.equals(ContextResolver.class)) {
// NICE also throw, where the error occurs.
throw new IllegalTypeException(
The ContextResolver is not allowed for @Context
annotated fields yet. Use
javax.ws.rs.ext.Providers#getContextResolver(...));
}
if (declaringClass.equals(ExtensionBackwardMapping.class)) {
return extensionBackwardMapping;
}
if (declaringClass.equals(PathSegment.class)) {
final String msg = The use of PathSegment annotated with
@Context is not standard.;
logger.config(msg);
return new GetLastPathSegment(tlContext);
}
if (declaringClass.equals(SecurityContext.class)
|| declaringClass.equals(HttpHeaders.class)
|| declaringClass.equals(Request.class)) {
return tlContext;
}
if (declaringClass.equals(UriInfo.class)) {
throw new ImplementationException(
You must not call the method
ContextInjector.getInjectObject(...) with class UriInfo);
}
// NICE also allow injection of ClientInfo and Conditions. Proxies are
// required, because the injected objects must be thread local.
throw new IllegalTypeException(declaringClass
+ must not be annotated with @Context);
}
It doesn't appear that this code currently supports having custom
ContextResolver providers (although they appear to be available in the
providers parameter).
I'd very much appreciate it if you could take a closer look at this-
seems like an important part of any JAX-RS implementation!
-Dave Fogel
On Fri, Mar 20, 2009 at 4:04 AM, Stephan Koops stephan.ko...@web.de wrote:
Hi David,
use
�...@context
private StorageServiceResolver serviceResolver;
best regards
Stephan
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1365883
Re: Benchmark - Restlet 1.1.3
I don't have pretty graphs and charts, but here are my observations ... The low level API (the Restlet class and friends) is not materially different from low level code written for Servlet. When I looked at this long ago (Restlet 1.0), I could not tell any externally detectable performance difference between a Hello World Restlet and a Hello World Servlet running on the same machine under the same Tomcat 6 instance. I also tested a non-trivial WebDAV Servlet vs. a Restlet port and did not observe any performance difference. Now for the interesting part. When I optimized the Restlet WebDAV version to use the high level Resource API and less hand written stuff, the performance *increased* a tiny fraction -- 3% or so in requests served per second. And from a user perspective, the performance increased *much* more, because it now properly handled conditional GETs and other operations that my original code did not (and the JMeter based test harness did not test). This made people using the WebDAV layer feel a lot better liveness in their requests and snappier performance in Explorer or Finder. This general observation has borne out as we've moved apps to Restlet. The app doesn't slow down any if we just glue our old code under Restlet ... and the application performs drastically better when we use Restlet well. On Fri, Mar 20, 2009 at 12:27 PM, David Fogel carrotsa...@gmail.com wrote: One of our questions in choosing to build our technology stack on top of Restlet is that we're not sure what the additional overhead is, given that Restlet adds some layers on top of, for instance, Jetty or Simple. To put it another way: what is the price in performance that we need to pay for a better more RESTful API? -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1366010
Re: Benchmark - Restlet 1.1.3
Hi Rob- That's great to hear. In poking around the restlet code base, I wondered frequently if the additional object-creation/garbage-collection overhead of translating between native web requests and Restlet requests, as well as the throw-away style of Resource classes, would impact scalability. In looking at the various Representation classes implementation, it seemed that their performance/scalability might vary significantly depending on which subclass was being used- some implementations do thing like creating tasks to be run from a thread pool, and piping data through various structures. Anyhow, thanks for the restlet in-the-wild report! -Dave Fogel -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1366239
Re: Benchmark - Restlet 1.1.3
Good morning, On Friday 2009.03.20, at 09:27 , David Fogel wrote: [...] Thanks for posting those benchmarks. Another comparison that I'd be very interested to see added to your current benchmarks is between Restlet and non-Restlet solutions. For example, if the graphs you published were to also show a plain servlet solution on the different engines, as well as maybe a comparison to apache and lighttpd, etc. Obviously a lot depends on what kind of resources are being exposed- static file performance seems unlikely to tell us very much about real-world web application and web service performance. Um, er, without a clear idea of what that real-world application is, these micro-benchmarks won't tell you much. One of our questions in choosing to build our technology stack on top of Restlet is that we're not sure what the additional overhead is, given that Restlet adds some layers on top of, for instance, Jetty or Simple. To put it another way: what is the price in performance that we need to pay for a better more RESTful API? For static resources, there's really three main choices: * the traffic is small enough that it doesn't matter at all -- do whatever is easiest for you. * the traffic is enough that one should split out the static from the dynamic -- lots of ways to deal with this. * the traffic is huge and one needs lots of help -- CDNs, multiple data-centers, clouds, etc. Perhaps you can give us a more specific idea of what your target zone is or use case or something to narrow it down? For Krugle, we used lighttpd+mod_cache for caching, apache+mod_perl for the (stateless) front-side, and restlet+jetty for the app server / middleware gatekeeper (fronting all of the back end search features). IMHO, one of the key things to look at in terms of comparing wildly different technological approaches is how well they deal with various kinds of resource exhaustion. I.e., what happens when you can't run more Ruby worker processes; what happens when you start hitting full- GCs in Java solutions, etc. That will have a bigger impact on planning (if one cares, anyways :-) than milliseconds here or there on a micro-benchmark. As Rob mentioned, in my experience the basic performance of Restlet approach vs. Servlets is basically the same for servlet-ish code but one full step better if doing native restlet (on non-trivial workloads). Hope this helps, John -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1366279
Principal from HttpServletRequest
Is it possible to get the Princpal object from the HttpServletRequest without getting access to the HttpServletRequest itself. I'm using spring security as my authentication layer which sets a Principal in a wrapper of the request. Cheers, Paul -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1366843
Resource factories
Hey Restleters, Sorry if this question has been answered before -- I'm rather new to the community, even though I've been a heavy Restlet user for a while. I understand and agree with abstract class design used by Restlet, as is detailed by the wiki: http://wiki.restlet.org/developers/179-restlet/198-restlet.html However, I wonder if this has been taken too far, as regards the Finder class. Finder uses nothing but the Java class itself, and creates instances dynamically using newInstance(). But how do we inject initialization information to these instances? One idea, following the abstract class design, can be to inherit these classes and use different ones for different purposes. However, I've come across a situation in which this is problematic. Specifically, I want to have several Application instances running on the same component. These instances all use the same set of classes inherited from Resource. In many cases this works fine, but in some cases I want these classes to work slightly different per application. Specifically, there is shared information used by instances that I store as static field within the class. The problem is that both applications share the same static scope. Using the factory design pattern, I would have a problem -- factories can be used to create instances as I please. I understand the reluctance to use this pattern in Restlet, but I wonder if anyone has another solution. Maybe I'm just really missing something obvious! -Tal
Re: Resource factories
I tried to solve this problem in a limited way, using Guice, and wrote about it here: http://tembrel.blogspot.com/2008/07/resource-dependency-injection-in.html Maybe some of this could adapted for your purposes. --tim On Fri, Mar 20, 2009 at 10:03 PM, Tal Liron tal.li...@threecrickets.comwrote: Hey Restleters, Sorry if this question has been answered before -- I'm rather new to the community, even though I've been a heavy Restlet user for a while. I understand and agree with abstract class design used by Restlet, as is detailed by the wiki: http://wiki.restlet.org/developers/179-restlet/198-restlet.html However, I wonder if this has been taken too far, as regards the Finder class. Finder uses nothing but the Java class itself, and creates instances dynamically using newInstance(). But how do we inject initialization information to these instances? One idea, following the abstract class design, can be to inherit these classes and use different ones for different purposes. However, I've come across a situation in which this is problematic. Specifically, I want to have several Application instances running on the same component. These instances all use the same set of classes inherited from Resource. In many cases this works fine, but in some cases I want these classes to work slightly different per application. Specifically, there is shared information used by instances that I store as static field within the class. The problem is that both applications share the same static scope. Using the factory design pattern, I would have a problem -- factories can be used to create instances as I please. I understand the reluctance to use this pattern in Restlet, but I wonder if anyone has another solution. Maybe I'm just really missing something obvious! -Tal -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1369577
