commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Bourg <ebo...@micropole-univers.com>
Subject Re: [configuration] WebConfiguration
Date Tue, 02 Mar 2004 12:24:17 GMT
Good point I forgot this one. I wonder if I should keep everything in 
the same class or split the class into a ServletConfiguration, 
FilterConfiguration, AppletConfiguration, etc. The WebConfiguration 
could break in a servlet 2.2 environnement due to the lack of servlet 
filters, this may be an argument in favor of splitting the class.

Emmanuel Bourg


Paul Libbrecht wrote:

> That has ssome good taste... I would add an "applet-parameter"-based one 
> as well...
> 
> paul
> 
> 
> On 1-Mar-04, at 19:02 Uhr, Emmanuel Bourg wrote:
> 
>> Hi, I'd like to suggest a new configuration implementation that 
>> bridges between parameters commonly used in web applications (servlet, 
>> filter, application and request parameters) and our Configuration 
>> interface.
>>
>> Because I'm tired of writting always the same parsing code like:
>>
>> public void init(ServletConfig config) {
>>     try {
>>         param = Integer.parseInt(config.getInitParameter("param"));
>>     }
>>     catch (NumberFormatException e) { }
>> }
>>
>> I tought it would be much easier to write instead:
>>
>> public void init(ServletConfig config) {
>>     Configuration conf = new WebConfiguration(config);
>>     param = conf.getInt("param");
>> }
>>
>> The WebConfiguration works with 4 types of objets specified in its 
>> constructor: a ServletConfig, a ServletContext, a FilterConfig or a 
>> ServletRequest.
>>
>> I wrote a test case using mock objects covering the different cases 
>> except for the FilterConfig, the mock lacks a setInitParameter() 
>> method. Also the mock for the ServletRequest sends an exception for 
>> unknown parameters instead of returning null, most of its tests break.
>>
>> Emmanuel Bourg
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message