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

[jsr339-experts] Re: A Feature interface

From: Marek Potociar <marek.potociar_at_oracle.com>
Date: Tue, 28 Jun 2011 20:17:07 +0200

Hi Bill,
I gave it a second thought and I think it may be worth exploring the Feature concept more.

Can you please try to look at the Feature concept in more detail and come up with a more complete proposal for
- what the interface should look like,
- what are the use cases it should cover,
- how is it supposed to be used,
- how does it fit into the bigger picture (e.g. can/should we reuse the features on the server side) etc.?

I don't expect a long elaborated document. Just a short description of the covered use cases, a documented draft of the
Feature API and a short description of how it should work internally would do the trick.

Let me know if it works for you.

Thanks,
Marek

On 06/09/2011 09:49 PM, Bill Burke wrote:
>
>
> On 6/9/11 12:12 PM, Santiago Pericas-Geertsen wrote:
>>
>> On Jun 8, 2011, at 9:52 AM, Bill Burke wrote:
>>
>>>> Is this something we can specify in the javadoc for Invocation.getProperties() and BaseContext.getProperties()?
>>>>
>>>
>>> Yes. But also I'd like to brainstorm a little bit more about this.
>>>
>>>
>>> For example, maybe this is yet another way to bind an interceptor. An interceptor could get a callback with a
>>> properties map and decide whether or not to apply itself.
>>
>> What if we change the DynamicBinding interface as follows:
>>
>> public interface DynamicBinding<T extends BaseContext> {
>> public boolean isBound(T ctx);
>> }
>>
>> That'll give access to everything in the context. Incidentally, why did you use AccessibleObject as the return type
>> of getAppliedTarget() in your original proposal?
>>
>
> I was thinking of something more that was a boot/deployment/init time thing.
>
> public interface Feature {
>
> void bind(Client client);
> void bind(Client client, BaseContext ctx);
> void bindServer(BaseContext ctx);
> }
>
> Or have 2 separete interfaces:
>
> public interface ClientFeature {...}
>
> public interface ServerFeature {...}
>
> Maybre that makes more sense and would allow us to separate client and server easier if we ever wanted JAX-RS client to
> be in JDK.
>
> It would then look like:
>
> clientConfigurate.getClasses().add(MyFeature.class);
>
> or Application.getClasses() would return a MyFeature.class.
>
>
> BTW, I noticed that Client doesn't have an registerClass() registerSingleton(). I think this is something that would
> need to be added.
>
>