Jean Aurambault wrote:
> Hi,
>
> 1) I read this article
> http://weblogs.java.net/blog/mhadley/archive/2007/09/new_jersey_feat.html
> about resource lifecycle.
> If I have well understood, we have the choice between to| PerRequest
> |and |Singleton|. The default value should be |PerRequest.|
> In my case the default behaviour seems to be singleton and if I put the
> PerRequest annotation there is no difference, the resource instantiation
> is not done per request. Do I miss something?
>
It should be per-request by default. The relevant unit tests are not
failing in this respect so it should be working.
Did you check if the constructor of the resource class gets called for
each request? Can you share some code and the configuration?
> 2) Another question, about Providers. I see in the examples that we can
> use the annotation @Provider instead of using the file META-INF/service
> in order to define our specific providers. I would like to now if there
> is a specification about the order of the providers in the provider
> list. I suppose that providers retreived using annotation are put before
> the ones defined in the META-INF/service to allow overloading of default
> providers.
Yes.
> It should be interessting to be able to define the order at
> least between providers added with annotation. Basicaly, I don't want to
> iterate the whole list of providers if I know that I will be likely to
> use the same one all the time (eg. application with 95% XML requests
> and 5% JSON requests). Maybe it doesn't have a big impact on performance
> ... but I was just wondering :-D
>
The order of the providers is specified by the ApplicationConfig
(ResourceConfig) implementation and the set of providers that are
returned by that. For the class scanning resource config implementations
provided by Jersey i presume the order would be the order of the classes
in the classpath (i am not sure that can be fully determined and is
consistent over VMs).
In this respect one does have to be careful not to register a greedy
provider (type == Object.class) for all media types (*/*).
The lookup is based on the media type (if present) and the Java type. If
you want to make things a little more efficient stick a @ProduceMime on
a writer and an @ConsumeMime on a reader.
IMHO as a developer you should not have to worry about the efficiency
:-) it is really up to the implementation to optimize. For example, an
implementation could cache the previously used reader/writer for a
resource method and check if it can use that one before doing a more
detailed search (Jersey does not do that... yet!).
> 3) Last question about Content-Length in httpHeader response.
>
> When I make a GET on a resource (200) the Content-Length is not set.
> When I make a HEAD on the same resource Content-Length is 0.
Yes, you have found a bug :-) Would you mind logging an issue?
> If I make a HEAD an resource which doesn't exist (404) Content-Length is
> 952. I have specific content for 404 with variable size. 952 is not the
> size of the returned content, because when the content changes
> Content-Length stays at 952.
>
Is that because the the Web container is handling the HEAD (and the GET)
? I suspect the Web container is returning some HTML as the 404 response.
> HEAD is supposed to return the Content-Length that a GET request would
> have returned. Doesn't it? Is jersey supposed to take in charge the
> Content-Length?
>
It should, when the content length is known upfront (e.g. for File or
for byte[]). For efficient Jersey will use chunked transfer encoding
when the content length is not known (and one would have to buffer to
determine it, e.g. for JAXB beans). In such cases a HEAD response should
return information consistent with the GET with an unknown content length.
Paul.
--
| ? + ? = To question
----------------\
Paul Sandoz
x38109
+33-4-76188109