|
|
|
java.io.File directly?
Answer:
B-tree storage implementation works directly with files since it is a standalone
database independent from NetBeans and OpenAPI. Btree-files
- For every storage the b-tree database
creates two permanent files - index file (*.btx) and data file (*.btd). When modifying
data in the database the b-tree creates an additional backup file (*.btb), which is deleted
when the database is shutdown. In the standalone mode, placement of the DB files can be
specified in a system property. When running in NetBeans, the files are located under
&nbuserdir/var/cache/mdrstorage directory.
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. It uses layer to register instances into lookup. The module also creates a new folder
named MDRepositories, which other modules can use to register their own repositories.
The MDR module registers the default repository.
Question (resources-read):
Does your module read any resources from layers? For what purpose?
Answer:
Yes. The implementation of MDR manager reads list of registered metadata repositories.
Currently the registration and discovery of the repositories works using a special
dataloader for *.mdr files. So the repository needs to be registered in the layer
as a file with "mdr" extension. Properties of the repository are declared as file
attributes. This is an obsolete thing which we plan to replace with a different
registration mechanism before the release. Here are the changes we envision
(any comments are welcome):
org.openide.util.Lookup
or any similar technology to find any components to communicate with? Which ones?
Answer:
The lookup is used to find implementation of MDRManager, XMIReader, XMIWriter, JMIMapper and
some other less significant interfaces from the api package. The order is important in case
of JMIMapper and XMIReader instances, since we have several implementations of those
(e.g. a JMIMapper that generates java sources and a JMIMapper that generates class files directly).
User is able to choose which one to invoke by changing order of them in the lookup.
Question (lookup-register):
Do you register anything into lookup for other code to find?
Answer:
It registers instances of the following classes:
System.getProperty) property?
Answer:
org.netbeans.mdr.persistence.btreeimpl.btreestorage.MDRCache.threshhold
It is used in MDRCache to set cache threshhold.
If you go through the source code, you can find more uses of system properties, however
those are only effective if the MDR is running as a standalone thing - when running as a
module in NetBeans the properties are ignored.
The following properties can be set in the module layer when MDR is running as a module in NetBeans.
storage
Determines a factory class that is used to create storages. If it is not set, a factory for btree storage is taken defaultly.
org.netbeans.mdr.persistence.btreeimpl.uuid
Btree storage takes the value as uuid of the storage.
org.netbeans.mdr.persistence.btreeimpl.filename
Used to set the name of btree storage. It determines names of files used to store data of the storage.
org.netbeans.mdr.persistence.memoryimpl.id
Used to set uuid of memory storage.
org.netbeans.mdr.persistence.memoryimpl.fileName
Used to set the name of a file, which is used to store data of memory storage permanently.
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?
WARNING: Question with id="exec-ant-tasks" has not been answered!
Question (exec-classloader):
Does your code create its own class loader(s)?
Answer:
MDR dynamically generates implementations of JMI interfaces. It defines these classes using its
own classloader.
Question (exec-reflection):
Does your code use Java Reflection to execute other code?
Answer:
Yes - this is used to access metamodel specific API in the implementation of the JMI reflective API.
Question (exec-privateaccess):
Are you aware of any other parts of the system calling some of
your methods by reflection?
Answer:
Implementation of MDR storage is pluggable. MDR creates the right storage factory based
on its class name provided in start up properties using reflection. Same holds for
pluggable transaction mutex. Custom implementations of collections use
java.lang.reflect.Array to implement toArray method.
Reflection is used to implement JMI reflective operations in RefStruct and RefEnum interfaces
to access implementations of JMI non-reflective features. Bytecode generators use reflection
to access features of JMI interfaces.
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:
Implementation of JMI objects are expected to be subclasses of MDR handler classes.
Question (exec-threading):
What threading models, if any, does your module adhere to?
Answer:
The MDR introduces transaction mutex, which ensures atomicity of every operation.
Each operation starts a transaction (uses mutex to lock the repository) upon the entrance
and ends the transaction (i.e. releases the mutex) when exiting. The default implementation
of the mutex supports multiple readers or single writter. The whole MDR is thread safe.
There is one event-dispatching thread created for every repository instance. It takes care
of asynchnorous event notifications.
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:TBA
java.awt.datatransfer.Transferable?
Answer:
None.
Built on May 4 2005. | Portions Copyright 1997-2005 Sun Microsystems, Inc. All rights reserved.