https://issues.apache.org/bugzilla/show_bug.cgi?id=44386
Curt Arnold <[EMAIL PROTECTED]> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #7 from Curt Arnold <[EMAIL PROTECTED]> 2008-08-21 16:03:07 PST ---
Committed a different take in bug 687885. The submitted patches changed the
signatures on the native methods which could potentially result in undesirable
behavior if the new Java class was mixed with an old DLL or vice-versa.
In the committed change, there are separate set of native methods
(registerEventSource64 et al) that take long for the message source that are
used they appear in the DLL. If there is a UnsatisifedLinkError on ...64
method, the old "int" methods are called which from my testing allowed the new
NTEventLogAppender.class work with an old DLL.
>From comment #4:
>Another minor change: there is no reason for the .dlls to be com dll's that
>need to be regsvr32'ed on the systems. So that has been removed.
The registry keys that point to the category files are attempted to be set at
run time if they are not present, however that user may not have privileges to
write to the registry. The DllRegisterServer allows the registry keys to be
written at installation time.
>From comment #6:
>As it is very hard to build the DLL's on other platforms I suggest that they
>should be placed in subversion so the distribution can be built on any
>platform.
Building NTEventLogAppender.dll for x86 on Linux and similar should be as
simple as installing mingw-dev prior to running Maven. However, it does look
like MinGW's support for x86_64 is experimental at best (haven't looked at
Itanium), so it does not seem practical attempt to build those DLL's with MinGW
either on Windows or Linux.
To build NTEventLogAppender.dll for x86_64, open the appropriate command prompt
window from the Visual Studio Tools entry in the start menu and then run:
mvn -Dntdll_target=msbuild package
The NTEventLogAppender unit tests will require running under an x86_64 JVM to
succeed. Though the DLL would be correctly build from either an x86 or x86_64
JVM.
It would be helpful to include an x86_64 DLL in the release, however it is not
practical since the MinGW cross tools seem too immature and moving back to
building on Windows is undesirable. In addition the general ASF position is to
not to provide platform specific binaries and let downstream packagers do that.
The class initializer first attempts to load NTEventLogAppender.dll. If that
fails (either missing or not the right type), it will then attempt to load
NTEventLogAppender + System.getProperty("os.arch") + ".dll" which results in
attempting to load NTEventLogAppenderamd64.dll when running with Sun's x86_64
JVM. I thought the lower casing was problematic (turkish i and similar
problems) and unnecessary since Windows file systems are case-insensitive.
Overriding the os.arch with a system property seemed overkill and potentially a
security issue since you could redirect to an unexpected DLL.
I've modified nteventlog.cpp so that it will still properly register itself if
you rename the DLL. So if you want to rename the DLL from
NTEventLogAppender.dll to NTEventLogAppenderamd64.dll it will still work.
I thought about also providing a Visual Studio project file, however it would
still require tweaking to include the right JVM include files and a custom step
to invoke javah, etc.
Would appreciate feedback.
--
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]
