Andi Vajda <va...@apache.org> wrote: > > On Tue, 23 Mar 2010, Bill Janssen wrote: > > > Andi Vajda <va...@apache.org> wrote: > > > >>> That's why I made it a JCC option, which could be enabled/disabled > >>> via the config.py file. (That is, you could build it shared with or > >>> without auto-find, but if you decided you wanted it the other way, > >>> you could simply edit config.py to change it.) > >> > >> If you build your extension with --find-jvm-dll, code to hack the Path > >> on windows is inserted into your extension's __init__.py > >> file. Otherwise, the code doesn't exist in your extension. That code > >> is run when your extension is first imported. > >> > >> That code can only be effective if it is run before the very first > >> time the _jcc extension is loaded (which loads jcc.dll and jvm.dll > >> into your process). All other extensions will be run with the > >> jcc.dll/jvm.dll pair that the first extension caused to be loaded into > >> the process. > > > > Yes, that's why it's so dangerous to put it in the extension rather than > > the jcc module. Things will mysteriously work or break depending on > > module load order. On the other hand, if you just put it in the jcc > > module, which is the first thing all JCC-generated Windows extensions > > load, the load order is immaterial. > > Yes, that is why I don't like this hack. It's broken by design. DLL > hell cannot be fixed.
I take it that you don't buy into the Python zen of "practicality beats purity". I prefer a dipper of water, even if I'm in hell :-). I don't think it makes it worse for the 20% who have odd setups, and I think it improves life for the 80% who live in drab uniformity. Andi, you've got an O: drive; most folks don't. You're running an old version of Java (1.6.0_02, if I remember correctly), the installer for which may well have had bugs which are fixed by now. At least install a newer Java on your Windows machine, and see if the registry is updated correctly. > > How about a win/win solution here? You add the --find-jvm-dll back as > > an optional arg to the setup.py for JCC, so that it can, if the user so > > desires, also do the auto-find trick. Let it default to off, as you > > prefer. That way, we have mechanism, instead of policy. Those who > > think it's a good idea can use it, and those who don't can not use it? > > And let the users vote with their configs? > > No, not unless there is more than one person on this list who requests > this hack, however forcefully and persistently ;) The last time we discussed this, all the Window users (which I gather you're not) approved this. Right now, I think I'm the only person on this list, including you, who wants to build both Windows installers for PyLucene, and my own private JCC-generated modules. > I don't understand why you want to force feed this to all. You can now > build your product so that it runs this hack. I'm actually pushing it because I believe it will make life easier for everyone concerned, not just me. I can always have my product put the JVM DLL on its PATH. But that doesn't help with compiling PyLucene. > If people run their > extension in your product's process, your product is going to > initialize things correctly before their stuff is loaded. If they run > it in their own setup, let _them_ > control it by how _they_ run jcc not the way _you_ built jcc first. I don't want to force feed it to all PyLucene or JCC users. I just want the ability to use it with JCC as well as with JCC-generated modules. And, because of the way that shared JCC works on Windows, that passes it to all of the other modules. But that's inherent in the design of JCC on Windows. Bill
