Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Works as designed
    • Affects Version/s: 2.0
    • Fix Version/s: 2.0
    • Component/s: filters&handlers
    • Labels:
      None

      Description

      The javadoc for DynamicFeature currently states:

      * Dynamic feature is used by JAX-RS runtime to register providers that shall be applied
       * to a particular resource class and method and overrides any annotation-based binding
       * definitions defined on any registered resource filter or interceptor instance.
      

      DynamicFeature should not override any name bindings as both forms of per-method bindings need to coexist. Why? Well,
      for many method-bound filters, you need access to the annotations of that method. For example, a response filter that sets the
      max age for a Cache-Control header based on an annotation value. For @NameBindings, this annotation value is not available so the user is forced to write a DynamicFeature. BTW, this is why I question the value of @NameBinding.

        Activity

        Hide
        patriot1burke added a comment -

        Let me rephrase this because my initial description is inaccurate:

        If your annotation has a qualifier, then @NameBinding really isn't a very efficient pattern to implement a filter or interceptor. For example, let's say you had a @MaxAge annotation that triggered adding a Cache-Control header with a qualified max-age :

        @MaxAge(100)
        @Authenticated
        @GET
        public String get() {...}
        

        The @NameBinding filter would have to inject ResourceInfo and look up the @MaxAge annotation each and ever request to set the value. It is much better to implement a DynamicFeature in this case so you can pre-initialize the filter with the annotation's value. Notice also that the example has the same @NameBinding example @Authenticated example as the spec. So, in summary, I can see people wanting to mix both Dynamicfeatures and NameBindings in the same deployment for the same JAX-RS Method. It shouldn't be an either/or choice.

        Show
        patriot1burke added a comment - Let me rephrase this because my initial description is inaccurate: If your annotation has a qualifier, then @NameBinding really isn't a very efficient pattern to implement a filter or interceptor. For example, let's say you had a @MaxAge annotation that triggered adding a Cache-Control header with a qualified max-age : @MaxAge(100) @Authenticated @GET public String get() {...} The @NameBinding filter would have to inject ResourceInfo and look up the @MaxAge annotation each and ever request to set the value. It is much better to implement a DynamicFeature in this case so you can pre-initialize the filter with the annotation's value. Notice also that the example has the same @NameBinding example @Authenticated example as the spec. So, in summary, I can see people wanting to mix both Dynamicfeatures and NameBindings in the same deployment for the same JAX-RS Method. It shouldn't be an either/or choice.
        Hide
        Marek Potociar added a comment -

        That's not what is meant. The "override" refers to a fact that a DynamicFeature MAY attach (otherwise) name-bound providers and these MUST be attached to a method even if a particular name-binding annotation is not present on a method. Of course, what you suggest should work. If you have a proposal for a javadoc that makes it more clear, let us know.

        Show
        Marek Potociar added a comment - That's not what is meant. The "override" refers to a fact that a DynamicFeature MAY attach (otherwise) name-bound providers and these MUST be attached to a method even if a particular name-binding annotation is not present on a method. Of course, what you suggest should work. If you have a proposal for a javadoc that makes it more clear, let us know.
        Hide
        Marek Potociar added a comment -

        Not hearing back from you, I'm closing the issue as resolved. If you still feel we should change the javadoc wording, let me know how.

        Show
        Marek Potociar added a comment - Not hearing back from you, I'm closing the issue as resolved. If you still feel we should change the javadoc wording, let me know how.
        Hide
        patriot1burke added a comment -

        Ah, ok...guess I misread the javadoc.

        Show
        patriot1burke added a comment - Ah, ok...guess I misread the javadoc.

          People

          • Assignee:
            Marek Potociar
            Reporter:
            patriot1burke
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: