https://issues.apache.org/bugzilla/show_bug.cgi?id=44386
--- Comment #8 from David Bennion <[EMAIL PROTECTED]> 2008-08-21 18:34:04 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. You can do what you want, but I just don't believe this is an issue at all and I would take the approach I took. I think it is unnecessary to create alternate 64 bit versions of the functions. My rationale is this: If you are using the Windows NT Event Logging, you know that you need to deploy the .dlls when you put out a new version of log4j. If you are not, it will never matter anyway as your app will never attempt to load the dll. I think now is the time to make a clean break and do it right. Keep the code simple and clean so that if someone was using this code as a model for some similar thing they were doing it would be obvious how to do it. >>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. I didn't think of that security privileges issue, and it is a valid point. However, the idea of doing it via the DllRegisterServer doesn't guarantee a fix. It only guarantees that you can write a default event source, so maybe named "log4j" or whatever you named it in your commit. But that forces all applications to write to the "log4j" event source. The user must specify that named event source, instead of choosing one that looks like his application. If my application is ABCServer I would rather have my event logs show up as ABCServer rather than the generic log4j -- along with every other app that uses log4j event log appender. The way I have it, all the user must do otherwise to initialize the event log is run the app as a privileged user one time so that it can create the event registry. He could even run a simpleton "initialization" class instead of the whole app. I don't know what the golden solution to this is. Personally, I think the DllRegisterServer is a misuse of the COM registration stuff, which is what regsvr32 is all about. But it is a clever way to get stuff setup outside of any Java code. >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. Give me a break. This is going to murder the value of this whole exercise for the average user. The average log4j user is a java programmer -- not guaranteed at all to have the developer tools or know how to build a native stuff on Windows (especially since you need Visual Studio 2005 to build the 64 bit stuff and the itanium stuff and you don't have a reasonable mingw alternative now and probably for some time to come in the future). Further, the user may want to support 64 bit windows but not have access 64 bit machines anyway to build the binary on in the first place. Further yet, his working java logging application will cease to work when someone starts using a 64 bit JVM on 64 bit windows instead of 32 bit. And the log4j programmer's user may need 64 bit due to the extra memory capacity available (i.e. above 1280M JVM memory), so then he is straddled with the choice between two features that he wants. Just include the dlls. The old package had the 32 bit dll pre-built and no one was complaining. Just include the 64 bit dlls along with the source code and have done with the whole mess and get back to java development. This has always been a fringe module for log4j anyway since it is not pure java. -- 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]
