No objections.
From: Marek Potociar [mailto:marek.potociar_at_oracle.com]
Sent: Montag, 15. Oktober 2012 23:52
To: jsr339-experts_at_jax-rs-spec.java.net
Subject: [jsr339-experts] Re: [jax-rs-spec users] Please review: Feature,
Configurable API update proposal.
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/87d7e1ee01724344dc
99c78637071bf085b7a4ab
(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