Skip to main content

[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.



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:

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.


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

    -- 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

jersey-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit

Back to the top