I'm not an expert on Avalon, so this will be a learning experience for everyone involved :-)
HiveMind is targetted at a layer below Avalon; you would use its concept of services and configurations to build a container like system, though it isn't a container per-se. The interceptor concept (which, of course, is an integral part of servers like JBoss and, in a more general sense, all J2EE app servers) can provide container like services; you can transparently wrap a service with a logger, a performance monitor, a JMX monitor, or a transactional wrapper, whatever. Perhaps part of HiveMind will be interceptor factory services for those type of operations. Avalon has a more explicit assembly stage, where (this may be more Phoenix related) you assemble Blocks, identify roles and so forth. HiveMind is more dynamic, where the various HiveModule descriptors are located, parsed, assembled, verified and applied at runtime ... this allows dynamic changes to the application for testing purposes, and the ability to provide difference versions of the application for different purposes. In addition, HiveMind is specifically targeted at a real separation of interface and implementation ... where one module defines an interface (and a service extension point), a second module provides the implementation of the interface, and other modules provide interceptors to enhance the implementation. For instance, for my at-work project (which I hope to use both Tapestry and HiveMind on), there's some database dependencies in our current code. Using HiveMind to refactor, those dependencies go into one or more HiveMind modules. Code that currently does a JNDI lookup to get a DatabaseConnection will, instead, work through a new API that abstracts out those details; we'll have different implementation modules for Oracle, SQLServer, etc. ... and, of course, an embedded server for local developer testinging. In addition, we something that can be easily compatible with a number of J2EE application servers; I haven't been able to uncover the deployment story for Phoenix yet, but I don't see that Phoenix SARs will be compatible with J2EE EARs. HiveMind modules will be packaged as llbrary and EJB jars within an EAR and will still be operational as such (just a matter of convincing Maven to produce the right Manifest Class-Path headers). Again, I see HiveMind also operating at a lower level, as a gateway to the kind of code available in Avalon, or in JMX, or as EJBs. I'm not trying to boil the ocean; what I see in HiveMind is a solution to some general problems at my work; HiveMind is a solution to those problems, but (like a lot of my solutions) it's very general purpose. I see it as having a lot of synnergy with existing Apache projects such as Avalon and Turbine. I think a home in commons-sandbox is simply more appropriate than yet-another-SourceForge project. -- Howard M. Lewis Ship Creator, Tapestry: Java Web Components http://jakarta.apache.org/tapestry > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: Tuesday, May 27, 2003 8:27 PM > To: [EMAIL PROTECTED] > Subject: RE: [PROPOSAL] HiveMind in the sandbox > > > Can you elaborate on the differences between HiveMind and > Avalon? After a first read, it seems like they both share > similar aims...? > > Eric Pugh > > -----Original Message----- > From: Howard M. Lewis Ship [mailto:[EMAIL PROTECTED] > Sent: Tuesday, May 27, 2003 8:23 PM > To: [EMAIL PROTECTED] > Subject: [PROPOSAL] HiveMind in the sandbox > > > Proposal for HiveMind Package > > (0) rationale > > HiveMind is a simple, flexible framework for creating > pluggable, configurable, reusable services. By pluggable, we > mean that there is a complete separation of service > definition and service implementation. By configurable we > mean that modules may contribute services and configuration > data to each other in a well organized way. It also means > that configuration data is pervasive, supplied by many > individual modules, rather than centralized in a single file. > By reusable we mean that both HiveMind itself, and modules > created using HiveMind may be easily recombined and > reconfigured for use in disparate applications. > > HiveMind's basic unit is a module (a single project creating > a single module JAR). At runtime, HiveMind builds a registry > by accessing a deployment descriptor in each module. Modules > can declare service extension points and configuration > extension points. Services are expressed in terms of an > interface, configurations in terms of a data type. Modules > may contribute to service and configuration extension points > within themselves or, more frequently, in other modules. > > A service contribution may be a factory (which creates a > "Plain Old Java Object" (POJO) to implement the service), or > an interceptor, which provides added functionality to a > service implementation by intercepting method invocations. > Interceptors are created by a particular kind of HiveMind > service (to some degree, HiveMind is recursively defined). > Services may also be called upon to create acts factories for > objects used by other services. > > Modules may also contribute configuration extensions; these > are objects that are specified and/or created and plugged > into a configuration extension point. > > A signficant portion of HiveMind involves the build time > aspects of modules; this includes specialized Maven plugins > for creating HiveMind modules using the HiveMind deployment > descriptor as the basis for module dependencies. It also > includes generation of hypertext documentation identifying > all of an application modules, extensions and contributions. > > The API for HiveMind allows threadsafe, easy access to > services and configurations in a minimal amount of code. The > value-add for HiveMind is not just runtime flexibility: it is > developer productivity. HiveMind systems will entail less > code; key functionality that is frequently an after-thought, > such as reading configuration files, is handled by the > HiveMind in a consistent, robust, well-documented manner. > > HiveMind will embrace and adapt the best practices > established in the Tapestry project, including line-precise > exception reporting (a feature of Tapestry in which runtime > objects are related back to the XML specifications from which > they were generated, to assist the developer in diagnosing > and fixing problems). > > > (1) scope of the package > > The package shall entail a core library JAR, along with > ancilliary artifacts such as Maven plugins and, of course, > documentation, all distributed under the Apache Software License. > > > (1.1) interaction with other packages > > HiveMind has dependencies on several standard commons > packages, including: commons-lang, commons-digester and > commons-logging. > > It makes use of OGNL (Object Graph Navigation Library) which > is available from http://www.ognl.org. OGNL is licensed under > modern BSD. > > HiveMind currently has dependencies on Tapestry. Over time, > a goal of HiveMind is to reverse those dependencies, moving > common code from Tapestry to HiveMind. > > > (2) identify the initial source for the package > > The initial codebase is being developed by Howard M. Lewis > Ship. Source code is available for review upon request (as a > buildable Maven project). > > (2.1) identify the base name for the package > > org.apache.commons.hivemind > > (2.2) identify the coding conventions for this package > > Coding conventions match those established in the Tapestry project. > > (3) identify any Jakarta-Commons resources to be created > > (3.1) mailing list > > Until traffic justifies, the package will use the > Jakarta-Commons list for communications. > > (3.2) CVS repositories > > For the time being, the package will use a root branch of the > Jakarta-Commons CVS. > > (3.3) Bugzilla > > The package should be listed as a component of under the > Jakarta-Commons Bugzilla entry. > > (4) identify the initial set of committers to be listed in > the Status File. > > Howard M. Lewis Ship > > > -- > Howard M. Lewis Ship > Creator, Tapestry: Java Web Components > -and HiveMind! > http://jakarta.apache.org/tapestry > > > > --------------------------------------------------------------------- > 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]
