Overview

There is increasing need to extend the current Glassfish implementation to support deployment of non-Java module types. So far we have heard about SIP, JBI, Phobos, JRuby and there could be even more in the future. This proposal is to talk about how we could provide a generic deployment framework to plug in various 3rd party extension modules.

This proposal is intended to address the deployment aspect of the extension module pluggability. Separate contract may be needed for container interactions. And it is only intended to address the standalone extension modules and not the embedded ones (inside ear).

SPI

The party who is responsible in enabling the deployment of such extension module will implement this SPI.

Please find the javadoc of the proposed SPI ([ArchiveDescriptor|Deployment^ArchiveDescriptor.html], [ArchiveDeployer|Deployment^ArchiveDeployer.html]) here.

The 3rd party extension container should register itself as a lifecycle module with the glassfish, and then register the SPI implementation classes during its lifecycle INIT_EVENT.

We want to provide some simple SPI to the 3rd party without requiring them to know too much about the Glassfish internals. In the meantime, they can leverage the existing glassfish logic if they wish. The glassfish code merely passes the data object around without needing to looking into the contents.

The 3rd party implementation classes of SPI will be responsible for processing all the metadata inside the extension module (including JavaEE descriptors and common annotations if they exist). And these implementation classes are also responsible for loading all the components inside the extension module (include any JavaEE components if they exist) to the extension container. This is necessary for having simple SPIs that have no dependencies on the glassfish internal implementation.

In the event when an extension module contains JavaEE components, it is up to the 3rd party to decide whether to provide their own implementation for it or leverage the existing glassfish logic. The glassfish code will provide relevant utility APIs to make such re-use relatively easy.

Note: It is not defined in this proposal how the ArchiveDeployer would locate the relevant container(s) and do the loading. The 3rd party needs to be have some glassfish knowledge if they want to utilize the existing glassfish containers. We will have a better idea of standardizing this aspect after we start the modularization work.

PluggableDeploymentInfo

This class is the central point for the interactions between the 3rd party code and the glassfish code. It contains APIs for registering/retrieving the 3rd party SPI implementation classes, and also utility APIs for the 3rd party to leverage the existing glassfish logic (more will be added in this category as needed).

Please find the javadoc of the [PluggableDeploymentInfo|Deployment^PluggableDeploymentInfo.html] class here.