On Dec 7, 2012, at 4:34 PM, Bill Burke <bburke_at_redhat.com> wrote:
> Looks good so far, but I'd need to implement it to give more detailed feedback. Just one question though. What value is there in having separate mutable/immutable read/write interfaces for Configurable/Configuration? Especially since every context in which they can be accessed is able to read and write configuration? I still think you should combine the concepts, but don't care that much if you don't.
I would like application-wide Configuration to be injectable on the server side, but I really do not like the mutable methods on such injectable interface. I think this way it's cleaner.
> BTW, I never liked the contracts stuff:
>
> public C register(Object component, Class<?>... contracts);
>
> It seemed like a really really rare use case that could be solved by refactoring code. Just seems like we're rewarding bad code practices. I don't care that much, just wanted to give my 2cents again.
That use case came up e.g. when we were implementing LoggingFilters. While most of the functionality seemed common and it made sense to implement all filter types in a single class, we were not able to narrow down scope of such class multi-provider class, when needed. FWIW, I do not consider our approach with logging filter to be a bad practice, but if more people in EG are convinced that we should not support it in the spec, we can still consider revisiting.
Marek
>
> On 12/7/2012 9:18 AM, Marek Potociar wrote:
>> Hello Experts,
>>
>> Based on experiences from implementing the config interfaces, I plan to
>> push the following changes of the JAX-RS configuration API components
>> into the origin master branch soon:
>> https://github.com/mpotociar/jax-rs/compare/config-api-take3
>>
>> Here's a summary of the changes, including the reasons:
>>
>> *Main problems:*
>>
>> * Custom contract priorities or partial contract registrations were
>> not visible via getters
>> * Mixing of immutable and mutable methods on two similar interfaces
>> * Client-side Configurable interface seemed to be commonly reusable
>> * Injected Configuration interface contained redundant setters
>> * The registration rules are not aligned well with JAX-RS Application
>> getters.
>>
>> *Proposed solution:*
>>
>> * Transform Configuration interface into a read-only encapsulation of
>> config state
>> * Add missing information about custom/partial registrations to the
>> Configuration interface
>> * Make Configurable interface common and write-mostly concept
>> * Expose Configuration via Configurable
>> * Simplify component registration rules and improve javadoc.
>>
>> *Steps taken:*
>>
>> * Configurable interface was moved from client to core package
>> * Removed all config getters from the Configurable interface
>> * Added a single new Configuration getter into Configurable interface
>> * Removed all mutable methods from Configuration interface
>> * Added missing getters to the Configuration interface
>> * Some methods renamed to be shorter
>> * Redesigned register(...) method to support full flexibility of
>> custom contract registration.
>> * Added a lot of clarifying API docs around configuration and
>> introduced fixed rules for overriding registrations:
>> o there can be only one (either class or instance-based)
>> registration per component type
>> o existing registrations cannot be overridden
>> + this is important for DynamicFeature not screwing up global
>> providers
>> * Updated examples
>>
>> Please, let me know if you have any other suggestions.
>>
>> Thank you,
>> Marek
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com