[ 
https://issues.apache.org/jira/browse/PYLUCENE-28?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13812882#comment-13812882
 ] 

Andi Vajda commented on PYLUCENE-28:
------------------------------------

A couple of comments. Your patch introduces a silent failure: if the second 
invocation of initVM() is made with different parameters (in particular, with a 
different classpath) people are going to be tearing their hair out with odd 
class loading errors because the 'second' classpath didn't take. Your patch 
should at least make sure that the classpath in the second invocation either 
matches the first or that the second classpath is forced into the existing VM 
(possible but hacky).

I didn't intend jcc to be used this way because of the one Java VM per process 
limitation and I thus consider your bug a feature request. It's a worthwhile 
feature nonetheless but it needs to be implemented more solidly. 

Maybe a better way to support this would be to introduce a new entrypoint in 
cpp.py that takes a VMEnv. That way, there is no silent failure possible, the 
user "knows" what VMEnv they have and passed in. Or maybe the jcc() function 
could take an optional VMEnv parameter - and check that no VM configuration 
params are passed in via args (and error if there are) in that case ?


> JCC reuses JVM instances in impl, if compile() is called twice.
> ---------------------------------------------------------------
>
>                 Key: PYLUCENE-28
>                 URL: https://issues.apache.org/jira/browse/PYLUCENE-28
>             Project: PyLucene
>          Issue Type: Improvement
>         Environment: jcc-svn-head (2.18-pre)
>            Reporter: Martin Scherer
>            Priority: Blocker
>              Labels: patch
>         Attachments: jvm_instance_check.patch
>
>
> If you import jcc.cpp to call compile yourself (a wrapped setup.py script to 
> generate a wrapper on the fly, which seems to be a common use case), the 
> current version complains about the JVM already being initialized before.
> The patch first checks for a running instance and creates one, if none is 
> being found.
> For myself, this is a blocker, since it raises otherwise.
> Best, 
> Martin



--
This message was sent by Atlassian JIRA
(v6.1#6144)

Reply via email to