Hi, the [1] sources for Lucene's Directory based on Infinispan are here: http://anonsvn.jboss.org/repos/infinispan/trunk/lucene-directory/
Or you can have a look on FishEye: http://fisheye.jboss.org/browse/Infinispan/trunk/lucene-directory Sanne 2009/10/26 Emmanuel Bernard <emman...@hibernate.org>: > > On 23 oct. 09, at 23:00, Amin Mohammed-Coleman wrote: > >> Hi All >> Thank you for your valuable feedback. >> >> I agree that the Spring integration should actually be done on the >> Spring >> side. To be honest I have been somewhat annoyed with Spring and >> agree that >> putting Spring into the Hibernate Search isn't probably a good >> idea. It >> makes sense for Spring to be doing the work to integrate with >> Hibernate >> Search. I have created a Spring Integration Lucene indexing project >> on >> Google code which basically does aysnc indexing, this application >> takes in a >> directory and indexes files (extracts text using apache tika). >> >> 2) The reason for this came about when I was developing something >> for our >> application. Basically we have 2 products, one of the products has >> knowledge of the other so basically A knows certain things about B >> however B >> doesn't know about A (our crazy codebase). In B some entities are >> hibernate search indexed and some of the data is required in A. So >> instead >> of returning the entity to A, B publishes an event with some data >> and then A >> gets the lucene document from the B's index (hope people are still >> following >> me at this point), and populates an entity which is subsequently >> indexed in >> A. I created this method in A's codebase and thought that it would >> be handy >> to get the raw lucene document without creating a FullTextQuery and >> the do a >> search. The aim is to read a document using a convenient method to >> do this >> on the FullTextSession. > > So basically, you: > - load and change an entity E1 in B (2 I/O) > - send a message with the change diff to A (1 I/O) > - load B's index (1 I/O) > - create an entity out of the document you've loaded from B's index > (1 I/O for the doc load meaning you are storing data in the index > making it bigger) > - store the new entity and index it (2 I/O) > > Why don't you do: > - load and change an entity E1 in B (2 I/O) > - send a message with the entity (1 I/O) > - create an entity out of the entity passed as a message > - store the new entity and index it (2 I/O) > >> >> In relation to GigaSpaces, i started on this and created a openspaces >> project but there really hasnt been much momentum on it and as you >> guys have >> done work around JGroups, JMS I thought it might be a nice addition. > > It could certainly be a nice addition, I don't know GigaSpaces in > detail but if you are thinking about putting indexes onto the data > grid as opposed to the it probably looks similar to what we have done > with Infinispan. We have the infinispan prototype at ... [1] Sanne, > can you point to the svn link > >> What I >> would like to do help as much as I can and I'm happy to do what you >> guys >> need doing (writing documentation, writing tests, etc). > > There are many areas where you can help. > On of them is the programmatic mapping API that I have started a while > back. The concept is there I think but there are still many mappings > missing and the doc is non existent. > http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-352 > If you are interested, let me know and we could chat on IRC or > something like that this week. > >> To be honest I'm >> hoping for some guidance from you guys. As I mentioned before >> Hibernate >> Search is a really great library and I would like to help whatever >> way I >> can. >> >> P.S Hadoop and Hibernate Search? > > I haven't thought about that yet as I barely know Hadoop. What would > be the use case? > > >> >> Cheers >> Amin >> >> >> >> On Fri, Oct 23, 2009 at 7:24 PM, Emmanuel Bernard <emman...@hibernate.org >> >wrote: >> >>> Hello, >>> >>> On 23 oct. 09, at 16:47, Amin Mohammed-Coleman wrote: >>> >>> Hi All >>>> >>>> I have been looking at the Hibernate Search codebase and I am very >>>> keen to >>>> help out. I have noticed some small changes I would like to >>>> purpose (very >>>> small) and I hope I don't offend anyone by mentioning these. >>>> >>>> 1) Remove cyclic reference in JmsBackEndQueueProcessor and >>>> JmsBackEndQueueProcessorFactory. It seems as though the factory >>>> creates a >>>> processor and the processor depends on the factory. The processor >>>> only >>>> needs the queueConnection factory and jms queue which I think >>>> should be >>>> passed to the processor instead of passing the factory. The >>>> object being >>>> created should not know about the factory. >>>> >>> >>> Whatever ;) >>> >>> >>>> 2) Create a convienence method (not sure where) that enables a >>>> user to get >>>> the lucene document using either the fulltextsession. So for >>>> example the >>>> method would loook something like: >>>> fullTextSession.getDocument(Class<?> clazz, Serializable id); >>>> Under the hood it would delegate the work to the directory >>>> providers and >>>> close the index readers. >>>> >>> >>> What's your use case exactly? I've never had such a need. >>> >>> >>>> 3) Provide integration with GigaSpaces which I had started but not >>>> completed. >>>> >>> >>> cool. It maybe time to cut Hibernate Search into a few subprojects. >>> Hardy, >>> do you want to give it a thought? >>> >>> >>>> 4) Integration with Spring and maybe Spring Integration. >>>> >>>> >>> cool, maybe it could be another module, I don't want any unneeded >>> dependency on the core. >>> >>> >>>> Sorry if my mail is brief however I would be happy to discuss any >>>> of the >>>> points further. >>>> >>>> >>>> Kind Regards >>>> >>>> Amin (amin-mc on the forums) >>>> _______________________________________________ >>>> hibernate-dev mailing list >>>> hibernate-dev@lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>> >>> >>> >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
