logging-log4j-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Curt Arnold <carn...@apache.org>
Subject Re: NTEventLogAppender with missing description source for Windows Server 2003
Date Wed, 13 Dec 2006 20:13:49 GMT

On Dec 13, 2006, at 10:43 AM, CHANG Shuh wrote:

> Hi Emilie,
>
> Thanks for your inquiry. Please keep all inquiries on the log4j-user
> list.
>
> No, I have not heard much back to resolve this issue. I am hoping that
> someone who knows the answer could help out.
>
> Basically, the NTEventLogAppender works to capture the log information
> in the Event Viewer, except that it also generates those extra  
> annoying
> messages for every log that you send. These extra messages clog up  
> (and
> probably mislead) the real log message that makes the  
> NTEventLogAppender
> somewhat unrealistic for a real application.
>
> The real issue is that NTEventLogAppender itself does not register
> properly with regsvr32 to begin with. Curt Arnold earlier gave some
> clues on that as he wrote:
>
> "If it appears to be missing header files, it is likely files that are
> produced by javah that generate the header required to implement the
> java native methods."
>
> Since the downloaded log4j package does not provide complete source
> files required to build the whole DLL thing, I was hoping that someone
> involved in the log4j development could provide some more help here.
>
> Regards,
> Shuh
>


I believe that you misinterpreted my response.  The log4j package  
does include all files necessary to rebuild NTEventLogAppender.dll,  
it is not missing any files.  If you run the ant target  
"build.nt.dll" on Windows with MinGW on the path (I believe that I  
use MinGW 3.1 or 3.1.1), NTEventLogAppender.dll will be built.  It  
appears that you were attempting to build the appender without using  
the build script and did not use javah to create the supposedly  
missing header files corresponding to the java classes  
org.apache.log4j.nt.NTEventLogAppender and org.apache.log4j.Priority.

regsvr32 does not find a DllRegisterServer in NTEventLogAppender.dll  
since that entry point was never written.  Just having a  
DllRegisterServer entry point would satisfy regsvr32, but it would  
not address the unregistered message file issues.

To enhance the NTEventLogAppender.dll to address your observed  
complaints, a DllRegisterServer and DllUnregisterServer entry points  
would need to be added to NTEventLogAppender.dll.  The implementation  
of DllRegisterServer would need to determine the full path to  
NTEventLogAppender.dll using GetModuleFileName() and then would need  
to register the DLL as a message source as described in http:// 
msdn2.microsoft.com/en-us/library/aa363661.aspx.  The DLL does appear  
to contain the necessary message resource, it just doesn't appear to  
have any code that attempts to register itself. What you are  
experiencing is exactly what is described at the bottom of that page.

> An application can use the Application log without adding a new  
> event source to the registry. If the application calls  
> RegisterEventSource, passing a source name that cannot be found in  
> the registry, the event-logging service uses the Application log by  
> default. However, because there are no message files, the Event  
> Viewer cannot map any event identifiers or event categories to a  
> description string, and will display an error. For this reason, you  
> should add a unique event source to the registry for your  
> application and specify a message file.

To recap:

1. log4j 1.2.14 isn't missing any files.  The files that you thought  
were missing are generated using javah in the build script.  If you  
don't use the build script, you have to manually perform all the  
steps in to compile the message files, resource files, and generate  
the header files corresponding to the needed java classes.
2. The observed behavior isn't a regression.  That is, it didn't stop  
working, it just never had the necessary code to implement  
registering itself as an event source.
3. The observed behavior isn't desirable.  A patch that added a  
DllRegisterServer entry point to make the appropriate registry  
entries would be a helpful contribution as an enhancement.  If anyone  
would like to take a shot and contribute your work, create a new bug  
in Bugzilla and then after creating the bug attach a patch file.


---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org


Mime
View raw message