On Nov 12, 2008, at 4:13 AM, Craig McClanahan wrote:
> 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?"
OK.
>
>
>> 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.
OK. We have another area of configuration for WADL generation. I
argued for a Java class and builder pattern rather than a more complex
String-based syntax as an initialization parameter. But maybe a
properties file would work well in this respect. But, i have no time
to look more closely at this. So we also need to wait until something
more pressing occurs i think.
Paul.