Hi all,
I'm now working for quite some time on HiveApp here at OPS4J and I
think, this work is good. However, it seems to me that the OPS4J
community is very OSGi-centric and the wrong place for a project like
that. Yes, there are no docs whatsoever, and yes, there isn't even a
build file for Ant. I perfectly understand, why there's absolutely no
echo -- how could there be any, nobody but me is actually able to at
least build it, without spending hours on figuring out how to do that
and without having at least an idea of what it actually does ... :)
Therefore, I'm considering to (temporarily) move HiveApp to my own
domain, get the build working, add some docs, and announce it at places
where people reside, who could actually be interested in it (e.g. the
HiveMind mailing list). The goal is to find some community -- OPS4J
seems to be the wrong one, because it's very OSGi-centric. raffael.ch
isn't the right place neither, that's for sure, but that could be a
temporary solution to get it somewhere ...
But I'd actually like to stay here, therefore the question to all of
you: Is there any interest in something like this at all?
So, what does HiveApp do?
It provides an infrastructure for building plugin-based applications. It
uses HiveMind for all the wiring and "stuff", but it also extends
HiveMind heavily. It actually extends HiveMind in areas, which make it
unsuitable for certain applications, HiveMind was designed for. E.g.,
HiveMind could also be used for EJBs. HiveApp can't (or shouldn't),
because it violates certain constraints for EJBs, that HiveMind doesn't
violate. Hence the name: HiveApp is designed for building
*applications*, HiveMind is designed for building about *any* "thing"
in a modular way.
So, what does it do now? Please?
* It introduces a concept of "AppModules" (Application Modules).
AppModules are basically HiveModules, just some extensions added.
There's also a distinction between "application modules" (plugins)
and "boot modules" (needed for bootstrapping the application, those are
basically "POHMs" ("Plain Old HiveModules" ;)).
* It introduces a sophisticated ClassLoader management (I recently cut
it down a bit, although the current implementation is actually more
complex than the previous one, it provides less flexibility -- for the
good of it). The HiveApp ClassLoader allows to share classes among
other ClassLoaders, trying to get the versions in sync (the newest
version all modules agree to, wins), by keeping the possibility for
each module to use its own version (if it doesn't import a package,
it'll get its own version, no matter what).
Some detail about how the ClassLoader resolves things: Let's assume
there's a module A, which requires package p in version 2 or higher,
providing it in version 2.0.1. There's another module B, which requires
2.4.x and provides version 2.4.1. And another module C, that requires
2.2 or highter and itself provides 3.0.3. And yet another package D,
which requires 2+ and provides 2.4.3.
=> 2.4.3 will be chosen for all modules sharing that package. Because
the newest available version of the package, which all modules accept,
is 2.4.3. 2.0.1 e.g. is too old for most of those modules, 3.0.3 is too
new for module B. But 2.4.3 and 2.4.1 fit all the requirements, so
2.4.3 wins, because it's newer.
Modules that don't explicitly import a package, are free to use whatever
version they like, but for modules sharing a package with other
modules, one single package version will be determined and used. If an
import is unresolvable, it'll be logged as error and you'll be
confronted with ClassNotFoundExceptions. Reports about all this can be
obtained using JMX.
* It introduces a sohpisticated resource management. Each AppModule is a
file system of its own, using the ch.raffael.hiveapp.vfs.* packages.
These file systems are read-only, but scannable by any other module.
There are services that allow modules to ask for a list of present
modules and scan their (virtual) file systems for things that they're
interested in. E.g., in Loom (AKA Raffi's proposal for Silk), the
Drools plugin scans all modules for a container resource (AKA
directory) called "rules" for *.drl files for including them into the
rule base. This is extended further: There's always a context ensured,
which not only provides the information, which plugin the code belongs
to, but also, which plugin called the code. That one can heavily help
to cut down APIs.
This VFS API is designed for being a thin layer that doesn't force all
of the code to depend on it. Use resource.toURI().toURL() or
resource.getInputStream() to break out of this API and use whatever you
want. Only at the highest level, the direct interface to the underlying
system, it's required to use that API.
* Only a minimal bootstrapping classpath has to be set up; that comes
with the above point (VFS), because that one's actually used by the
before-above point (ClassLoader) to determine where to get the classes
from. Basically, the JARs needed are hivemind.jar and hiveapp.jar.
hivemind.jar additionally needs oro.jar (which is a pitty, but well)
and javassist.jar. The latter dependency of HiveMind lead me to use it
as well on bootstrapping-level, so hiveapp.jar needs that one, too.
commmons-logging is used for Logging. And that's it (hivemind.jar,
hiveapp.jar, commons-logging.jar, javassist.jar and unfortunately
jakarta-oro.jar).
* It provides utilites for building Proxies (=> AOP). Creating a proxy
class for some interface is a matter of a few lines. No
java.lang.reflect.Proxy is being used for that, it's all dynamically
created Classes using Javassist (and the very nice tools for working
with Javassist provided by HiveMind). That's more interesting for boot
modules, actually, but might come in very handy for plugins, too.
* It provides convenience services for several tasks: JMX support is a
breeze with it, RMI support, too, it allows privating parts of services
using the ServiceProxyFactory (and HiveMind's feature to declare
services as 'private'), and other useful stuff.
So, is there any interest in that thing? As written above: I think, this
one's really good. It contains some hacks, true ... :( but I did them
because I needed them, and maybe, someone has some better idea, how to
do these things.
But I'm very sure, and it will be hard to convice me otherwise, that
this one's a very good approach to plugin-based applications where even
the core functionality is a plugin already ... :)
Comments are welcome ... I'll try to get build and docs up ASAP, but I'm
still doing most of the work in my spare time, so bear with me ... feel
free to ask questions, if you actually want to take a look at it --
Jabber-ID: [EMAIL PROTECTED]
cu,
Raffi
--
The difference between theory and practice is that in theory, there is
no difference, but in practice, there is.
[EMAIL PROTECTED] · Jabber: [EMAIL PROTECTED]
PGP Key 0x5FFDB5DB5D1FF5F4 · http://keyserver.pgp.com
_______________________________________________
general mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/general
