bq. Perhaps that is not possible or too difficult in every case
To clarify - sounds like I could be saying, well, perhaps we can't
improve every case, but some we can. I'm saying *too difficult in every*
case - even if we don't try and *fix a single case* - its still
beneficial for you to report and discuss these issues IMO. And as I
said, I'll remain interested.
- Mark
On 12/5/10 3:40 PM, Mark Miller wrote:
I have an interest - don't really care if it uses true java or not. I
say keep it coming. Where/if it makes sense, why not make lucene work
better with it. Perhaps that is not possible or too difficult in every
case - but I'd still like to see the cases pop up. Better than those
spam wiki update emails.
- Mark
On 12/5/10 3:36 PM, DM Smith wrote:
Thanks Uwe (and others). We'll adapt.
Is there any interest here in knowing if there are any other problems
regarding Lucene on Android? From what I see, it is the first mobile
platform on which Lucene can run.
-- DM
On Dec 5, 2010, at 5:16 AM, Uwe Schindler wrote:
Hi DM,
In Lucene 3.0.3, NativeFSLockFactory no longer aquires a test log and
does
not need the process ID anymore, so java.lang.management package is no
longer used.
In general, Lucene Java is compatible to the Java 5 SE specification.
Android uses Harmony and therefore we cannot guarantee compatibility as
Harmony is not TCK tested (but we do with latest versions, soon there
will
also be tests on Hudson with Harmony). But only latest versions of
Harmony
are really compatible with Lucene, previous versions fail lots of
tests (ask
Robert), and Android phones use very antique versions of Harmony - it
is not
even sure, that the Java5 Memory Model is correctly implemented in
Dalvik!
About 3.0.2: Of course this version even works with latest Harmony, so
Harmony has java.lang.management package (which is java.lang!!!), so
the bug
is in Android, simply by excluding a SE package. So you should open bug
report at Google and then hope that they fix it and all the phone
manufacturers like Motor-Roller will update their Android versions.
For your problem: The easy workaround is using Lucene 3.0.3 or simply
use
another LockFactory (Andoid is single user so even NoLockFactory
would be
fine in most cases). This are the same limitations like with the NFS
filesystem. Just use FSDir.open(dir, lockFactory).
Uwe
-----
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: [email protected]
-----Original Message-----
From: DM Smith [mailto:[email protected]]
Sent: Sunday, December 05, 2010 12:16 AM
To: [email protected]
Subject: Exception in migrating from 2.9.x to 3.0.2 on Android
The current code that works on Android with 2.9.1, but fails with
3.0.2:
Directory dir = FSDirectory.open(file);
...
do something with directory
...
The error we're seeing is:
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(NativeFSLock
Factory.java:87)
12-04 21:34:41.639: WARN/System.err(23160): at
org.apache.lucene.store.NativeFSLockFactory.makeLock(NativeFSLockFactor
y.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)
Turns out Android does not have
java.lang.management.ManagementFactory.
There are several work arounds in client code, but not sure what is
best.
The bigger question is whether and how Lucene should be modified to
accommodate?
Ultimately FSDirectory.open does the following:
if (Constants.WINDOWS) {
return new SimpleFSDirectory(path, lockFactory);
} else {
return new NIOFSDirectory(path, lockFactory);
}
Should Android be a supported client OS?
If so, wouldn't it be better not to have OS specific if-then-else
and use
reflection or something else?
Thanks,
DM
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected] For
additional
commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
