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).
>
> Craig, do you have any idea, how your general config facility
> would look like?
>
At the moment, I've been playing with an idea that Paul raised when I
created the MultiPartConfig class in jersey-multipart. In the current
code, this class is hard coded to read config properties (for this
application) from a properties resource in the classpath -- or provide
default values if there is no such resource. Also, a Provider is
supplied so you can inject this bean anywhere it's needed. In my case,
it was into the MessageBodyReader that parses multipart/mixed messages
... it needed to know how big to allow a body part to be before being
buffered to disk. The set of properties supported by this parsing,
though, is currently fixed.
If I had a general facility, I would code my config bean something like
this:
public class MultiPartConfig extends BeanProperties {
public MultiPartConfig() {
super("multipart-config.properties");
}
private int bufferThreshold = 4096; // Default value
public int getBufferThreshold() { return bufferThreshold; }
}
and the base class constructor would use reflection to match up property
keys to my fields (only bufferThreshold in this case, but could be any
number of them), perform the String->int conversion, and let me not have
to worry about the low level details. Any other Jersey facility that
needed its own configuration bean could do the same sort of thing.
Currently, I've got a base BeanProperties class like this written, but
am running into a couple of issues:
* Injecting into a private field throws IllegalAccessError for me.
At the moment I'm working around this by declaring it protected
instead, but there's got to be some magic trick to accessing a private.
* When debugging, it appears that the constructor of the subclass
runs *before* the instance variable initialization expressions do,
so anything I set from the properties gets replaced by the default
init value. Haven't worked around this one yet.
Craig
> ~Jakub
>
>
>>> Paul.
>>>
>>>
>> Craig
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>
>