https://issues.apache.org/bugzilla/show_bug.cgi?id=44386


Curt Arnold <[EMAIL PROTECTED]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|FIXED                       |




--- Comment #9 from Curt Arnold <[EMAIL PROTECTED]>  2008-08-21 22:32:22 PST ---
Changing the argument list on the existing native methods is not an option. 
There are two many scenarios where you could have a mismatch between DLLs and
log4j versions and bad things happen.  

However, it is not like we can't represent all the currently active event
sources in 32-bits.  What we could do is return the HANDLE in the 32-bit
implementation and maintain a small (maybe 256 entry) array of HANDLEs in the
64-bit versions and return the index into the array instead of the direct
handle.  That would allow pre-1.2.16's log4j's to work on 64-bit JDK's as long
as the NTEventLogAppender.dll on the path was a 64-bit DLL.  If you installed
the 32-bit NTEventLogAppender.dll in \Windows\SysWOW64 and the 64-bit in
\Windows\System32 (where 64 bit DLL's live despite the name), things might just
magically work for older versions of log4j.  log4j 1.2.16 would be needed if
you wanted to have a 32-bit dll and a 64-bit dll (NTEventLogAppender+ os.arch +
.dll) both on the path.  I'll give that a shot tomorrow.

As for including the AMD64 and/or IA64 binaries.  If we were to include them in
the log4j release itself, we'd have to keep canned versions of them in the SVN.
 We are kind of doing the same thing now with the output of the message
compiler since there isn't a cross-platform implementation of it.  It is a
little distasteful compared to building everything from source in a release,
but maybe tolerable.  I can build and test an AMD64 DLL and should be able to
build an IA64, but I won't be able to test it.  If someone is willing to test
the IA64 build, I'd be willing to include it in the release, but I would not
feel good about including it untested.


-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to