[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [jersey-dev] user guide's chapter-10 MISTAKES
|
In most questions, it seems you are (at least partially) questioning the
JAX-RS specification, so in that cases you can ask on the JAX-RS mailing
list, too. I try to answer inline.
Thanks,
Jan
On 22.01.2019 19:48, rawand takna wrote:
okay, then here is my feedback notes after studying chapter 10 of the
user's guide.
1- quoting from users guide:
"every interceptor must call the proceed() method otherwise the entity
would not be written"
if the *context.proceed()* method must be called by each interceptor,
shouldn't it be called internally by *jersey*.
the code that calls the method*aroundWriteTo()* method, can simply
call context.proceed() method after that invocation.
I would say no. For instance, as long as the JAX-RS Specification define
the context.proceed(), if you move a JAX-RS application over from
non-Jersey implementation where you would need to call context.proceed()
to Jersey, context.proceed() would be invoked twice, once by the app,
once by Jersey.
2- shouldn't *zipping *and *unzipping *be automatically done by
jersey, instead of letting developers define their own Interceptors to
compress and decompress entity body, it will be much easier for them
to have *built-in* ready to use interceptors that make the task easier
to them.
I would say no. Depending on the client and use case, you may or may not
want to zip/unzip the content. You may even want to use a different
algorithm than what is used in GZipInput/OutputStream. In my opinion, as
long as HTTP protocol is not automatically zipped/unzipped, a REST
framework should not do it automatically as well.
3- name-bound filter or interceptors:
the current procedure for defining name-bound filters or interceptors is:
1- define a *custom *annotation
2- annotate the annotation with *@NameBinding*
3- annotate the *filter *with the custom-defined annotation
4- annotate any resource method(s) that the filter or interceptor must
be applied on.
wouldn't it be easier to *apply filters or interceptors* to resource
methods using only *existing annotations* (without defining additional
ones)
something like:
@GET
@Path("too-much-data")
*@Filter(GZIPWriterInterceptor.class)*
public String getVeryLongString() {
String str = ... // very long string
return str;
}
this would eliminate the first 3 steps defined above.
On the other hand, you can have multiple interceptors annotated by a
single annotation. The GZip Interceptor, entity logging interceptor,
statistics monitoring interceptor, whatever. All these work by just
annotating the method with the single annotation annotating the
interceptors. In your case, you would need to annotate the method by as
many @Filter annotations as how many filters you would like to group.
And that's multiplied by the number of methods you want to
annotate/intercept. I don't feel like comparing advantages of one
approach over the other, but Jersey took the JAX-RS way, using
@NameBinding, which works with any JAX-RS implementation.
hope this helps to make *jersey *a better product.
Regards,
Rawand
On Tue, Jan 22, 2019 at 8:38 PM Jan Supol <jan.supol@xxxxxxxxxx
<mailto:jan.supol@xxxxxxxxxx>> wrote:
Sure, Jersey team always encouraged users to write what they think
about
Jersey.
-- Jan
On 22.01.2019 18:14, rawand takna wrote:
> Thank you for your response.
> I appreciate your detailed explanation of my concerns.
>
> also, do you accept feedback in the mailing list?
>
_______________________________________________
jersey-dev mailing list
jersey-dev@xxxxxxxxxxx <mailto:jersey-dev@xxxxxxxxxxx>
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jersey-dev
_______________________________________________
jersey-dev mailing list
jersey-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jersey-dev