VJ, > Endeca already has a Java API, so the makeup of the search command will > be similar to SolrSearchCommand and its related components. However, > rather than adding the Endeca libraries and our search command into the > project and building them together, we'd like to be able to compile our > search command and config externally so it can be dropped into a Sesat > deployment.
1) You can keep everything within your own skin and drop in just that war file. That is a search command and its configuration class can be implemented within your own skin. Such a project would look like: myskin \-- search-command-config \-- search-command-control \-- war It's really about taking a copy of the localhost.com (generic.sesam/sesam.com) skin, since the archetype approach to create an empty skin did not work so well. The search command needs to reside within your own skin warfile (but outside of sesat-kernel's ROOT.war and generic.sesam.war) because classes are feed to the sesat through the ResourceServlet that is by default packaged with the skin. (Classloading works over HTTP making it possible to run sesat-kernel in one container/jvms and your skins in other containers/jvms). As far as third party dependencies go, eg Endeca's libraries, these don't have to be bundled into the war file if you don't want to. In the projects pom.xml define them as "<scope>provided</scope>" dependencies and then make sure that they exist in the container's classpath. Of course any Endeca search command written we hope you'll share we us and that we can publish it as part of sesat-kernel. I'm happy to help out writing and stabilising such a command. This in turn will you give back the best performing, in stability and performance, search command. "Many eyes make all bugs shallow." > Could someone also give me more details on the lookup between modes.xml > and the search configuration classes? The deserialisation and lookup from xml to class name occurs in SearchModeFactory. Lookups are implemented with AbstractConfigFactory.findClass(..). For search configuration this is implemented in SearchModeFactory.SearchCommandFactory.findClass(..) This lacks is no described in the javadoc, which i've fix now, see SearchModeFactory now! (AbstractDocumentFactory.beanToXmlName(..) had a little already). Once you are up and running you'll find the modes.xsd which is automatically generated in your skin provides the correct xml names for your newly created search configuration (and other configuration) classes. Most IDEs will, from this schema, give you autocompletion when editing modes.xml ~mck -- "Traveller, there are no paths. Paths are made by walking." Australian Aboriginal saying | semb.wever.org | sesat.no | finn.no |
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Kernel-development mailing list [email protected] http://sesat.no/mailman/listinfo/kernel-development
