Re: [Springframework-developer] Web app and Log4J initialization

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

Hi Juergen,

Last time I looked the Sun One AS 7 was only available for Windows and Solaris, which rules me out (Linux). I just had a look again, and they now support RedHat 7.2, which is really old (it's at 9 now).
I'm sort of in favor of JRun4 for the demo because it is a lot more user friendly than JBoss and has better docs. And there is a service pack for version 4, which hopefully solved most of the bugs.

Isabelle

On Fri, May 23, 2003 at 02:50:41PM +0200, jürgen höller [werk3AT] wrote:
> There's an issue with Orion (up to 2.0.1), regarding web app startup: In contrast to most other servlet containers (including Tomcat 4.x, Resin, Jetty), Orion starts load-on-startup Servlets BEFORE invoking ServletContextListeners. This means that combining startup listeners with load-on-startup servlets can be problematic on Orion, if the latter depend on initialization performed by the listeners.
> 
> With Spring, this can occur when using both ContextLoaderListener and load-on-startup ControllerServlets. For Orion, the load-on-startup must be removed from the servlet descriptors, triggering servlet initialization on first request. Or you'll write a custom bootstrap servlet with a lower load-on-startup number than the ControllerServlets, invoking com.interface21.web.context.ContextLoader.initContext(ServletContext), and maybe other things that your app would normally do in a listener.
> 
> Admittedly, the Servlet 2.3 spec didn't specify whether listeners or load-on-startup servlets should be initialized first. But the Servlet 2.4 spec demands that listeners get invoked before servlets, so containers like Orion that do in the other way round need to change their behavior anyway. I've already filed an Orion bug report for it. Does anyone know of other containers that behave like Orion?
> 
> BTW, Orion's JSP engine has a quite extreme bug: It doesn't correctly export variables from custom tags. This means that our bind tag does not work, as it exports a status variable. I've already filed a bug report some time ago, but haven't got any feedback.
> 
> All things considered, I guess we shouldn't adopt Orion as our default "full" J2EE platform. For 1-database web apps, Tomcat 4 or Resin are perfectly sufficient anyway. But what about >1-database apps that need JTA, or apps leveraging JMS, JCA, or EJB?
> 
> - For the JTA case: Tomcat/Tyrex, Resin, or WebLogic Express Basic may do the job, WebLogic Express Premium even including WebLogic's full transaction recovery.
> 
> - But for JMS/JCA/EJB: Is JBoss back on the list again? Or Sun ONE AS 7, providing all 3 already in the free Platform Edition? Or JRun 4, free for development?
> 
> In any case, I'm not keen on having to stick to heavyweights like WebLogic or WebSphere. Unfortunately, I've experienced JRun 4 to be rather buggy, at least its initial release. I don't like internal NullPointerExceptions on deployment :-( So, has anyone tried Sun ONE AS 7?
> 
> Juergen
> 
> 
> -----Original Message-----
> From: jürgen höller [werk3AT] 
> Sent: Friday, May 16, 2003 2:58 PM
> To: spr...@li...
> Subject: [Springframework-developer] Web app and Log4J initialization
> 
> 
> Isabelle, Ken, everybody,
> 
> On the occasion, some examples for initializing a Spring web app, especially regarding Log4J.
> 
> 
> 1. Log4J for usage within a web app
> 
> In web.xml, add the following to activate Log4j with a config file location relative to the web app root, by default refreshing the config file every minute (also recognizes a context-param "log4jRefreshInterval", and assumes an XML file in case of a ".xml" extension):
> 
> 	<context-param>
> 		<param-name>webAppRootKey</param-name>
> 		<param-value>example.root</param-value>
> 	</context-param>
> 
> 	<context-param>
> 		<param-name>log4jConfigLocation</param-name>
> 		<param-value>WEB-INF/log4j.xml</param-value>
> 	</context-param>
> 
> 	<listener>
> 		<listener-class>com.interface21.web.util.Log4jConfigListener</listener-class>
> 	</listener>
> 
> In log4j.properties, the system property with the specified "webAppRootKey" can be used as follows:
> 
> 	log4j.appender.examplefile=org.apache.log4j.FileAppender
> 	log4j.appender.examplefile.File=${example.root}/WEB-INF/example.log
> 
> If you don't need a refresh check and use the default config location anyway (i.e. "WEB-INF\classes\log4j.properties"), you can omit the "log4jConfigLocation" param. Log4J performs its default initialization then, still recognizing the system property. Just to achieve the latter, WebAppRootListener would be enough, but Log4jConfigListener is fine in this case too (see respective javadoc). 
> 
> If you'd like to use absolute log file paths anyway, you can omit the "webAppRootKey" param. You can also omit it and use the default "webapp.root" key in your log4j.properties - if running in an appropriate container like Resin that isolates system properties per web app. With containers like Tomcat that no not separate each web app's system properties, you'll need to specify a unique key per web app to avoid clashes.
> 
> BTW, Log4J's ${key} simply looks for a system property named "key". So if you like to use the webAppRootKey mechanism but also support a test environment with the same Log4J config file, simply call Log4jConfigurer.setWorkingDirectorySystemProperty(<key>) to set the specified system property to the current working directory.
> 
> Note: The order of the listeners is important, to initialize Log4J before any Spring activity.
> 
> 
> 2. Loading Spring application contexts
> 
> The following illustrates a typical setup in web.xml:
> 
> 	<context-param>
> 		<param-name>contextConfigLocation</param-name>
> 		<param-value>WEB-INF/myContext.xml</param-value>
> 	</context-param>
> 
> 	<listener>
> 		<listener-class>com.interface21.web.context.ContextLoaderListener</listener-class>
> 	</listener>
> 
> 	<servlet>
> 		<servlet-name>example</servlet-name>
> 		<servlet-class>com.interface21.web.servlet.ControllerServlet</servlet-class>
>   		<load-on-startup>1</load-on-startup>
> 	</servlet>
> 
> If you'd like to use a root application context, register the ContextLoaderListener. If you do not, you will simply have no root application context but just servlet-specific ones without parent. If you'd like to use the default root context location (i.e. "/WEB-INF/applicationContext.xml") anyway, you can omit the "contextConfigLocation" param.
> 
> A FrameworkServlet resp. ControllerServlet looks up its namespaced context at "/WEB-INF/<servlet-name>-servlet.xml" by default. This can be customized via "contextConfigLocationPrefix" and "customConfigLocationSuffix" context-params, e.g. prefix "/WEB-INF/servlets/", suffix ".xml" -> "/WEB-INF/servlets/<servlet-name>-servlet.xml" (see XmlWebApplicationContext javadoc). The "<servlet-name>-servlet" namespace can be customized too, but at the FrameworkServlet level: It can be overridden by a "namespace" init-param.
> 
> Context implementation classes can also be customized, if desired. For the root context, this can be achieved via a "contextClass" context-param (see ContextLoader javadoc). A FrameworkServlet resp. ControllerServlet offers a "contextClass" init-param. Note that for the latter, the context implementation needs an (ApplicationContext, String) constructor, for the parent and the namespace (see FrameworkServlet javadoc).
> 
> 
> 3. Keep it simple
> 
> Let's review necessary settings:
> - A Spring web app doesn't need any context-params or listeners at all, if just using a FrameworkServlet resp. ControllerServlet with its own context.
> - If you want a root application context, register ContextLoaderListener.
> - If you'd like to specify a custom context config location, or FrameworkServlet namespace or prefix or suffix, add the respective context-param.
> - For the web app root system property (e.g. in your Log4J config), register WebAppRootListener or Log4jConfigListener, and specify the "webAppRootKey" context-param in a non-isolating container.
> - For custom Log4J initialization, register Log4jConfigListener and add respective context-params.
> 
> So please, let's not use context-params if not needed, i.e. if using the defaults anyway. This avoids cluttering web.xml.
> 
> Finally an important note: I've removed both Log4jConfigServlet and ContextLoaderServlet, as we require Servlet 2.3 and should thus use Log4jConfigListener resp. ContextLoaderListener in any case. You'll have to adapt your config files if you've still used those initialization servlets up to now, but I consider it important to clean this before a proper release: 1 way for 1 thing to achieve. Sorry for any inconvenience - in case of severe impacts regarding context loading, write your own initialization servlet, overriding init() with a ContextLoader.initContext(ServletContext) call.
> 
> 
> Regards,
> Juergen
> 
> 
> -------------------------------------------------------
> Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
> The only event dedicated to issues related to Linux enterprise solutions
> www.enterpriselinuxforum.com
> 
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: ObjectStore.
> If flattening out C++ or Java code to make your application fit in a
> relational database is painful, don't do it! Check out ObjectStore.
> Now part of Progress Software. http://www.objectstore.net/sourceforge
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
> 
> 

-- 
Isabelle Muszynski
Software Engineer
Zandweellaan 4
2660 Antwerpen
Belgium
Tel. 32-(0)3-830 18 54
Mobile: 32-(0)485 49 50 89
Email: isa...@me...
Website: www.meta-logix.com