  | |  | NTEventLogAppender packaging | NTEventLogAppender packaging 2003-05-23 - By Brett Henderson
Back Thanks Ceki, you've obviously put a lot more thought into this than I have.
I haven't looked into all the details yet but I have a couple of questions. 1. Who sets the RepositorySelector interface? Is there an effective way of doing this if I have multiple versions of the same application running on a single app server? Is there any way of specifying a global log4j configuration at the app server level that would specify which repository selector to use and how each log repository is configured? 2. The above question leads to how is each LoggerRepository configured? Can I get it to automatically load a log4j.xml within each web application without running into ClassLoader problems? 3. Can I now package custom object renderers inside the web application? Will log4j now find them given that they are packaged at a lower level in the ClassLoader hierarchy. 4. Am I likely to run into problems when co-existing with other web applications?
Given that I have no support from the container, I'm concerned that the above approach may rely on other web applications playing fairly and using the same approach (no mandatory separation). I'd rather not make too many assumptions about the environment if it can be avoided.
While writing this email, I've thought of another approach that may solve my problems (very specific to my case).
1. Create a wrapper to log4j (already have this for various reasons). 2. Explicitly instantiate a new Hierarchy instance (implements LoggerRepository). 3. Call DOMConfigurator.doConfigure passing my app specific log4j.xml as an InputStream and the Hierarchy instance for the LoggerRepository argument. 4. Call Hierarchy.addRenderer to explicitly pass the renderer instance and class type. I can't configure the renderer in the config file because DOMConfigurator won't have visibility of the renderer class. Renderer is VERY app specific so loss of config file configuration is not a big deal. 5. I will then have a LoggerRepository containing my app specific settings that cannot be affected by external influences. 6. Use a custom log4j wrapper in a similar vein to commons-logging to call getLogger on my unique Hierarchy instance.
I realise the above may sound messy in terms of tidy log4j configuration but the only hardcoded configuration will be the custom object renderer and the remaining configuration will be in log4j.xml. The custom renderer is very application specific and its configuration never changes.
The custom option above wouldn't be much work and would provide the following functionality. 1. Per application instance logging configuration with no reliance on external factors. 2. Our wrapper will never be packaged at a global level so we will always have separation. 2. Global log4j installation thus avoiding any JNI UnsatisfiedLinkError issues. 3. Custom renderers can be packaged within the application (but must be registered via code instead of config file). 4. If we decide that the approach is BAD (entirely possible) we can change it in one place (in our wrapper).
The main downside to this approach that I can see is that log4j configuration cannot be managed at a global level but given that this is what I'm trying to avoid I don't see this as an issue for my application.
Sorry about the length of these emails but I like to bounce around as many ideas as I can ;-)
-- --Original Message-- -- From: Ceki Gulcu [mailto:ceki@(protected)] Sent: Thursday, 22 May 2003 5:59 PM To: Log4J Users List Subject: Re: NTEventLogAppender packaging
There is a lot of thought that went into this problem. A solution is outlined at https://www.qos.ch/logging/sc.html. It is similar to what your solution number 1) but with several improvements. I intend to work on this after the rolling package is done.
At 12:20 PM 5/21/2003 +1000, you wrote: >I'm sure this must have come up before but I have been >unable to find anybody who has come up with a >satisfactory method of resolving it. > >We have a J2EE web application that has a requirement >to write to the NT event log (windows 2000). We are >using log4j so the NT Event Log appender is the >obvious choice. > >The problems are as follows: >1. We don't want any JNI classes packaged in the EAR >file (within a WAR) for two reasons. > 1a. Reloading a web application for any reason causes > UnsatisfiedLinkError due to the native DLL already > being loaded by the JVM. > 1b. Loading two web applications causes an > UnsatisfiedLinkError in the second web application > due to the native DLL already being loaded by the >JVM. >2. We want to package log4j in the EAR for two >reasons. > 2a. Loading log4j inside each web applications > simplifies configuration (no global namespace). This > allows each web application to define its own log > settings. > 2b. We have a custom object renderer for part of the > application which we don't want to maintain external > to the web application. We can't package and > configure log4j at a global level and package the > custom renderer within the EAR for classloader > hierarchy reasons (I may be wrong). > >The NT event log appender uses JNI code and is >packaged within the log4j jar file. This means that >points 1 and 2 above conflict with each other. > >I have several options to resolve the problem: >1. Install log4j and the custom renderer at a global >level (app server lib directory). >2. Package log4j and the custom renderer within the >EAR and assume that we will never reload web >applications and only a single web application will be >deployed to the server. >3. Modify the log4j jar file and break it into two >separate components. One will contain the core log4j >functionality and will be packaged in the EAR file. >The second component will contain the NT event log >appender and will be installed in the app server lib >directory. > >Option 3 is the only "correct" solution. > >Does anybody have any other ideas on how to resolve >this problem? > >Given that log4j is often deployed as part of a web >application, is it a good idea to package JNI classes >in the core log4j package? > > >http://mobile.yahoo.com.au - Yahoo! Mobile >- Check & compose your email via SMS on your Telstra or Vodafone mobile. > >-- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ------ >To unsubscribe, e-mail: log4j-user-unsubscribe@(protected) >For additional commands, e-mail: log4j-user-help@(protected)
-- Ceki For log4j documentation consider "The complete log4j manual" ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp
-- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ------ To unsubscribe, e-mail: log4j-user-unsubscribe@(protected) For additional commands, e-mail: log4j-user-help@(protected)
-- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ------ To unsubscribe, e-mail: log4j-user-unsubscribe@(protected) For additional commands, e-mail: log4j-user-help@(protected)
Earn $52 per hosting referral at Lunarpages.
|
|
 |