You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-dev@logging.apache.org by "Lilianne E. Blaze" <li...@tlen.pl> on 2007/10/12 02:28:44 UTC
Small patch for NTEventLogAppender
Hello,
I had major problems getting Log4j compiled on Netbeans 6.0 / WinXP.
It was constantly bitching about lack of NTEventLogAppender.dll, even
when I did everything I could think of to turn off the tests during
compilation.
The patch below basically checks for the dll file, and if it's not found
emits a log-log warn and then silently swallows all events.
Could you please consider including it?
Or at least provide some instructions on how to disable that particular
test during the build?
Greetings, Lilianne E. Blaze
Index: NTEventLogAppender.java
--- NTEventLogAppender.java Base (BASE)
+++ NTEventLogAppender.java Locally Modified (Based On LOCAL)
@@ -38,6 +38,7 @@
@author <a href="mailto:jim_cakalic@na.biomerieux.com">Jim
Cakalic</a> */
public class NTEventLogAppender extends AppenderSkeleton {
private int _handle = 0;
+ static private boolean _libLoaded = false;
private String source = null;
private String server = null;
@@ -73,6 +74,11 @@
this.layout = layout;
}
+ if( !_libLoaded ) {
+ LogLog.warn("NTEventLogAppender system library is not loaded.
NTEventLogAppender will not work.");
+ return;
+ }
+
try {
_handle = registerEventSource(server, source);
} catch (Exception e) {
@@ -88,7 +94,7 @@
public
void activateOptions() {
- if (source != null) {
+ if ( _libLoaded && source != null) {
try {
_handle = registerEventSource(server, source);
} catch (Exception e) {
@@ -101,6 +107,11 @@
public void append(LoggingEvent event) {
+ if( !_libLoaded )
+ {
+ return;
+ }
+
StringBuffer sbuf = new StringBuffer();
sbuf.append(layout.format(event));
@@ -126,9 +137,11 @@
public
void finalize() {
+ if( _handle != 0 ) {
deregisterEventSource(_handle);
_handle = 0;
}
+ }
/**
The <b>Source</b> option which names the source of the event. The
@@ -157,6 +170,12 @@
native private void deregisterEventSource(int handle);
static {
+ try {
System.loadLibrary("NTEventLogAppender");
+ _libLoaded = true;
}
+ catch(java.lang.UnsatisfiedLinkError e) {
+ _libLoaded = false;
}
+ }
+}
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Small patch for NTEventLogAppender
Posted by "Lilianne E. Blaze" <li...@tlen.pl>.
Hello,
Then, could you please consider adding the following (or similar) file:
Index: BUILD-ON-WINDOWS
--- BUILD-ON-WINDOWS Locally New
+++ BUILD-ON-WINDOWS Locally New
@@ -0,0 +1,11 @@
+Default build configuration tries to build and test NTLogEventAppender,
which
+is partially based on Windows32 native code.
+
+To build Log4j on Windows32 you need to either
+
+1a) Install MinGW [someone please provide more details]
+
+Or
+
+1b) Copy NTEventLogAppender.dll from binary Log4j distribution to your
system
+directory (usually C:\Windows\System32)
\ No newline at end of file
Greetings, Lilianne E. Blaze
Curt Arnold wrote:
>
> On Oct 11, 2007, at 11:20 PM, Lilianne E. Blaze wrote:
>
>> Looks like it's not enough. Is there any simple way to just tell maven
>> to skip the tests? There is an option in NB that says just that, but it
>> doesn't work. Probably having something to do with three different build
>> scripts.
>> For now I just put that dll in %system% and it works, I'll look into it
>> later. To be honest, so far re-compiling log4j wasn't exactly
>> straightforward.
>>
>
> Sorry, I don't use Netbeans and it didn't know that it was invoking
> Maven which in turn invokes Ant. Maven does not pass system
> properties on to Ant, but you could backdoor it by creating
> tests/build.properties containing:
>
> skip-nteventlogtest=whatever
>
> Since the tests/build.xml file will load build.properties if it exists.
>
> The simple way to tell Maven not to run the tests, is to not select a
> goal that requires the tests to be run, for example, "compile".
> "package" which creates a Jar, does run the unit tests. If you really
> don't want Netbeans to run any of the tests, you could use the same
> unless="..." trick on the "runAll" target.
>
> Also, if you had MinGW installed, then the build script should build
> NTEventLogAppender.dll and place it on the path for the unit tests and
> you should not need to have to place it in %system%.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Small patch for NTEventLogAppender
Posted by Curt Arnold <ca...@apache.org>.
On Oct 11, 2007, at 11:20 PM, Lilianne E. Blaze wrote:
> Looks like it's not enough. Is there any simple way to just tell maven
> to skip the tests? There is an option in NB that says just that,
> but it
> doesn't work. Probably having something to do with three different
> build
> scripts.
> For now I just put that dll in %system% and it works, I'll look
> into it
> later. To be honest, so far re-compiling log4j wasn't exactly
> straightforward.
>
Sorry, I don't use Netbeans and it didn't know that it was invoking
Maven which in turn invokes Ant. Maven does not pass system
properties on to Ant, but you could backdoor it by creating tests/
build.properties containing:
skip-nteventlogtest=whatever
Since the tests/build.xml file will load build.properties if it exists.
The simple way to tell Maven not to run the tests, is to not select a
goal that requires the tests to be run, for example, "compile".
"package" which creates a Jar, does run the unit tests. If you
really don't want Netbeans to run any of the tests, you could use the
same unless="..." trick on the "runAll" target.
Also, if you had MinGW installed, then the build script should build
NTEventLogAppender.dll and place it on the path for the unit tests
and you should not need to have to place it in %system%.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Small patch for NTEventLogAppender
Posted by "Lilianne E. Blaze" <li...@tlen.pl>.
Looks like it's not enough. Is there any simple way to just tell maven
to skip the tests? There is an option in NB that says just that, but it
doesn't work. Probably having something to do with three different build
scripts.
For now I just put that dll in %system% and it works, I'll look into it
later. To be honest, so far re-compiling log4j wasn't exactly
straightforward.
But, maybe you could consider something like my previous patch + the
following modification:
static {
try {
System.loadLibrary("NTEventLogAppender");
_libLoaded = true;
}
catch(java.lang.UnsatisfiedLinkError e) {
if(
"warnOnly".equals(System.getProperty("log4j.nteventlog.failmode")) ) {
_libLoaded = false;
} else {
throw e;
}
}
}
?
This way it behaves like before when the property is not set, and
silently swallows when it is.
Greetings, Lilianne E. Blaze
Curt Arnold wrote:
>
> On Oct 11, 2007, at 7:28 PM, Lilianne E. Blaze wrote:
>
>> Hello,
>> I had major problems getting Log4j compiled on Netbeans 6.0 / WinXP.
>>
>> It was constantly bitching about lack of NTEventLogAppender.dll, even
>> when I did everything I could think of to turn off the tests during
>> compilation.
>>
>> The patch below basically checks for the dll file, and if it's not found
>> emits a log-log warn and then silently swallows all events.
>>
>> Could you please consider including it?
>>
>> Or at least provide some instructions on how to disable that particular
>> test during the build?
>>
>
> The behavior when deployed is much more critical that behavior in an
> IDE that making a change to make life in a particular IDE better isn't
> a compelling argument. While not every decision was perfect, any
> change of behavior must be carefully considered as to the benefits
> that it offers users when deployed vs the potential for breaking some
> app that depends on the established behavior.
>
> Changes in the test suite or tests/build.xml have a much lower
> threshold as they don't affect deployed behavior. Currently the
> tests/build.xml will skip the NTEventLogAppenderTest if the build is
> executed on a non-Windows platform. You could modify tests/build.xml
> to skip that test if an arbitrary property is set, something like:
>
> -<target name="NTEventLogAppender" depends="build" if="is-windows">
> +<target name="NTEventLogAppender" depends="build" if="is-windows"
> unless="skip-nteventlogtest">
>
> If you set the skip-nteventlogtest property when you launch
> tests/build.xml, the test should be bypassed for you and you won't
> have to see the messages. If that works for you, I'd have no problem
> with that going in.
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Small patch for NTEventLogAppender
Posted by Curt Arnold <ca...@apache.org>.
On Oct 11, 2007, at 7:28 PM, Lilianne E. Blaze wrote:
> Hello,
> I had major problems getting Log4j compiled on Netbeans 6.0 / WinXP.
>
> It was constantly bitching about lack of NTEventLogAppender.dll, even
> when I did everything I could think of to turn off the tests during
> compilation.
>
> The patch below basically checks for the dll file, and if it's not
> found
> emits a log-log warn and then silently swallows all events.
>
> Could you please consider including it?
>
> Or at least provide some instructions on how to disable that
> particular
> test during the build?
>
The behavior when deployed is much more critical that behavior in an
IDE that making a change to make life in a particular IDE better
isn't a compelling argument. While not every decision was perfect,
any change of behavior must be carefully considered as to the
benefits that it offers users when deployed vs the potential for
breaking some app that depends on the established behavior.
Changes in the test suite or tests/build.xml have a much lower
threshold as they don't affect deployed behavior. Currently the
tests/build.xml will skip the NTEventLogAppenderTest if the build is
executed on a non-Windows platform. You could modify tests/build.xml
to skip that test if an arbitrary property is set, something like:
-<target name="NTEventLogAppender" depends="build" if="is-windows">
+<target name="NTEventLogAppender" depends="build" if="is-windows"
unless="skip-nteventlogtest">
If you set the skip-nteventlogtest property when you launch tests/
build.xml, the test should be bypassed for you and you won't have to
see the messages. If that works for you, I'd have no problem with
that going in.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org