On 06/28/2011 03:01 PM, Sergey Beryozkin wrote:
> Hi Bill
>>
>> On 6/27/11 8:22 AM, Marek Potociar wrote:
>>> The assumption was that we need to be able to control the features up to the invocation level. Here's a potential use
>>> case:
>>>
>>
>> Controlling features per request would rarely, if ever, be used, IMO.
>>
>>
> I agree. Applying features to individual clients (and thus have its 'descendants' if any inheriting it) and also
> possibly the client runtime thus affecting all clients is easier to deal with. At least this is how thing work in CXF -
> I'm not biased here, it just seems effective and straightforward
>
> thanks, Sergey
I guess we need to look at it from the perspective of supported use-cases and programming models.
If we accept the fact that client instance is certainly the one that is most expensive to create and bootstrap (scanning
for providers, initialization of injection, setting up thread pools, etc.), creating a new client every time one needs a
different configuration does not seem particularly effective.
Also, if we accept the fact that a single configuration may not necessarily be suitable for all the resources, it is
useful to provide an effective lightweight mechanism (resource link, invocation), where most of the bootstrapping and
initialization is reused from the client level and where the configuration is inherited, but it can be still further
customized to fit the communication needs of a particular resource or it's method.
At the same time, we should try to avoid the problematic "singleton initialization" design pattern we used in JAX-RS 1.x
when the RuntimeDelegate was introduced. Currently it is causing huge issues in the containers (JavaEE, OSGi) if
multiple applications in the container have different requirements on the API implementation vendor or version. That's
why we should try to keep all the bootstrapping and expensive initialization encapsulated in a client *instance* and
have those instances completely separated from one another.
Marek
>
>>> // All communication on this client is audited by default
>>> client.register(AuditingFilter.class);
>>>
>>
>> By class isn't good enough as the filter may be a singleton that is initialized.
>>
>>
>