Hi Peter, thanks for reply!
Is there any chance to get the old index API back, as an *alternative* to the new one? Within an OSGi environment the old index API worked perfectly in Neo4j 1.0, 1.1, and 1.2. In the latter ones the old index API friendly coexists with the new (serviceloader-based) index API but starting with Neo 1.3 the old index API was dropped. With Neo4j 1.2 I just have the neo-kernel and neo-index bundles deployed in Felix along with the Lucene bundle and it works perfectly. It is perfectly OSGi-like and it perfectly fits all the Maven workflow (no publishing of custom-build Neo bundles to a private Maven repo required). >From my point of knowledge, Java's service-loader is just not applicable in >the context of OSGi. It seems to be a lack in the OSGi Spec. On the Java-side >there is ServiceLoader.load(Class, ClassLoader) but a Bundle neither tells you >its ClassLoader nor provides a loadService(Class) method. So, my question is, why not returning to a working solution (the old index API) to support the OSGi users *now* and let it friendly coexist with the new index API? Regarding the super bundle approach: From my point of view this is the wrong way as it renders the OSGi idea pointless and complicates the Maven workflow without reason. Anyway, I will give the super bundle approach a try. Please help me with one question: how is my OSGi application supposed to be bundled? 1) *one* single bundle that contains my application (in particular its Activator) *and* the required Neo and Lucene bundles? or 2) *two* bundles: one with my application and another one with Neo and Lucene? Cheers, Jörg On Jul 20, 2011, at 19:26, Peter Neubauer wrote: > Hi Jörg, > I understand your view. However, as there is no support for scopes in > OSGi, the reasonable approach would be to import ALL dependencies for > all Neo4j code. That would require quite substancial numbers of > bundles for e.g. the enterprise edition that pollute the Bundle Space > for the whole system. > > Also, it seems every OSGi setup has its own granularity level. E.g. > some want to use their own Lucene bundle, some installations prefer > the Neo4j ones, some like JTA as its own bundle, etc etc. So for the > time being I thought a template default setup would be a good start, > as refactoring the Java Service Loader to be fully OSGi aware seems > very big to get to a stable state across all frameworks and systems. > The template is just one pom.xml at > https://github.com/neo4j/neo4j-osgi/blob/master/bundle/pom.xml and the > resulting "default" bundle could easily be published. Do you think > fine grained atomic bundles instead of a sueprbundle template that is > adaptable would be really generic? > > Secondly, I think the request for an injection-based initialization > method for index providers sounds good. Could you add a lighthouse > ticket at > http://neo4jdb.lighthouseapp.com/projects/77609-neo4j-community/tickets > or add you requests to > http://neo4jdb.lighthouseapp.com/projects/77609/tickets/3-osgi-environments-not-starting-lucene > ? > > Cheers, > > /peter neubauer _______________________________________________ Neo4j mailing list [email protected] https://lists.neo4j.org/mailman/listinfo/user
