Skip navigation links
org.netbeans.modules.j2eeserver/4 1.115.0 1

Java EE Server Registry
Friend, Private or Third Party

See: Description

Java EE Server Registry 
Package Description
org.netbeans.modules.j2ee.deployment.common.api  
org.netbeans.modules.j2ee.deployment.devmodules.api  
org.netbeans.modules.j2ee.deployment.devmodules.spi  
org.netbeans.modules.j2ee.deployment.plugins.api
Plugin API
org.netbeans.modules.j2ee.deployment.plugins.spi
Deployment api S1S extensions
org.netbeans.modules.j2ee.deployment.plugins.spi.config  
org.netbeans.modules.j2ee.deployment.plugins.spi.support  
org.netbeans.modules.j2ee.deployment.profiler.api  
org.netbeans.modules.j2ee.deployment.profiler.spi  

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: PluginRegistration XML layer contract for registration of server plugins and instances that implement optional capabilities of server plugins. Plugins with server-specific deployment decriptor files should declare the full list in XML layer as specified in the document plugin-layer-file.html from the above link.

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.

What is New (see all changes)?

Use Cases

Deployment API Compliant Server Plugin
A server that supports Deployment API can be integrated in IDE so that J2EE modules could be deployed to it from IDE. It will not support incremental deployment, start/stop server or JSP compilation.

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.

Plugin for Server that does not support Deployment API
If a J2EE server does not support Deployment API still needs to be possible to implement a server plugin for it.

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.

Server Plugin mandatory APIs
Each server plugin is required to provide J2EE platform which devmodules may use beside else for obtaining compilation classpath.

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.

Server Plugin that implements optional APIs
In practice plugins will likely want to provide tighter integration with IDE that is specified in Deployment API. They can choose to provide any or all of the optional parts of plugin API: incremental deployment, JSP compilation, start/stop/debug server support and/or customized UI for server management.

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:

Devmodule integration
Implemetors of J2EE module support (web module, EJB module, J2EE Application, etc.) need to be able to provide UI to deploy or debug their modules on any J2EE server that has a corresponding plugin and supports given type of J2EE module. The deployment needs to work both for Deployment API based (full) deployment and incremental deployment (this needs to be transparent for the devmodules). Devmodules also need to provide UI for editing server specific configuration files existing in their sources. In addition to that, J2EE Application devmodule needs to communicate with devmodules representing J2EE module that constitute the application.

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.

Customization of Server Registry UI
Some products (JSC) requested to make it possible to replace the whole server registry UI.

Not supported in current version.

Retrieve data sources

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.

Create data source

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.

Deploy data source

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.

Exported Interfaces

This table lists all of the module exported APIs with defined stability classifications. It is generated based on answers to questions about the architecture of the module. Read them all...
Group of java interfaces
Interface NameIn/OutStabilitySpecified in What Document?
J2EEServer-devmodulesExportedFriend

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.

J2EEServerAPIExportedFriend

J2EE Server module serves as an integration point between two kinds of netbeans modules:
  • server plugins (or simply plugins) that integrate various J2EE servers in IDE
  • devmodules - netbeans modules that provide support for development of J2EE modules (web module, EJB module, J2EE Application, etc.) and need to deploy and debug them on J2EE servers.

Group of layer interfaces
Interface NameIn/OutStabilitySpecified in What Document?
PluginRegistrationExportedFriend .../api/doc-files/plugin-layer-file.html

XML layer contract for registration of server plugins and instances that implement optional capabilities of server plugins. Plugins with server-specific deployment decriptor files should declare the full list in XML layer as specified in the document plugin-layer-file.html from the above link.

Group of lookup interfaces
Interface NameIn/OutStabilitySpecified in What Document?

Implementation Details

Where are the sources for the module?

The sources for the module are in the NetBeans Mercurial repositories.

What do other modules need to do to declare a dependency on this one, in addition to or instead of a plain module dependency?
Tomcat plugin (org.netbeans.modules.tomcat5), Web Core (org.netbeans.modules.web.core), Web Projects (org.netbeans.modules.web.project).

Read more about the implementation in the answers to architecture questions.

Skip navigation links
org.netbeans.modules.j2eeserver/4 1.115.0 1