On 12/04/17 02:21, Greg Wilkins wrote:
>
> On 12 April 2017 at 11:07, Greg Wilkins <gregw_at_webtide.com
> <mailto:gregw_at_webtide.com>> wrote:
>
> All,
>
> I'm a bit agnostic on the matter of Map<String,String> vs
> Map<String,List<String>> as regardless we will have to check strings
> for CSV anyway.
>
> I'm a bit cautious about the setTrailerCallback(Consumer<Map<String,
> String>> callback) API because there are insufficient details about
> when and who will call callback.accept(trailers)). If it is a
> true container callback, then it needs to be treated like the other
> container callbacks - context classloader set, mutually excluded
> from other callbacks etc.
>
> Alternately, we could say that it will only ever be called by the
> thread that calls HttpInput.read() and is about the return -1, but
> immediately prior to that will call accept?
That is how I was thinking of implementing it in an attempt to avoid /
reduce threading issues.
> Either way, I don't see much improvement on a method like
>
>
>
> Sorry pushed send too soon.
>
> Either way, I don't see much improvement on a method like:
>
>
> /**
> * @return A map of trailers or null if none are available.
> * @throws IllegalStateException if called before all request input
> has been consumed.
> */
> public Map<String,String> getTrailers();
>
>
> So my preference is A.c. If we are to go with A.e, then we need a lot
> more specification about how and when it is to be called. Eg. can a
> call to the setter immediately callback the accept within the scope of
> the call?
Fair point. I leant towards A.e rather than A.c for reasons of symmetry
between input and output but if that means a lot more specification then
A.c does look like the better choice.
> I'm also in favour of B.c, but again we need to be more specific about
> what thread will call that API. Specifically I believe that we should
> say that it is called within the scope of whatever thread/call causes
> the response content to be completed. Typically this will be any thread
> calling close() on the output stream or writer.
That seems reasonable to me.
Mark