Version 5

    The purpose of this document is to list the various 'modules' produced under the umbrella, along with some basic information about each module's purpose. The goal is to:

    • encourage code reuse by providing a quick reference as to what libraries are already available that may solve a given problem.

    • help engineers working on projects that consume some of these modules to understand the design intent behind the module.


    'Module' is an arbitrary term; if anyone can come up with a better one, please edit away. The meaning here is a body of code with an independent build that produces a binary that can be uploaded to JBoss's maven repository. Perhaps 'project' would be better, but 'project' is an even more overloaded term than module. In particular, here 'project' is reserved for the higher level JIRA or sense of the term; i.e. the organization the produces a set of possibly related modules.


    The following listing is organized by 'project' in that higher level organization sense; this is to make it easier to figure out who to contact to find out more about a particular module.


    See "Guidelines on Adding Entries" for more information about the intended content.


    See "JBoss AS Module Listing" for information about the various modules in the JBoss AS source tree.



    Project: JBoss Common (JIRA)




    Numerous utilities meant to be reused in a wide variety of projects. All projects should be familiar with the contents of this module. Depends on jboss-logging-spi, although not all classes do, so many utilities can be used without bringing in the dependency.



    SPI for JBoss' logging abstraction. No dependencies.



    Implementation of jboss-logging-spi that delegates to log4j. Depends on jboss-logging-spi and log4j.



    Implementation of jboss-logging-spi that delegates to java.util.logging. Depends on jboss-logging-spi.


    Implementation of the SLF4J SPI that delegates to JBoss Logging. Depends on slf4j and jboss-logging-spi.


    Project: AS Clustering ( JIRA)




    Classes used in a cluster-aware client-side proxy. API and some implementation. Depends on jboss-common-core and optionally on Remoting and JBoss AOP.



    API for interacting with the JBoss AS server-side clustering framework (e.g. HAPartition). Implementation is currently in the JBoss AS cluster although the intent is to break this out of the AS codebase into an idependent module. Depends on ha-client and optionally on JBoss Cache and PojoCache.



    SPI for JBoss AS clustering services' interaction with a distributed caching system. Not used by non-JBAS projects like EJB3 or Hibernate Second Level Cache. Intended to isolate AS code from changeable JBoss Cache implementation details. Numerous dependencies on other AS-related modules. Do not introduce a dependency on JBC itself to this module.


    Implementation of ha-server-cache-spi that makes calls into JBoss Cache and Pojo Cache.



    JBoss Cache 1.4.x series implementation of Hibernate 3.2 org.hibernate.cache.TreeCacheProvider interface, developed with performance in mind. Detailed information available in New JBoss Cache 1.4.x Based Hibernate 3.2 Cache Provider.

    Guidelines on Adding Entries


    The intent here is not to list every binary produced under the JBoss umbrella. The focus is on those that may be re-used in other projects.


    The following information should be provided for each module.  This would be better presented in a multi-column table, but 2 columns best fit the width of this wiki page.


    • 'Module' Column
      • Name of the module
      • URL to where the trunk of the code can be found in SCM
      • Maven groupId:artifactId for the binary
    • 'Usage' Column
      • What the purpose of the module is. Why would someone use this module in their project.
      • Whether it's an API, an SPI or an implementation. If an implementation, of what API or SPI.
      • Quick comment on dependencies. Doesn't need to be verbose; just a quick indication to help people who like a module's "foo" functionality to understand that to get it they will/won't have to pull in some large dependency tree to get it.


    If you add a new project section, please include an external link to something about that project, e.g. it's JIRA page, page, forum or something. A way for those interested to find out more about the project.