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

[Martin Denham]

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.crosswire.org/pipermail/jsword-devel/attachments/20101204/efeba081/attachment-0001.html>