I think you should leave the API as is, and write a custom XML writer for lucene search results. The request is trivial since you can simple pass the single string. I would not write wrapper beans just to use the built-in serialization support.
The custom XML writer will be MUCH, MUCH faster, as you do not need to create an XML document first. The XML needed to support a Lucene search result is quite trivial. R -----Original Message----- From: Maros Ivanco [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 17, 2005 8:27 AM To: java-dev@lucene.apache.org Cc: Marek Baumerth Subject: lucene API Hi there, I am creating a search solution based on Lucene. A part of the solution is Lucene web service. Even though the Lucene API is very straitforward to use on a local machine, I found creation of Lucene WS to be extremely difficult. The problem causes the API, which very often does not obey even trivial coding conventions (getter and setter names, for instance). As a result, the jax-rpc subsystem is unable to produce correct serializers and deserializers. From my point of view, there are serveral possibilities to solve the problem: 1., write envelopes for nonserializable objects (Document, Field, Term, ...) 2., write custom serializers and deserializers 3., change lucene API 1. requires creation of many envelopes, since most of the Lucene classes do not obey JavaBean semantics thus, they are not serializable by jax-rpc. Wrapping and uwrapping of Lucene objects takes extra processing. Moreover, the un/wrapping is sometimes not possible, because some objects (Filters, for instance) do not exhibit their full state. I am doing this right now (and doing, and doing,... I cannot see the end :-)). 2. requires creation of de/serializer for every nonserializable class. Also requires extra configuration + generation of factories. Twice as difficult as solution 1. Moreover, this solution renders resulting WS as nonportable. 3. requires change of lucene API in the way that will allow either direct de/serialization or, at least, the solution 1. As far as Lucene is open sourced, everybody can make changes, but the real question is, whether the changes will become part of the official distribution. If not, the overall search solution will remain stucked with current release. I would personally prefer the third one, but only if the changes will make it to the official release. Our company plans to deploy several instances of the solution. There is certain probability, that my employer will contribute some resources (my time) to the project. The question is, whether the contemporary development comunity is willing to accept this kind of changes and if I can participate. So, is it? Maros. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
