Paul Sandoz wrote:
> Hi Craig,
>
> This is looking good, some comments on the code:
>
> 1) Perhaps it might be easier to re-use @Context rather than supply
> another annotation?
>
> 2) The InjectableProvider can do the following:
>
> - check if the value to inject is an instance of MultiPartConfig
>
> - create just one instance.
>
> so the code would be as follows:
>
> public Injectable< MultiPartConfig >
> getInjectable(ComponentContext ic, Context a, Type t) {
> if (MultiPartConfig.class != t)
> return null;
>
> try {
> final MultiPartConfig mpc = new MultiPartConfig();
> return new Injectable<MultiPartConfig>() {
> public Object getValue() {
> return mpc;
> }
> };
> } catch (IllegalArgumentException e) {
> // What should we do here, provide an instance with
> default values?
> }
> }
>
That's good advice -- I made the changes to reuse @Context. However,
I'm currently punting on the potential for an IllegalArgumentException,
which means it will likely ripple out to the application upon the first
request for a resource using this injection. It seems to me that this
will be sufficiently annoying to the developer that it'll get fixed,
instead of the potential for missing a single log message ("you messed
up your properties files, so we set all the config parameters to
defaults") and leaving him/her wondering "now why aren't my custom
configuration properties working?"
> I am wondering if this approach is worth generalizing using Java bean
> introspection?
>
> public class MultiPartConfig extends BeanProperties {
> MultiPartConfig() { super("jersey-multipart-config.properties"); }
> ...
> }
>
> Or indeed if there is something like this already?
>
That would certainly make sense if there were more than one use case.
I've written reflection code like that before (Commons BeanUtils), and
it would not be difficult. We can think about that when we run across
another need.
> Paul.
>
Craig