See: Description
There are two separate api/spi sets in j2eeserver. The devmodules api/spi is for j2ee development modules (web, j2ee app, etc). The plugins api/spi is for server plugins.
J2EEServer-devmodules The spi classes are to be subclassed by dev modules and to be provided as cookies on the development nodes. The api classes are to be used to add actions/properties/additional cookies to those nodes. J2EEServerAPI J2EE Server module serves as an integration point between two kinds of netbeans modules:J2EE Server Module enables using J2EE Deployment API (aka JSR88) for plugin integration. In addition to that it provides its own API for incremental deployment, JSP compilation, server life cycle management (start/stop/debugging mode). Incremental deployment deploys J2EE modules to server from a directory structure without requiring to build a J2EE module archive. It also takes the minimal action to "refresh" the module on server rahter then completely undeploying and deploying the module (or even restarting the server).
J2EE Server Module is integrated with Ant based project system (in the devmodules part) and deployment is called via custom Ant task (works only in IDE).
J2EE Server module provides basic UI for server managment and server plugins can provide customized UI.
J2EE Server module furthermore supports devmodules by managing server libraries i.e. it provides compilation classpath and registers sources and javadocs in lookup.
Provides additional methods to query for support for debugging and profiling.
Additional Callable parameter allows execution of custom code just before the actual deployment.
Added CommonServerBridge utility class to provide mapping of instance url to common api server instance.
Adds helper method to create server instance which is not persistent.
The ModuleConfiguration2 enhance the old ModuleConfiguration with new method to which the server instance id is passed in addition to J2eeModule. The creation code can be more instance specific.
In order to do this the plugin needs to add the server classes that implement Deployment API to classpath and to provide a layer file that will register the server in IDE (specifying URL, user name and password) and register a factory class from Deployment API. Beside that server plugin must also implement some other mandatory APIs.
In this case the plugin needs to implement the Deployment API interfaces ( DeploymentFactory, DeploymentManager) and delegate to whetever interface the specific J2EE server provides. An example of this is the Tomcat5 plugin implemented in tomcatint/tomcat5 module, although it only supports deployment of web modules and it also supports some optional interfaces defined by J2EE Server Module in addition to the Deployment API.
Plugins must implement J2eePlatformImpl interface and register it via J2eePlatformFactory whose instance must be registered in the module layer file. Devmodules then may access the J2eePlatform interface via the Deployment utility class.
In order to do this plugin needs to implement the additional interfaces and register their instances in module layer file and in netbeans-deployment.xml file (an additional config file with specified DTD).
Registration of various optional functionality is done via OptionalDeploymentManagerFactory.The classes and/or interfaces related to each optional functionality are:
This is achieved by devmodules implementing the devmodules API. Typically this will be done by subclassing a support class in devmodules SPI but direct implementation of devmodules API should also be possible. The mechanism of discovery of devmodule implementation is highly dependent on how devmodules are represented in IDE (e.g. as projects or DataObjects) so this part of API is the least stable.
The API package provides abstractions of J2eeModule and a J2EEModuleContainer (a module that contains other modules, such as J2EE application). Two utility classes provide direct access to Deployment and to a JSPServletFinder. The SPI package contains utility classes for implementation of J2eeModule and J2eeModuleContainer.
Not supported in current version.
Data sources created in the module and deployed on the server are accessed using J2eeModuleProvider methods. Some of the module's data source may be already also deployed on the server, in that case the client is responsible for the duplicity handling.
Retrieval from a server is done by a server plugin. Core part of the functionality is done by DatasourceManager implementation which is exposed from a server plugin through OptionalDeploymentManagerFactory.
Retrieval from a module is done with help of ConfigSupport and ConfigurationSupport implementations.
Data sources are created in a module if they does not exist yet on a server or in a module itself.
Data sources are stored in the server-specific format, only some common subset of attributes
(e.g. JNDI name, username, url, ...) is provided by a creator.
Data source creation is done with help of ConfigSupport and ConfigurationSupport implementations. In case of conflict with existing data source, the first conflicting data source is passed to the thrown DatasourceAlreadyExistsException.
Data sources stored in a module are deployed (registered) on a module's target server at the beginning
of a module deployment.
Data sources stored in a module are retrived and passed to a
DatasourceManager instance
for deploying (registering) on the server.
All module data sources having a conflict with some existing server data source are passed to the thrown
DatasourceAlreadyExistsException.
|
|
|
The sources for the module are in the Apache Git repositories or in the GitHub repositories.
Read more about the implementation in the answers to architecture questions.