On Nov 9, 2006, at 12:29 AM, Simon Willnauer wrote:
So except of the meta data work people would have to do it is just a
replacement e.g reimplementation of a single method.
Instead of Registry.getService() it would be
ApplicationContext.getBean()
is it that what you are alluding to?
On Nov 8, 2006, at 11:43 AM, Simon Willnauer wrote:
That's why I evaluated some IoC DI container like spring, hivemind,
pico and Felix (Apache OSGi). Hivemind felt good to me due to some
reasons (some more on this later @siren I will send a separate email
on this topic).
would it be possible
On May 12, 2006, at 3:38 PM, Robert Engels wrote:
I finally got around to making the NioFSDirectory with caching 1.9
compliant. I also produced a performance test case.
How does this implementation compare to the MMapDirectory?
I've found that the MMapDirectory is far faster than the
On May 15, 2006, at 5:41 PM, Robert Engels wrote:
As stated in the email, it is 3x faster reading from a Java local
cache,
then having Java go to the OS (where it may or may not be cached).
It avoids
the overhead/context switch into the OS.
I read that in the original mail, but your
Reporter: peter royal
LUCENE-475 introduced a bug in creating RAMDirectories for large indexes. It
truncates the length of the file to an int, from its original long value. Any
files that are larger than an int are truncated. Patch to fix is attached.
--
This message is automatically generated
[ http://issues.apache.org/jira/browse/LUCENE-546?page=all ]
peter royal updated LUCENE-546:
---
Attachment: RAMDirectory-truncate.diff
Index corruption when using RAMDirectory( Directory) constructor
