On Feb 20, 2013, at 4:04 PM, Bill Burke <bburke_at_redhat.com> wrote:
>
>
> On 2/20/2013 8:37 AM, Marek Potociar wrote:
>>
>> On Feb 19, 2013, at 3:12 PM, Bill Burke <bburke_at_redhat.com> wrote:
>>
>>>
>>>
>>> On 2/19/2013 8:48 AM, Marek Potociar wrote:
>>>>
>>>> On Feb 19, 2013, at 2:39 PM, Bill Burke <bburke_at_redhat.com
>>>> <mailto:bburke_at_redhat.com>> wrote:
>>>>
>>>>> I'm writing a sub-chapter on component registration and came across a
>>>>> problem. Is there any way of leveraging scanning so we can build a
>>>>> Client from scanned components? Would this work server side?
>>>>>
>>>>> @Context Configurable configurable;
>>>>
>>>> Should the above be Configuration? Configuration can be injected into
>>>> server side components (providers/resources).
>>>>
>>>
>>> Can you inject Configurable as well? Just wondering...
>>
>> No, why would you want that? Once app is deployed config should not be mutable. Mutability would open the whole can of worms.
>>
>
> To add filters and interceptors with a specific priority.
Feature and DynamicFeature are here for that use case.
>
>
>>>
>>>>> @Context ClientBuilder builder;
>>>>
>>>> I was hoping we have closed the client component injection topic with
>>>> removal of @Uri for the time being.
>>>>
>>>
>>> That's fine, but, FWIW this is much different. Injecting a ClientBuilder would require no special configuration and the container could just initialize the builder with configured components (scanned or via Application). This is quite unlike @Uri which would often require outside external configuration of the underlying Client.
>>
>> Now that @Uri has been dropped I'm strongly inclined to defer the whole server-side client component injection discussion. I do not want a half-baked last moment solution sneak into API.
>>
>
> No problem on deferring. I just don't think ClientBuilder injection is half baked though.
Ok.
Marek
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com