jsr339-experts@jax-rs-spec.java.net

[jsr339-experts] Re: [jax-rs-spec users] Please review: Feature, Configurable API update proposal.

From: Marek Potociar <marek.potociar_at_oracle.com>
Date: Mon, 15 Oct 2012 23:52:21 +0200

Ping...

Unless there are any objections, I'd like to promote the proposal to an official change and start implementing it.

Thanks,
Marek

On Oct 11, 2012, at 10:54 PM, Marek Potociar <marek.potociar_at_oracle.com> wrote:

> Hello Experts,
>
> I would like to propose a following update to the Configurable API:
> http://java.net/projects/jax-rs-spec/sources/git/revision/87d7e1ee01724344dc99c78637071bf085b7a4ab
>
> (Note: while it's in the Git, it is a proposal, not a given thing. Feel free to discuss or raise objections. If we have to, we'll remove it. I just figured it is much simpler to do it this way even though I'm aware that there have been some reservations to the approach in the past.)
>
> To sum up, I have tried to clarify and expand the Feature and Configuration API javadoc based on the feedback from our RI implementation team members. The main issue I tried to address is when and in what order should the features be configured by the runtime. The original javadoc seemed to suggest that the features have to be configured directly in the register method. The goal of the proposal is to give implementations more freedom in postponing the feature configuration processing to any later more convenient time. This is especially important when configuring client-side components.
>
> With that, I am also proposing a slight change in the Configurable API:
>
> - Renaming getFeatures() to getEnabledFeatures() method in order to better indicate the actual data provided by the getter. Additionally, I'm proposing to relax the requirements on when the data provided by the method should become available (during feature processing) and complete (after all features are processed).
>
> - Adding new getFeatureClasses() and getFeatureInstances() methods. These methods seemed to be missing in terms of users not being able to query the API which features have already been registered. Also, it seems to me that it makes a lot of sense to keep the methods separated from the similar existing provider-specific methods due to the special role Features play in the configuration API.
>
> Please review the proposal and let me know your feedback.
>
> Thanks,
> Marek