|
The project provides a generic framework for accessing Java EE metadata models.
Question (arch-overall): Describe the overall architecture. Answer:This module provides the GenericJavaEEMetadataModelAPI, which is a generic framework for models of Java EE metadata expressed as either XML deployment descriptors or Java annotations. The framework itself doesn't provide access to any specific metadata. Instead, it allows metadata providers to plug in SPI implementations returning whichever kind of metadata they want to provide.
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:A module wishing to access Java EE metadata obtains a metadata model, which is encapsulated by the MetadataModel class. The client then implements a model action, represented by the MetadataModelAction class, and executes this action in the model context by calling the model's runReadAction() method:
MetadataModel<SomeMetadata> model = // ...
String result = model.runReadAction(new MetadataModelAction<SomeMetadata, String>() {
public String run(SomeMetadata metadata) {
// ... do something with metadata, e.g.
// compute a String value
return value;
}
}
The way to obtain the model itself, as well as the kinds of metadata encapsulated by MetadataModel is
metadata and metadata provider-specific and is not addressed by this API.
A metadata provider first defines a root class describing the metadata, e.g., SomeMetadata. Then the provider
implements the MetadataModelImplementation interface and
creates a MetadataModel using MetadataModelFactory.
Then the provider defines a way to return the model to its clients:
private SomeMetadataModelImplementation modelImpl = new SomeMetadataModelImplementation();
private MetadataModel<SomeMetadata> model = MetadataModelFactory.createMetadataModel(modelImpl);
/**
* Call this to retrieve the model of some metadata.
*/
public MetadataModel<SomeMetadata> getSomeMetadataModel() {
return model;
}
// ...
private class SomeMetadataModelImplementation implements MetadataModelImplementation<SomeMetadata> {
// ...
}
A metadata provider might need to provide several kinds of metadata models at once. Furthermore, since there can be many models available or for backward compatibility reasons it might be impractical to provide a method for each of the models. In this case the provider may define a method like:
public MetadataModel<T> getMetadataModel(Class<T> clazz) {
// ...
}
The types of Class which may be passed to the method is a part of the contract between
the provider and its clients.
The work should be ready for the 6.0 release.
Question (arch-quality): How will the quality of your code be tested and how are future regressions going to be prevented? Answer:All functionality mentioned in the Javadoc should be 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 NetBeans Git in the java/j2ee.metadata directory.
The default answer to this question is:
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 only.
JAR only.
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 official 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.
No I18N messages.
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:No settings defined by this module.
Question (compat-deprecation): How the introduction of your project influences functionality provided by previous version of the product? Answer:This API does not deprecate any existing public APIs.
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:No.
Question (resources-read): Does your module read any resources from layers? For what purpose? Answer:No.
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:No.
org.openide.util.Lookup
or any similar technology to find any components to communicate with? Which ones?
Answer:
No.
Question (lookup-register): Do you register anything into lookup for other code to find? Answer:No.
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: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.
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:The API defines the contracts to be supported by the implementations, but does not enforce them in any way. The API is thread-safe if implementations support the contracts correctly.
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:The API performance is constant, but the performance of the implementations might scale linearly in the number of files in a project.
Question (perf-limit): Are there any hard-coded or practical limits in the number or size of elements your code can handle? Answer:No.
Question (perf-mem): How much memory does your component consume? Estimate with a relation to the number of windows, etc. Answer:The module only contains an API delegating to a SPI, so the memory consumption is very low.
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, but implementations might. The API clients are encouraged not to call long-running methods in the AWT thread.
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:Implementations are expected to operate quickly. Clients are advised that some operations might run for a long time.