[jsword-devel] Is it possible to turn off new Lucene jars use of ManagementFactory

[DM Smith]

I think the problem is that you copied 1:1, which is not valid for a search request.

BTW, I posted to Lucene's developer's list to see what should be done. The work-around is fairly straightforward. We are using Lucene's ability to pick the best implementation for the OS. It doesn't know about Android. The work around is to pick ourselves. If so, I'll need your help to properly identify Android. Probably should work that in to OSType.

I'll probably open an issue with them that Android should be supported.

-- DM

On Dec 4, 2010, at 5:42 PM, Martin Denham wrote:

> The new jars are great if only for being compiled under jdk 1.5 and therefore removing a lot of warnings generated by the Dalvik compiler.
> 
> I did some simple tests on Greek, German, French, and English bibles and all seemed fine but I did manage to throw an exception by copying a German verse, pasting the whole verse into the search field.  I will raise an issue in JIRA but it is quite hard to get the error and it may have happened with the previous version of Lucene.
> 
> Thanks for all your work
> 
> Martin
> 
> On 4 December 2010 22:23, DM Smith <dmsmith at crosswire.org> wrote:
> I guess I can revert the jar back to 2.9.3. It should be compatible. Supposedly the only differences between 2.9.3 and 3.0.2 is that 3.0.2 requires Java 5 and has deprecations removed. It should  not be otherwise different.
> 
> I'll see if we can work around it. I may be giving a patch to Lucene upstream.... Or reverting.... Or ....
> 
> -- DM
> 
> 
> On Dec 4, 2010, at 5:10 PM, Martin Denham wrote:
> 
>> Unfortunately Android does not have java.lang.management.ManagementFactory
>> 
>> The old version of Lucene never required it but the new version of Lucene does.
>> 
>> 12-04 21:34:41.629: WARN/System.err(23160): java.lang.NoClassDefFoundError: java.lang.management.ManagementFactory
>> 12-04 21:34:41.639: WARN/System.err(23160):     at org.apache.lucene.store.NativeFSLockFactory.acquireTestLock(NativeFSLockFactory.java:87)
>> 12-04 21:34:41.639: WARN/System.err(23160):     at org.apache.lucene.store.NativeFSLockFactory.makeLock(NativeFSLockFactory.java:142)
>> 12-04 21:34:41.649: WARN/System.err(23160):     at org.apache.lucene.store.Directory.makeLock(Directory.java:106)
>> 12-04 21:34:41.649: WARN/System.err(23160):     at org.apache.lucene.index.IndexWriter.init(IndexWriter.java:1058)
>> 
>> I can't really see a reason to use ManagementFactory but here is how it is used:
>> 
>> private synchronized void acquireTestLock() {
>>     if (tested) return;
>>     tested = true;
>>     
>>     // Ensure that lockDir exists and is a directory.
>>     if (!lockDir.exists()) {
>>       if (!lockDir.mkdirs())
>>         throw new RuntimeException("Cannot create directory: " +
>>                               lockDir.getAbsolutePath());
>>     } else if (!lockDir.isDirectory()) {
>>       throw new RuntimeException("Found regular file where directory expected: " + 
>>                             lockDir.getAbsolutePath());
>>     }
>> 
>>     // add the RuntimeMXBean's name to the lock file, to reduce the chance for
>>     // name collisions when this code is invoked by multiple JVMs (such as in
>>     // our tests). On most systems, the name includes the process Id.
>>     // Also, remove any non-alphanumeric characters, so that the lock file will
>>     // be created for sure on all systems.
>>     String randomLockName = "lucene-"
>>         + ManagementFactory.getRuntimeMXBean().getName().replaceAll("[^a..zA..Z0..9]+","") + "-"
>>         + Long.toString(new Random().nextInt(), Character.MAX_RADIX)
>>         + "-test.lock";
>> 
>> I suppose I could edit the code and build a modified Lucene jar but I don't really want to do that.  Another solution might be to go back to earlier jars but again that would lead to differences with JSword.  I suppose I could disable index creation on Android because the above is only required during index creation.  At the moment all I can think of is to modify the Lucene jars.
>> 
>> Any ideas?
>> 
>> Thanks
>> Martin
>> _______________________________________________
>> jsword-devel mailing list
>> jsword-devel at crosswire.org
>> http://www.crosswire.org/mailman/listinfo/jsword-devel
> 
> 
> _______________________________________________
> jsword-devel mailing list
> jsword-devel at crosswire.org
> http://www.crosswire.org/mailman/listinfo/jsword-devel
> 
> 
> _______________________________________________
> jsword-devel mailing list
> jsword-devel at crosswire.org
> http://www.crosswire.org/mailman/listinfo/jsword-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.crosswire.org/pipermail/jsword-devel/attachments/20101204/12896def/attachment-0001.html>