On Thu, 6 Mar 2008, Bill Janssen wrote:
goodstuff.initVM(classpath=lucene.CLASSPATH, maxheap='2000m',
env=lucene.getVMEnv())
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: <jcc.JCCEnv object at 0xb7ed0240>
Hmmm, when I think about it, there's no way this can work. The
comparison in jcc.cpp is
if (!PyObject_TypeCheck((PyObject *) jccenv, &JCCEnvType))
and PyObject_TypeCheck compares the two pointers for equality, but the
two different "JCCEnvType" variables are in two different shared
libraries. So they'll never match.
Yeah, that's the bug.
I could check the type name strings instead, as a fallback workaround.
This surfaces the related issue that a Java object from one module is not
going to be considered a Java object by another module since JObject, the
root wrapper type, is also duplicated. So passing objects around across
modules is not going to work well currently.
The way to properly fix this is to have a separate JCC runtime python
extension that has all these common types. Instead of compiling the JCC
runtime code into each module, make its own python extension and import
these types from it.
This gets hairier, though, with Java classes that each module you build
might have in common, in particular, as a dependency into the JRE.
java.lang.Object from one is not the same as java.lang.Object from the
other, for example, so passing their instances across extensions is not
going to work at the moment.
In the meantime, just compile all your java modules into one python
extension. This is how lucene is built. All the jars included are compiled
together into PyLucene's lucene python module.
Andi..
_______________________________________________
pylucene-dev mailing list
[email protected]
http://lists.osafoundation.org/mailman/listinfo/pylucene-dev
