We personally use a facade/factory that allows us to interface to
neo4j and the Lucene indexes as if it was a single system.
This service is a singleton initialized with Spring with an init and
destroy method that properly starts/shutdown the store and index.
If it was up to me the index utils would be part of the core neo and
have a node.setIndexedProperty() or some kind of api that does exactly
the same as setProperty but also indexes the property.
We use Spring but any kind of IOC would do similar and our config
looks like this, wrapping the services to properly manage both the neo
and index services lifecycle...
<bean id="entityFactory" class="com.yourpackage.Neo4jEntityFactory"
autowire="autodetect" init-method="init" destroy-method="destroy">
</property>
<property name="neoService">
<bean id="neoService" class="org.neo4j.api.core.EmbeddedNeo">
<constructor-arg index="0" value="${graph.filestore}"/>
</bean>
</property>
<property name="indexService">
<bean class="org.neo4j.util.index.LuceneIndexService">
<constructor-arg index="0" ref="neoService" />
<property name="isolation" value="SAME_TX" />
<property name="sorting" value="INDEXORDER" />
</bean>
</property>
<property name="fullTextIndexService">
<bean class="com.yourpackage.LuceneFullTextSimpleQueryIndexService">
<constructor-arg index="0" ref="neoService" />
<property name="isolation" value="SAME_TX" />
<property name="sorting" value="INDEXORDER" />
</bean>
</property>
</bean>
Another IOC containers allow registration of services by simply
dropping the jar and providing contribution to the system extension
points so that if you drop the index utils in the classpath you can
contribute to lifecycles such as init, destroy, per request, around
transaction, etc...
2010/1/4 Tobias Ivarsson <tobias.ivars...@neotechnology.com>:
> Hi,
>
> Neo4j today is made up of a core service that persists nodes, relationships
> and properties. In addition to that there are a number of additional
> services, where index-util is probably the most used and most important at
> the moment. index-util is also a good example of the problem I would like to
> discuss in this email.
>
> With the current architecture there is no way of introspecting which
> additional services have been initialized with a particular Neo store, for
> example there is no way of telling which (if any) IndexService has been
> used. This causes problems with the transaction recovery process, where the
> recovery mechanism today has to know about all possible extension services
> without having a compile time dependency on them. Needless to say this
> causes a mess. The code for this is ugly and borderline-buggy. It also
> causes a problem when introspecting a store, or even restarting your
> software, since it is up to the programmer to remember to restart all of the
> same services as last time.
>
> I would like to propose an addition to the store, in a separate metadata
> file in the store directory, where we store a simple list of all started
> additional services. Does anyone have any suggestions to what this should
> look like to be reasonable future proof (i.e. be able to handle some service
> that is not implemented yet as well as the current index-utils).
>
> What comes to mind is something similar to the Java ServiceLoader API [1],
> but simplified with the fact that we can require all classes referenced in
> the file to implement one specific interface, and we know where the file
> will be, in effect taking out all the complications involving ClassLoaders.
> What I'm worrying about is that storing Java classnames in a file will make
> this metadata unusable to any future implementations of the NeoStore format
> outside of the Java platform. Any suggestions to how information about
> loaded services can be stored is welcome, my idea of a clear text file might
> not even be good (since people have a tendency to think they can patch those
> manually).
>
> Since we have a community of smart and entrepreneurial individuals I thought
> I'd throw the question out here and see if I got any good responses.
>
> Cheers,
> Tobias
>
> [1] http://java.sun.com/javase/6/docs/api/java/util/ServiceLoader.html
> Simple explanation of how it works:
> * You have an interface with fully qualified classname:
> com.somedomain.someproduct.ServiceInterface
> * In each jar that provides implementations of the ServiceInterface you add
> a file called
> META-INF/services/com.somedomain.someproduct.ServiceInterface
> * In this file you put the fully qualified classnames of each implementing
> class separated by newline
> * In your code you do: ServiceLoader<ServiceInterface> impls =
> ServiceLoader.load(ServiceInterface.class);
> --
> Tobias Ivarsson <tobias.ivars...@neotechnology.com>
> Hacker, Neo Technology
> www.neotechnology.com
> Cellphone: +46 706 534857
> _______________________________________________
> Neo mailing list
> User@lists.neo4j.org
> https://lists.neo4j.org/mailman/listinfo/user
>
--
Raul Raja
_______________________________________________
Neo mailing list
User@lists.neo4j.org
https://lists.neo4j.org/mailman/listinfo/user
