These pages are living design documents for proposed changes to the HiveMind framework.

Each proposal begins with a problem statement: something about the HiveMind framework that is deserving of change.

Please remember that these documents will often be read out of context ... be specific about what release of HiveMind contains the "problem", and keep the proposal updated with respect to any solutions that are implemented.

  • DescriptorApiRevampProposal describes and discusses a revamped API to allow other module descriptor formats.
  • <grab-file> ProxySupport add support for the build process to grab dependency files behind a http proxy server.
  • InterceptorOrderingProposal describes better ways to handle the ordering of interceptors for a service. implemented in 1.0-alpha-4
  • ConditionalContributionsProposal describes an even more dynamic approach to configuring services.
  • ServiceImplementationSwitch an alternative to ConditionalContributionsProposal
  • ServicePreloadProposal concerns early loading of key services. implemented in 1.0-alpha-5 as configuration hivemind.EagerLoad
  • UnitOfWorkProposal describes a shift in how services are acquired and managed within a thread.
  • ModuleResourcesProposal a way in which HiveMind modules can define/provide resources which are different and complimentary to services.
  • NotXMLProposal if XML is a problem, what's the solution?
  • PrivatesProposal reduce clutter, keep some services hidden Implemented in 1.1-alpha-1
  • HiveMindElementImprovementProposal describes addition of basic utility methods to org.apache.hivemind.Element
  • CentralizedErrorReportingProposal don't like HiveMind's approach to reporting errors? Roll your own. Implemented in 1.0
  • PrototypeBeanFactory create plain java beans with the same configuration options like a service.
  • PojoServices support of plain java beans as services.
  • ContributionOrderingProposal make ordering of configuration data declarative.
  • PartialPipelineFilterProposal allow a pipeline filter to define only a subet of the methods.
  • DocRevision is a proposal for improval of the documentation
  • Annotation support is a proposal for annotation based modules
  • No labels