 | | | 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.
|
|
|