On Nov 14, 2008, at 3:08 AM, Craig McClanahan wrote:
> Jakub Podlesak wrote:
>>
>> On Thu, Nov 13, 2008 at 10:16:14AM -0800, Craig McClanahan wrote:
>>
>>> Paul Sandoz wrote:
>>>
>>>> On Nov 12, 2008, at 11:15 PM, Jeremy Whitlock wrote:
>>>>
>>>>
>>>>> And finally, what I'm proposing is a configurable way to handle
>>>>> these
>>>>> situations.
>>>>>
>>>> Agreed. You might also be interested in a blog here [2] on
>>>> configuration.
>>>> I am wondering if the JSON mapped configuration suits your needs
>>>> more.
>>>> From the feedback we have got most developers don't appear to
>>>> like the
>>>> mapped convention and prefer a more concise convention that is
>>>> easier to
>>>> consume by the JavaScript client.
>>>>
>>>>
>>> For the actual mechanics of configuration, I had a similar need
>>> for easy
>>> customizability in jersey-multipart, and ended up with a class
>>> that loaded
>>> a properties resource from the classpath (if it existed, or used
>>> default
>>> values otherwise), and then provided the mechanism to inject the
>>> configuration bean into your providers, resources, and so on.
>>>
>>> The mechanism here could be generalized to support arbitrary
>>> properties on
>>> a configuration bean (using Java's reflection APIs). I'm going to
>>> take a
>>> crack at that and see if we can provide a general facility for easy
>>> application configuration for various services within Jersey.
>>>
>> Interesting idea. Then we could probably get rid of JAXBContext
>> resolver as the only mean
>> of JSON format configuration (since there is the possibility to
>> inject
>> custom Marshaller, this is needed anyway).
>>
>> On the other hand, configuring JSON format only via a general
>> config file
>> would mean, all beans will be configured the same way (all root
>> elems stripped off,
>> without exceptions, etc.)
>> To me it makes sense: one application, unified JSON notation,
>> but for some people it could be limiting.
>> For those we can keep the JAXBContext configuration style in place
>> (also for
>> backward compatibility reasons).
It may be possible to reuse the config class programmatically with
JSONJAXBContext from within a ContextResolver, and thus overriding the
application-wide settings. Perhaps it may be possible to have property
names scoped to the JAXB class names?
I suspect things will be a little clearer when we have the JAXB/JSON
improvements fully integrated.
Paul.