No comment on this? I think if you want to have things on the client
API like enableFeature/disableFeature we should also have an SPI that
allows to plug in features that are triggered by adding properties (or
annotations on the server).
On 6/9/11 3: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.
>
>
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com