Passing on Howard's reply...
Begin forwarded message:
From: "Howard M. Lewis Ship" <[EMAIL PROTECTED]>
Date: April 7, 2006 5:00:31 PM EDT
To: Erik Hatcher <[EMAIL PROTECTED]>
Subject: Re: Microkernal architecture (was Re: XML Query)
Cool.
Erik Hatcher wrote:
On Apr 7, 2006, at 2:33 PM, Yonik Seeley wrote:
Is it possible to approach this (using a config microkernel) in an
incremental and backward compatible way?
I can't say entirely for sure, but I think so. We could make a
MicrokernalRequestHandler and within it would be the HiveMind
container mojo leaving the standard request handler alone while
we iron out the kinks.
I agree that we would gain a lot (in the long run) by using
something
like Spring or Hivemind.
Spring, at least from my well-read but virgin perspective, is a
big bite to take. It's J2EE redone, and while it is easy to use
within our context we'd only be using a fraction of what "Spring"
offers overall. HiveMind is a no-frills way to do the same thing.
Spring is both an IoC container and a set of libraries built on top
of, and integrated via, the container. I think HiveMind's container
does a number of things (important to me) better than Spring's.
Spring's Aspect Oriented Programming support is more refined.
HiveMind does a lot less with reflection and a lot more with
runtime code generation which may (may! not definately!) make a
difference in performance.
Spring is primarily a container for organizing the classes that
make up an application. HiveMind is primarily a container for
organizing a set of libraries. You somewhat have to be hip-deep in
containers and development to appreciate the differences.
When it comes to flexible configuraiton, that's where HiveMind
shines. You can create a kind of domain specific XML contribution
format (which is nicer than always talking exclusively in terms of
maps, lists, keys, and values like you would in Spring). More
importantly, once you define a configuration point, any module can
contribute into that configuration point. In this way, it's easy to
build and extend the application. It's also good for sub-dividing
the application. Much of this was built with the idea of taking a
monolithic application (WebCT's Vista) and reorganizing it so that
we could generate distributions with different functionality, or
connections to different types of databases, just by juggling the
JARs inside the applications EAR. It's a very high level of coding,
and adds a lot of abstractions, but ends up being very powerful.
For example, many of the features of Tapestry are defined in terms
of configuration points. An add-on library that provides new
features (for example, new strategies for managing persistent state
within the application) simply is a JAR with a hivemodule.xml
descriptor that contributes into a standard configuration point. No
additional configuration is needed, just drop the JAR on the
classpath and take advantage of its features.
ps: I worry slightly about going with Hivemind over Spring (which
seems to have won the popularity contest in a big way).
Tapestry users expressed the same concern, but both play fine
together. There are gateways to Spring from HiveMind, allowing a
system to use Spring for another subsystem, and wire beans into
Solr's HiveMind configuration into its Spring container. So we
definitely would not be closing the doors to someone using
Spring, but Solr's configuration would be in HiveMind. And for
all I know, there may be a one-line way to wire up HiveMind to
get all its configuration via Spring as well. I'm copying in
Howard Lewis Ship so he can see that we're discussing, without
much actual experience in this speaking for myself, ways to wire
in flexible configuration into Solr and what his thoughts on it
might be.
I don't know anything about Solr.
Using an IoC container is a lot like writing unit tests; initially
it seems like a pain in the ass, just more busy work. But before
you know it, you can't live without it!
Erik
On 4/7/06, Erik Hatcher <[EMAIL PROTECTED]> wrote:
Here's my opinion on this matter... a StandardRequestHandler
shouldn't even need to be subclassed to plug in different query
parsers. This is where a microkernal framework such as HiveMind
would really shine. I'm ashamed to admit that I'm not skilled
in the
ways of HiveMind Jedi, despite my Tapestry immersion, but the
benefits HiveMind offer are exactly for this sort of pluggable
features capability. I see several facets to a request handler and
each of these should be tunable by simple configuration: query
parsing, (possible future) multiple index support, request and
response protocols (OpenSearch, Solr XML, XML-RPC), highlighting,
security (a big one I haven't seen discussed here), and more. So
rather than a subclassing architecture, let's go for a kernel
architecture where we can plug in features easily very modularly
via
configuration rather Java code.
Anyone here toyed with HiveMind or Spring? I'd like to eat our own
dog food and give HiveMind a try though. Ah, yet another fun
idea to
put on my TODO list! Maybe I'll be lucky and someone beats me
to it :)
Erik
On Apr 7, 2006, at 12:12 PM, Yonik Seeley wrote:
On 4/6/06, Chris Hostetter <[EMAIL PROTECTED]> wrote:
: The easiest way would be to add another parameter specifying
the
: default query syntax.
: qformat=lucene // default QueryParser syntax
: qformat=xml // Mark's XML query syntax
: qformat=surround // Paul's surround query syntax
You mean the the standard request handler?
Why not add an XmlRequestHandler and an SurroundRequestHandler
that each
parse their "q" param using the appropraite parser?
If the only thing one wants to change is the format of the Lucene
query itself, and not the complete request (Paul's surround syntax
might be a better example), and it's a broadly applicable query
format, then why make a whole new handler?
But, it would make sense if enough stuff was different (query
args,
way to specify return fields, return format, etc). For example, I
imagine that enough stuff would be different for OpenSearch
support
that it would make sense to have a different handler.
-Yonik
--
Howard M. Lewis Ship
Independent J2EE / Open-Source Java Consultant
Creator, Jakarta Tapestry
Creator, Jakarta HiveMind
Professional Tapestry training, mentoring, support
and project work. http://howardlewisship.com
