1. jax-rs-spec
  2. JAX_RS_SPEC-451

Specification must clarify sequence of invocations for configure() and getProperties().


    • Type: Improvement Improvement
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 2.0
    • Fix Version/s: 2.1
    • Component/s: spec
    • Labels:


      Since JAX-RS 2.0 there is an API for sharing configuration properties among all registered features. The application and all features have the possibility to query and modify a shared set of properties, hence allowing an application to modify the behaviour of features, also allowing features to modify the behaviour of other features.

      One problem which arises is the sequence when an application / any features are asked to modify the configuration. For example, an application A defines two features F1 and F2. F1 and F2 are provided by different vendors and don't know about the existence of each other, but solely know a shared property name. The application wants to modify the behaviour of F1. F1 wants in turn to modify the behaviour of the "unknown" F2 by setting a property. Hence, to make this example work, there must be some guarantee that A.getProperties() is invoked first, second must be F1.configure(), and F2.configure() must be last.

      Currently the JAX-RS 2.0 specification, neither the PDF nor the JavaDocs, say anything about this sequence. In fact, it took even up to Jersey 2.7 to make the RI at least guarantee A comes before any F, but still Jersey 2.7 calls F1 and F2 in an apparently random sequence. So it currently is possible in Jersey to have A modify F1, but it is a vabanque play whether F1 will be able to modify the behaviour of an "unknown" F2.

      BTW, this is a real-world example. F1 is a Feature, and F2 is an extention provided to F1. So while F2 knows F1 for sure, F1 does not know about the existence of F2. So this is not an academic discussion, it is a real problem.

      Hence it is necessary that JAX-RS 2.1 defines (A) that A.getProperties() must be called before any F.configure() is called, and (B) that there must be a way to explicitly declare the sequence in which F1.configure() / F2.configure() is called (e. g. by using @Priority).


        There are no comments yet on this issue.


          • Assignee:
          • Votes:
            0 Vote for this issue
            0 Start watching this issue


            • Created: