[Springframework-developer] Polishing, HandlerMapping, Log4J support

[<jue...@we...>]

Hi everybody,

I've recently checked in some polishing and some adapted behavior:

---

- All location parameters and properties that allow both URLs and =
absolute and relative file paths are now named "location".

- The location lookup is implemented in AbstractApplicationContext, =
allowing subclasses to provide custom relative path behavior. Default is =
relative to the VM's execution directory. XmlWebApplicationContext =
interprets relative to the web app root directory, =
ClassPathXmlApplicationContext as class path resource. This allows for =
convenient setup of a live test suite, testing the middle tier of a web =
application.

- WebUtils does not provide a getResourceAsStream method anymore, as =
this is now addressed by the ApplicationContext implementation =
hierarchy. ApplicationContext.getResourceAsStream/getResourceBasePath =
should be used for all resource access that could potentially use =
relative location paths. Numerous classes within Spring use it, e.g. =
PropertyResourceConfigurer and VelocityConfigurer.

- Various "init" methods like in HandlerMapping and =
WebApplicationContextSupport are now called =
"initHandlerMapping"/"initApplicationContext"/etc, to express their =
special meaning and allow for different semantics in classes that =
implement both.

- I've reworked the web Controller implementation hierarchy, especially =
refining the visibility of various methods and adding lots of JavaDoc. =
FormController's onSubmit methods now feature ServletRequestDataBinder =
instead of DataBinder and name it "errors", to show that this is just a =
specific implementation of Errors. The trigger was an actual (even =
rather simple) requirement of one of our applications, BTW.

---

I've reworked the web HandlerMapping implementation hierarchy, providing =
an AbstractHandlerMapping and AbstractUrlHandlerMapping now to be able =
to reuse common code. The old UrlHandlerMapping concrete implementation =
is now called SimpleUrlHandlerMapping.

I've also changed the URL lookup behavior: previously simply =
request.getServletPath (inappropriately matching "/xxx" in case of =
"/xxx/*" servlet mappings!), now a more appropriate lookup path. If =
applicable, the path within the current servlet mapping (e.g. "/y.html" =
in case of a "/myapp/xxx/y.html" request and a "/myapp/xxx/*" servlet =
mapping, "/myapp" being the context path), else the full path within the =
current servlet context ("/xxx/y.html" in the example).=20

The alwaysUseFullPath property of the HandlerMapping implementation =
allows for enforcing full path lookup. Note that its default is "false", =
as using the path within the servlet mapping is assumably what the =
developer expects when mapping ".../*".

---

I've scrapped my previous Log4J initialization solution for web apps and =
replaced it with a new one, inspired by Barracuda and some convenience =
classes that I've found in the Log4J repository.

Now a system property is used instead of derived appenders. I consider =
this much cleaner, but it has the disadvantage that system properties =
are potentially shared by all web apps. That was previously my concern, =
but I've now discovered that some containers like Resin do indeed allow =
for separate system properties per web app.

The default system property key is "webapp.root" (literally, not the web =
app context path like in the Barracuda solution). It can be configured =
via a "webAppRootKey" context-param in web.xml, to allow for multiple =
web apps using this inside a container that does not support separation =
of system properties.

Example web.xml param:
  <context-param>
    <param-name>webAppRootKey</param-name>
    <param-value>demo.root</param-value>
  </context-param>

Example Log4J properties line:
  log4j.appender.demofile.File=3D${demo.root}/WEB-INF/demo.log

Of course, mapping the same web app twice (e.g. each configured to a =
different database) in a container like Tomcat requires changing the =
webAppRootKey context-param and adapting the key used in the Log4J =
config file. That's the only disadvantage, compared to the previous =
appender-deriving solution that used the web app class loader to enforce =
separation. Note that this isn't necessary when running in a container =
like Resin, you can even use the default key then without worrying.

com.interface21.web.util.WebAppRootListener just sets the respective =
system property, which would be enough for standard Log4J initialization =
or other usages of the property. =
com.interface21.web.util.Log4jConfigServlet sets the property implictly =
and allows for more sophisticated Log4J configuration (custom config =
file location, refresh interval).

com.interface21.util.Log4jConfigurer is a simple convenience class =
without state now, and there aren't any "RelativePathFileAppender" =
classes anymore.

---

Juergen


DI J=FCrgen H=F6ller
Senior System Architect
______________________________________

werk3ATS - division systementwicklung
part of werk3AT internetmedien oeg

europaplatz 4
A - 4020 linz

t.  +43 (0) 732 71 65 29 502
f.  +43 (0) 732 71 65 29 3
jue...@we...
www.werk3at.com
______________________________________
werk3ATS - WIR ENTWICKELN ERFOLG