On 4/30/12 11:05 AM, Martin Matula wrote:
> Hi Bill,
>
> On 4/30/12 4:30 PM, Bill Burke wrote:
>>> 2) readEntity() should make an implicit call to bufferEntity() before it
>>> does anything. This is just for filters! Not for reading in the resource
>>> method or the client.
>>
>> Just a thought..Maybe it shouldn't be implicit? Maybe the filter is
>> reading the entity, then replacing it with writeEntity(), so a buffer
>> is overkill? Or maybe its just better to protect the filter developer
>> from himself? I don't know...
>
> OK, not implicitly buffering may provide more flexibility. On the other
> hand one poorly written filter can break everybody else. Not sure what's
> better. I don't have a strong opinion on this one.
>
>>
>>> 3) maybe - remove get/setEntityStream() from filters (could not find a
>>> use-case that could not be covered by interceptors or a combination of
>>> an interceptor and a filter that triggers the interception by calling
>>> bufferEntity()). Or maybe we want to keep it to be safe. Which leaves us
>>> with just the two things above.
>>>
>>> Here is the rationale:
>>>
>>> - on the receiving end, you want "decoding" interceptors to work based
>>> on the headers, not based on the annotation - i.e. if the entity in the
>>> incoming message is zipped, it is not the resource method that tells me
>>> it is, it is the sender who should tell me - by the way of the headers.
>>> So, typically no annotations processing should be needed to make the
>>> stream usable for other consumers. At least I think I would never add a
>>> feature that would not have this kind of characteristics.
>>>
>>
>> hashes or signatures?
>
> Shouldn't the hashes/signatures be verified based on headers then? I.e.
> if the sender sends a hash/signature, don't you always want to verify?
Verification is expensive. Because you have to:
a) recreate the hash
b) encrypt the hash
c) compare
So, I would say, no, you don't always want to verify.
> And only use the annotation for enforcement? That way your verification
> interceptor can be global and the enforcement would be name-bound. And
> things would work. Or do you need to read something from the annotations
> which is essential for the signature/hash computation?
>
Annotation could have the hashing algorithm specified. But usually the
information is contained in a header somewhere.
> Otherwise I don't know how to implement it cleanly - I guess you would
> have to buffer headers (if you want to buffer the original stream) as
> well, since after my gzip interceptor removes the encoding header and
> somebody later reads the original stream from the buffer, my gzip
> interceptor will no longer know it has to decode - unless it gets the
> buffered original headers as well, no? The "mark" in the property bag
> would not be enough in this case, as the interceptor does not know when
> it works with the original stream as opposed to a new stream created as
> a result of writeEntity(). Seems to make things too complicated, no?
>
Why would a gzip interceptor remove the encoding header?
>> * If you call writeEntity() what should happen to headers? For
>> example, if the original wire bytes are gzip encoded and you call
>> writeEntity() what happens to the Content-Encoding header? In this
>> case, maybe we writeEntity() should have an additional headers parameter?
>>
>> public <T> void writeEntity(
>> final MultivalueMap<String, Object> newHeaders,
>> final GenericType<T> genericType,
>> final Annotation annotations[],
>> final MediaType mediaType,
>> final T entity);
>
> What would you pass to the header parameter?
> writeEntity triggers interceptors, based on the current headers, the
> gzip interceptor would either kick in or not, no?
>
Oh yeah, I guess it would. Good point.
> One more thing - should annotations[] be added to the client API
> somewhere (e.g. to the methods that work with entity or to the Entity
> class) to make name-bound interceptors reusable on the client side?
Yes. And it would also work well with our proxy framework :)
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com