...
5. Valve interface has a event() method which is used to process a comet event. Filters need not to worry about whether it is a comet event or not. So how can we reflect this part in our new filter-based structure?
6. Do we really need to move the logic in StandardEngine StandardHost/StandardContextValve into some filters? Since the logic of these classes is purely servlet-engine concerned, I do not think those logic could be reused by filters. Any comments?
7. My solution now to load configuration in $CATALINA_BASE/conf/server.xml is to add a CallMapParamRule.class to collect the attribute-value pairs into a map, and this map is the initiation parameter of a filter. A method with signature – "addFilterWithConfig(Class<? extends Filter> filterClass, Map<String, String> paramMap)" will be added in StandardEngine/Host/Context to add new filters into it. The main content of CallMapParamRule is as blow:
| Wiki Markup |
|---|
public void begin(String namespace, String name, Attributes attributes)
throws Exception \{
for (int i = 0, count = attributes.getLength(); i < count; i++) \{
// here we do not deal with the className attribute, since it
// is used as the class name that will be initiated.
if("className".equalsIgnoreCase(attributes.getLocalName(i))) \{
continue;
\}
paramMap.put(attributes.getLocalName(i), attributes.getValue(i));
\}
digester.getLogger().debug(paramMap);
Object parameters\[\] = (Object\[\]) digester.peekParams();
parameters\[paramIndex\] = paramMap;
\} |
In order to add those newly added filters into the FilterChain, the ApplicationFilterFactory class also need to be altered.
Any comments about this solution? Or are there a better one?