Hello Marc, Paul and all,
as you assume, I was not member of users_at_jsr311... I thought, it was
only for the expert group members. I've joined the mailing list.
Sorry, that I didn't answered to some questions. (I also didn't get the
mail, that I should join, because I was not a member of the mailing list
... shit happens :-) )
I've just looked in the mailing list archive. Here are some answers, you
requested:
Marc, to your email of yesterday:
> Thanks for the patch. I've committed everything apart from the
> spaces preceding each \cite - I think I read somewhere that there
> shouldn't be a space but I could be wrong and want to look into
> that first.
That is a queston of optical appearance. I think, it looks better, if
there is the space.
As Paul answered, I could wrote a patch, I also changed it.
> > • If the @ProduceMime or the accepted media types should be
> > respected, than I propose to return a Map<String,
> > Collection<MediaType>> instead of Map<String, MediaType>. This is
> > useful (e.g. for XML ["text/xml" and "application/xml"] and also
> > for JavaScript files ["text/javascript" and "application/x-
> > javascript"]), if the bowser acceptes only one of this MediaTypes.
> > By design criteria a Set is the best, but I think it should be
> > possible to order them, so a List should also be possible. So
> > Collection is a flexibel solution.
>
> Are you suggesting we'd filter the list/set returned from the mapping
> config against the actual Accept header sent in the request ?
Yes, the runtime could filter this and change the preferances. But it's
also good, to leave this as specific add-on to the runtime environment
implementer.
> > Must a MessageBodyWriter/MessageBodyReader close the input / output
> > stream? The Jersey providers does, but it is not requested in the
> > specification or in the javadoc.
>
> Can you point to some code?
Sorry, you are right. It was the stream of the given File in the
FileProvider and the same on the InputStreamProvider.
best regards
Stephan