When I first started digging into the Lucene codebase, I felt
similarly - the coding convention rule breaking drove me nuts.
Lucene grew on me and I've changed my take on "conventions"
dramatically thanks to Doug's explanations and the flavor he has
imparted onto the codebase. His "conventions" have changed how I code.
If JAX-RPC has issues with Lucene, it is more an issue with JAX-RPC
than with Lucene. There are sound reasons for the design of Lucene's
API and the (non)serializability of most pieces of it. What about
the Sourceforge Lucene web service project? Would using that rather
than creating your own solution be reasonable?
Erik
On Aug 17, 2005, at 9:26 AM, Maros Ivanco wrote:
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]
