A.c and B.c look reasonable to me too.
Thank you,
Martin Mulholland.
WebSphere Application Server Web Tier Architect
email: mmulholl_at_us.ibm.com
Mark Thomas <markt_at_apache.org> wrote on 04/12/2017 04:30:22 AM:
> From: Mark Thomas <markt_at_apache.org>
> To: jsr369-experts_at_servlet-spec.java.net
> Date: 04/12/2017 04:31 AM
> Subject: [servlet-spec users] [jsr369-experts] Re: Re: revised
> trailer proposals
>
> 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
>