|
|
|
J2EE Server Module provides support for development of J2EE modules and framework for J2EE server management and for J2EE deployment in IDE.
Question (arch-overall): Describe the overall architecture. Answer: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.
Question (arch-usecases): Describe the main use cases of the new API. Who will use it under what circumstances? What kind of code would typically need to be written to use the module? Answer: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.
modules/ folder: (XXX names are out of date)
No change to existing APIs.
java.io.File directly?
Answer:
java.io.File is used in plugin API. The motivation is to make this API independent on
netbeans since this is an extension of the contracts defined in J2EE Deployment API.
Filesystems are used for actual access to file contents and should also be used in plugin
code.
Question (resources-layer):
Does your module provide own layer? Does it create any files or
folders in it? What it is trying to communicate by that and with which
components?
Answer:
The server registry is defined in layer, it creates folder for registration of plugins
and server instances. Server registry instance is registered in layer file. Two handlers
for xml settings are registered for the settings related to deployed modules.
Question (resources-read):
Does your module read any resources from layers? For what purpose?
Answer:
J2eeserver reads server registry contents from layer. This includes installed server
plugins as well as individual server instances (installations).
Question (resources-mask):
Does your module mask/hide/override any resources provided by other modules in
their layers?
Answer:
No.
Question (resources-preferences):
Does your module uses preferences via Preferences API? Does your module use NbPreferences or
or regular JDK Preferences ? Does it read, write or both ?
Does it share preferences with other modules ? If so, then why ?
Answer:
Module use its own way to store information about registered instances.
org.openide.util.Lookup
or any similar technology to find any components to communicate with? Which ones?
Answer:
Folder lookup is used to read the definition of plugin (the additional optional
functionality registered by the plugin).
Question (lookup-register):
Do you register anything into lookup for other code to find?
Answer:
Implementations of
META-INF/services.
Question (lookup-remove):
Do you remove entries of other modules from lookup?
Answer:
No.
System.getProperty) property?
On a similar note, is there something interesting that you
pass to java.util.logging.Logger? Or do you observe
what others log?
Answer:
No.
Question (exec-component):
Is execution of your code influenced by any (string) property
of any of your components?
Answer:
No.
Question (exec-ant-tasks):
Do you define or register any ant tasks that other can use?
Answer:
Module itself does not define any. There exist ant tasks related to this functionality in j2ee.ant.
Question (exec-classloader): Does your code create its own class loader(s)? Answer: No. Question (exec-reflection): Does your code use Java Reflection to execute other code? Answer: Reflection is used in deployment configuration code. Question (exec-privateaccess): Are you aware of any other parts of the system calling some of your methods by reflection? Answer: No. Question (exec-process): Do you execute an external process from your module? How do you ensure that the result is the same on different platforms? Do you parse output? Do you depend on result code? Answer: No. Question (exec-introspection): Does your module use any kind of runtime type information (instanceof,
work with java.lang.Class, etc.)?
Answer:
No.
Question (exec-threading):
What threading models, if any, does your module adhere to? How the
project behaves with respect to threading?
Answer:
N/A
Question (security-policy):
Does your functionality require modifications to the standard policy file?
Answer:
No.
Question (security-grant): Does your code grant additional rights to some other code? Answer:No.
java.awt.datatransfer.Transferable?
Answer:
None.
The amount of memory consumed by server registry corresponds with the number of plugins and number of registered server instances. This is a small number, typically 2 or 3, certainly less then 10. The amount of memory consumed by server libraries depends on Java Support module implementation details.
Memory consumption of configuration UI crresponds with number of open configuration editors.
Question (perf-wakeup): Does any piece of your code wake up periodically and do something even when the system is otherwise idle (no user interaction)? Answer: No. Question (perf-progress): Does your module execute any long-running tasks? Answer: Yes, starting /stopping server and performing deploymen is a long running task. It is not done in AWT thread and a progress bar is displayed. Question (perf-huge_dialogs): Does your module contain any dialogs or wizards with a large number of GUI controls such as combo boxes, lists, trees, or text areas? Answer: No. Question (perf-menus): Does your module use dynamically updated context menus, or context-sensitive actions with complicated and slow enablement logic? Answer: No. Question (perf-spi): How the performance of the plugged in code will be enforced? Answer: There is no way to enforce performance of SPI. Performance of module does depend on plugin and devmodule performance.