blob: 30cf698cbbc98dd22b4c8fa5ff54c4c782ea2e30 [file] [log] [blame]
Configuration of Properties for ORB
attributes of propery:
name String (* in front means OMG std, otherwise Sun internal)
type int, String, boolean, float, class (or any class with a public XXX( String ) constructor)
DEBUG_PROPERTY String setDebugFlags( arg ) ( , list)
*INITIAL_PORT_PROPERTY int set var, setInitialServicesPort
*ORB_ID_PROPERTY String set var
LISTEN_SOCKET_PROPERTY String add mapped to list ( , list of (S:I) )
*PI_ORB_INITIALIZER_CLASS_PREFIX.* String map to class, instantiate, add to list
SERVER_ID_PROPERTY int setPersistentServerId
ACTIVATED_PROPERTY boolean set var
GIOP transport specific properties:
GIOP_VERSION GIOPVersion set var (from
GIOP_FRAGMENT_SIZE int set var (special checks)
GIOP_BUFFER_SIZE int set var
GIOP_11_BUFFMGR int set var (really enum or else 0-2)
GIOP_12_BUFFMGR int set var (really enum or else 0-2)
GIOP_TARGET_ADDRESSING int set mapped var (really enum or else 0-3)
USE_BOMS boolean set var
USE_BOMS_IN_ENCAPS boolean set var
CHAR_CODESETS CodeSetComponent set var
WCHAR_CODESETS CodeSetComponent set var
class IntParserFactory {
static IntParser makeRangeIntParser( int min, int max ) ;
Parsing process;
- construct
- unify all args, properties into a single properties object props
- for each key k in props
- find matching ParseAction p
- p.parse( k, props.getProperty( k ) )
Design principles:
1. Get config data out of ORB
Discussion: beans framework does not work this way: instead, it creates the beans,
which are themselves both configuration data and configured component.
Two models:
a. parse props -> create config data
b. parse props -> create config data -> create components
However, long-term bean persistence can be used in either model. Separation of
concerns (and the large size of the ORB class) argues for separating data from
2. get configuration out of ORB (except for finding config class)
ORB responsibility:
- gather all property, arg data together and make it available
- load the ORB configurator and let it process the data, generate a config object
- ORB is central registry, so ORB configurator store config data in ORB
3. Extensibility is required
The ORB will have large subsystems that are pluggable components (examples: aobject adaptors,
transport plugins). Individual instances of these frameworks will have their own configuration
data. To solve this, the ORB class will provide (read-only perhaps?) access to the collected
While the component config data is not needed in the ORB, it is needed in the ORB config data
so that bean persistence can be used to create an XML version of the data.
problem: properties vs. config data: same or not?
properties: easier to use, also necessary to indicate where to get config data if not default
config data: more powerful
4. Basic principle: A parser performs an action A based on a value V when it matches a property P.
Actions can be:
configObject.setP( V )
configObject.setP( A(V) )
5. ParserActions are composable
Basic action: Object parse( String arg, String value )
which nicely handles prefix parsing and sharing of actions across multiple keys
interface Operation {
Object operate( String arg, String value )
interface OperationFactory {
Operation booleanAction() ;
Operation integerAction() ;
Operation stringAction() ;
Operation integerRangeAction( int min, int max ) ;
Operation listAction( char sep, Operation act ) ;
interface ParserAction {
void parse( String arg, String value ) ;
interface ParserActionFactory {
ParserAction setFieldAction( String fieldName ) ;
ParserAction setFieldAction( String fieldName, Operation op ) ;
ParserAction operationAction( Operation op ) ;
6. Parsers are created incrementally:
new Parser( Class configurationDataClass )
- has the parser class available for useful defaults
interface PropertyParser {
/** Option must look like a standard property name, which we require here to
* be ( JavaIdent "." ) * JavaIdent. The last java ident we will call the tail.
* If tail starts with "ORB", this option will be used in augmentWithArguments.
* This match operates as follows:
* Let name = tail stripped of its ORB prefix.
* (e.g. if tail = ORBLowWaterMark, name = LowWaterMark).
* Then if option is matched, a conversion to the result type of the method named
* get<name> is performed, and set<name> is called on the data object to set the
* result.
void addMatch( String option ) ;
void addMatch( String option, ParserAction pa )
void addPrefixMatch( String prefix, ParserAction pa )
/** First constructs a new property object that has props as its default,
* then enters args into new property object that correspond to property
* names registered in match() calls.
Properties augmentWithArguments( Properties props, String[] args ) ;
/** Parse all matched properties in props, updating data as required
* by the actions.
void parse( Properties props, ORBConfigurationData data ) ;
7. A useful model:
abstract class ConfigDataBase {
ConfigDataBase( Properties props )
and then a specific class
public class ORBConfigData extends ConfigDataBase {
ORBConfigData( Properties props )
super( props ) ;
private int foo1 = fooDefault ;
private String foo2 = fooDefault2 ;
private boolean foo3 = fooDefault3 ;
private SomeObject foo4 = fooDefault4 ;
public int getFoo1() { return foo1 ; }
// and similarly
The constructor then uses reflection to automatically handle all of these variables with a number of
a. Standard names:
private <type> foo { = <default> }
public <type> getFoo() { return foo ; }
as argument: -ORBfoo
as property: (problems here)
b. type specific parsing
int: from Integer
String: no-op
boolean: true/false (from Boolean)
Class: must be able to load class
class XXX: XXX must have a public XXX( String ) constructor
Custom parsing?
What are valid prefixes?
1. provide com.sun.corba.prefix.XXX where XXX defines a prefix to look for
(some security implications)
2. Extend security model to ORB implementation (I like this approach best so far)
8. ORB config
public interface ORBConfigurator {
/** This method is called from ORB.init after all ORB properties have been
* collected. The corba.ORB constructor will make sure that all required
* registries are initialized and empty. This constructor will also initialize
* some data used in the corba ORB public API, such as support for deferred
* asynchronous invocation. However, all regisitration including things like
* the dyanmic any factory should take place in the configurator. This method
* is resonsible for making PI ORBInitializer calls, if PI is configured.
void configure( orb ) ;
The ORB will have a default configurator named
and also a property
than can be set to the name of the ORB configurator class to use. Note that this
implementation can either be a straight Java implementation, or something more
interpretive, such as an XML-based config description.
9. We need to construct a list of all properties, and then make sure that security is respected.
The basic security check is just:
SecurityManager sman = System.getSecurityManager() ;
if (sman != null)
sman.checkPropertyAccess( key )
and also
We can construct a list of all properties as we do now, which allows the ORB
to call System.getProperties() inside a doPrivileged() block. Then we create
a subclass of java.util.Properties that overrides getProperty to
do the checkPropertyAccess( key ) call. We also need to overload the
enumerate method, either to make it illegal, call sman.checkPropertiesAccess,
or just filter it to include only the accessible properties.
And we also need to overload store, because it does not call enumerate internally.
This allows us to provide all properties to an ORBConfigurator, while still preserving
the security model. Then anyone that needs security can set up property permissions
like* to allow access to only the properties they care about.
10. ORB APIs
The ORB needs registry support including:
The ORB needs to provide access to a basic (and extensible) ORB configuration object,
which supports at a minimum all of the standard CORBA defined properties.
Also need registries for:
ObjectAdapter (actually already in SubcontractRegistry, but needs extensions to
ObjectAdapterFactory to work fully)
What does an empty ORB provide?
- Registration of all ORB components
- Request dispatching to object adapters
- Access to ORB properties data (as secure Properties object)
- Access to ORB arguments
- Access to ORB configuration data (base class, plus collections of base config
data for plugins such as OAs and transports)
- shutdown support (separate tracking of invocations vs. OA tracking in POA case?
How should this be designed?)
- INS support? (perhaps this could be pluggable too?)
- How does create_output_stream get plugged in?
- Can we separate the current IIOP transport into a TransportPluging?
- PI support
- NVList, DII
- object <-> string (which includes INS?)
- (dis)connect API for TOA (move all impl to TOAImpl?)
- typecode/any
- initial services registry
- value factory registry
- logging, other M&M support as needed
ORB classes:
core.ORB: abstract class providing internal interface
corba.ORBImpl: internal implementation of CORBA APIs
corba.ORBSingleton: the singleton ORB (not much change needed)
corba.ConfigurationDataCollector: collects all source of config data and canonicalizes it
Interceptor.PIHandler: the interface for PI
Interceptor.PIHandlerImpl: standard implementation of PIHandler
corba.ORBConfigurationData: extensible bean containing all ORB config data
11. RequestHandler and ORB
The RH interface is currently implemented in the ORB class, but might better be a separate
class. The API is currently almost the same as a ServerSubcontract. Should we regularize
this? Also, the API would need to be extended to handle shutdown properly.
Extended API:
- void run(): does not return until shutdown(boolean) is called.
- shutdown(boolean) needs to be here so that requests can be
synchhronized with shutdown. This is also a point where OAs
need to be included (currently in shutdownServants)