Thierry,
This reminds me of a question I've been meaning to ask.
I've been using a hand-rolled utility method to replace "standard"
converters with my custom extensions, e.g., JacksonConverter with
LocalJacksonConverter:
public static void replaceConverter(
Class<? extends ConverterHelper> converterClass,
ConverterHelper newConverter) {
ConverterHelper oldConverter = null;
List<ConverterHelper> converters =
Engine.getInstance().getRegisteredConverters();
for (ConverterHelper converter : converters) {
if (converter.getClass().equals(converterClass)) {
converters.remove(converter);
oldConverter = converter;
break;
}
}
}
Is that the preferred way to do it, or is it better to add without
replacement but provide scoring that dominates the "standard" version? If
so, shouldn't the scoring be part of the public documentation of each
ConverterHelper?
--tim
On Sun, May 29, 2011 at 12:02 PM, Thierry Boileau <
[email protected]> wrote:
> Hello Ishaak,
>
> that's a good question.
> The types of representations exchanged between the client and the server
> are negociated according to headers specified by the request.
> Let's have a quick dive into HTTP. When a client want a specific kind of
> representation, it completes the "accept" header with the corresponding
> media type (actually, this is a list of preferences, each of them having a
> weight, 1 by default).
> For example, the client want a json representations : it generates a
> "accept: application/json" header in the HTTP request.
> Now, let's go back to Restlet.
> They are several ways to send a GET request with media-type preferences:
> - using a clientResource, just call the ClientResource#get(MediaType)
> method.
> - using a basic Client, set a Request and updates the clientInfo attribute
> : Request#getClientInfo#getAcceptedMediaTypes#add(new
> Preference<MediaType>(mediaType.application_json)) (for example).
> - when wrapping Restlet-annotated interfaces, the list of preferences is,
> by default, generated according to the list of converters available on the
> classpath (see ConverterHelper#getVariant(Class)).
> - using a clientResource, just call the ClientResource#get(class) method,
> the list of preferences is also generated according to the list of
> converters available on the classpath. That explains the magic of the sample
> code.
>
> On server side, the negotiation is also based on the list of converters,
> plus the client's preferences, plus the methods of the target ServerResource
> (ie the return type and the annotation).
>
> I guess you have defined a sample MediaType?
>
> Best regards,
> Thierry Boileau
>
>
>
>
> Thanks Thierry!
>>
>> Got a follow up question now though. I was looking at documentation at
>> http://wiki.restlet.org/docs_2.0/13-restlet/28-restlet/299-restlet.html,
>> trying to figure out how to ensure that my protobuf based
>> converter/representation is used by my Client/ServerResource classes.
>> However, am a bit confused by the example there on that wiki page - neither
>> the client nor the server code makes any references to Jackson - how does
>> restlet know to use the Jackson implementation? Or, what I'm more interested
>> in is, how do I do the equivalent for my protobuf implementation?
>>
>> Ishaaq
>>
>> > Hello Ishaaq,
>> >
>> > this maven artefact is actually the google protobuf library. It is used
>> by
>> > the sdc extension.
>> > If you want to implement an extension that provides conversion to and
>> from
>> > protobuf protocol, you can have a look at the jackson extension. You
>> should
>> > have to implement only two classes : a protobuf converter and a protobuf
>> > representation.
>> >
>> > Bes tregards,
>> > Thierry Boileau
>> >
>>
>> ------------------------------------------------------
>>
>> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2750452
>>
>
>
------------------------------------------------------
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2752300
