|
|
|
Allows UI presentation of server instance without dependency on a server specific API (like j2eeserver).
Question (arch-overall): Describe the overall architecture. Answer:The Server module provides the CommonServerSPI that contains SPIs needed for the UI presentation of servers (anykind) and cloud providers. It covers the services tab, server manager, server add wizard, cloud manager and cloud add wizard.
There is also API part of the module CommonServerAPI that provides API representation of the server and cloud instances. API access if required in future will be placed here.
Clients can provide its instances through the SPI. They can also provide wizards to define UI way for the server or cloud instance addition. It is done with CommonServerLayerSPI where the SPIs implementation must be registered.
To provide easy way for clients to persist properties of its instances easily, module provides support API CommonServerPropertiesAPI to do that. This support API is not mandatory for clients to use in any way.
ServersNodeActions
-
By registering actions to Servers/Actions you
can extend the list of popup actions on Servers node in
Services tab.
CloudNodeActions
-
By registering actions to Cloud/Actions you
can extend the list of popup actions on Cloud node in
Services tab.
serverNodeHidden
-
If the action registered in Servers/Actions or Cloud/Actions folder
has getValue("serverNodeHidden") == Boolean.TRUE, then
it will not be shown in the popup menu.
By adding wizardMessage attribute you tell the
Add Server...
or Add Cloud...
action to display this message as an
option, if no servers are yet registered. If user agrees, your
action will be called then to enable some server providers.
The action then receives command noui
,
to know that it shall only enable given functionality, but there
is no need to show user anything.
By adding additional attributes to files in Servers/Actions or Cloud/Actions
folder you can influence behaviour of the Servers
and Cloud
node.
By adding property-something attribute you identify
an action that will be called as soon as the node is expanded and
System.getProperty("something") is non-null.
By adding config-something attribute you identify
an action that will be called as soon as the node is expanded and
FileUtil.getConfigFile("something") is non-null.
In all of these cases, the action receives command noui
,
to know that it shall only enable given functionality, but there
is no need to show user anything.
These attribute based APIs shall be seen as temporary and subject to replacement. Please notify us as soon as you start to use them.
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:
An external module can register itself as the server instance provider.
In order to do that it must register the implementation of
ServerInstanceProvider
in Servers or Cloud folder in the layer.xml.
When this is done the module will handle displaying of instances at appropriate IDE dialogs and views. Note that more specific SPIs can still be required for the technology specific dialogs and actions. This module covers the areas where the "common server" term makes sence.
Every ServerInstance returned by the provider is handled by this module. Some features of the ServerInstance are not mandatory (as described in javadoc). If new instances can be added or removed during the lifecycle of external module it has to notify all listeners of the ServerInstanceProvider.
An external module can register the wizard(s) in order to allow the user
to add new instances. In order to do that it must register the implementation of
ServerWizardProvider
in Servers or Cloud folder in the layer.xml.
When this is done the module will offer this wizard in UI (at contexts where it makes sense).
The Commons Server SPI implemetor has to usually implement persistence of its instances somehow. There are many ways how this can be done. To make it easier InstancePropertiesManager can be used. It provides a way how to store and retrieve properties of the server instance.
Question (arch-time): What are the time estimates of the work? Answer:The code is already written. This would be the right place for several support APIs in future. Current functionality should be stabilized after 6.1 release.
Question (arch-quality): How will the quality of your code be tested and how are future regressions going to be prevented? Answer:As this is SPI and implementation consists mostly of UI classes only the core (non UI) implementation classes are covered by unit tests.
Question (arch-where): Where one can find sources for your module? Answer:
The sources for the module are in the Apache Git repositories or in the GitHub repositories.
These modules are required in project.xml:
None.
Question (dep-platform): On which platforms does your module run? Does it run in the same way on each? Answer:No known platform dependencies.
Question (dep-jre): Which version of JRE do you need (1.2, 1.3, 1.4, etc.)? Answer:1.5
Question (dep-jrejdk): Do you require the JDK or is the JRE enough? Answer:JRE is enough.
Just the single JAR file.
Question (deploy-nbm): Can you deploy an NBM via the Update Center? Answer:Yes.
Question (deploy-shared): Do you need to be installed in the shared location only, or in the user directory only, or can your module be installed anywhere? Answer:Anywhere.
Question (deploy-packages): Are packages of your module made inaccessible by not declaring them public? Answer:Only API and SPI packages are exported.
Question (deploy-dependencies): What do other modules need to do to declare a dependency on this one, in addition to or instead of the normal module dependency declaration (e.g. tokens to require)? Answer:Nothing.
Yes.
Question (compat-standards): Does the module implement or define any standards? Is the implementation exact or does it deviate somehow? Answer:No.
Question (compat-version): Can your module coexist with earlier and future versions of itself? Can you correctly read all old settings? Will future versions be able to read your current settings? Can you read or politely ignore settings stored by a future version? Answer:Yes. No settings stored.
Question (compat-deprecation): How the introduction of your project influences functionality provided by previous version of the product? Answer:The part of the j2eeserver handling the basic server instance UI should not be used anymore.
java.io.File directly?
Answer:
No.
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:
Yes. The module contains a standard layer which describes menu items, actions and services. The
folders Servers and Cloud where instance providers and wizards are registered, are created.
The module search for all classes implementing
ServerInstanceProvider
and
ServerWizardProvider
located under the Servers and Servers folder.
It uses Lookup in order to do that.
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:No.
org.openide.util.Lookup
or any similar technology to find any components to communicate with? Which ones?
Answer:
Yes.
Lookups.forPath--.
The module search for all classes implementing
ServerInstanceProvider
and
ServerWizardProvider
located under the Servers or Cloud folder.
Order is not important.
Yes. UI node is registered in UI/Runtime folder and manager action is
registered in Menu/Tools folder.
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:No.
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:No.
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. Server instance implementations could execute such actions though (especially executing external scripts which start/stop a server).
Question (exec-introspection): Does your module use any kind of runtime type information (instanceof,
work with java.lang.Class, etc.)?
Answer:
Yes.
Question (exec-threading): What threading models, if any, does your module adhere to? How the project behaves with respect to threading? Answer:SPI implementation (methods) can be called from any thread unless explicitely mentioned in javadoc.
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.
None.
Question (format-dnd): Which protocols (if any) does your code understand during Drag & Drop? Answer:None.
Question (format-clipboard): Which data flavors (if any) does your code read from or insert to the clipboard (by access to clipboard on means calling methods onjava.awt.datatransfer.Transferable?
Answer:
None.
No.
Question (perf-exit): Does your module run any code on exit? Answer:No.
Question (perf-scale): Which external criteria influence the performance of your program (size of file in editor, number of files in menu, in source directory, etc.) and how well your code scales? Answer:Performance scales linearly with the number of providers and instances, but usually the numbers are small.
Question (perf-limit): Are there any hard-coded or practical limits in the number or size of elements your code can handle? Answer:None known.
Question (perf-mem): How much memory does your component consume? Estimate with a relation to the number of windows, etc. Answer:The small amount memory is consumed by registry of providers. The module does not hold any large structures belonging to it (however an external module can hold large structure in its implementation). Typical (real-life) number of providers is less than 10.
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:No.
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:Not directly. Possibly the SPI implementation can contain such customizers.
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:SPI related actions should not invoke any time consuming operation.