Summary: Configuration options in the container schema, including security, port, directory services, JNDI, Jini Lookup, JMS, and logging.
OverviewA container instance can be created using a container schema file to be used as a template configuration file for the container creation. You can use one of the pre-configured schema names when running the space.
GigaSpaces includes a default container configuration file (default-container-schema.xml) file that is suitable for most scenarios. If no <container-name>-config.xml exists in the disk, a container schema will be used. In general, if a specific space is launched then the same schema name is used for the space is used also for the container schema. For example: SpaceFinder.find("/./mySpace"); Creates a single space named mySpace as part of a container named mySpace_container, using the default schema files (default-space-schema.xml and default-container-schema.xml files). Adding the property ?schema=XXX : SpaceFinder.find("/./mySpace?schema=XXX "); will override the default and cause the space/container to use the specified XXX schema xml files.
Schema NameThe container schema xml file includes the container schema name using the following tag: <com> <j_spaces> <core> <container> <name>default</name> </container> </core> </j_spaces> </com> SecurityThe space container schema provides basic security capabilities that control whether users have FULL-CONTROL or READ-ONLY access:
<com> <j_spaces> <core> <container> <!-- Security Mode: FULL_CONTROL / READ_ONLY --> <security>FULL_CONTROL</security> <admin-password>yPoDwIychjk=</admin-password> <admin-name>gsadmin</admin-name> </container> </core> </j_spaces> </com>
Connection PortThe container can be accessed from remote applications. This allows remote application to control the container, get information about its spaces, restart spaces, remove spaces or create new spaces remotely. <com> <j_spaces> <core> <container> <!-- The port used by the container to export its stub --> <connection> <tcp-port>0</tcp-port> </connection> </container> </core> </j_spaces> </com> The <tcp-port> value used to control the port to be used to access the container directly. A 0 value means that an arbitrary free port will be used. Shutdown Hook<com> <j_spaces> <core> <container> <!-- The container shutdown in response to a user interrupt, or a system-wide event such as user logoff or system shutdown. Default value: true --> <shutdown_hook>${com.gs.shutdown_hook}</shutdown_hook> </container> </core> </j_spaces> </com> The <shutdown_hook> is a Boolean value. Setting this value to true will invoke container shutdown procedure when the user closes the container processes using CTRL + C , system shut down or similar OS event. Directory ServicesThe container manages the directory services registration. These are used to publish the container and the spaces it manage into directory services to be accessible by remote applications. The space container support registration into JNDI and the Jini Lookup service. The <directory_services> element determines where space instances are registered. It may have one of three values:
JNDIThe following instruct the container to register into the JNDI directory service: <com> <j_spaces> <core> <container> <directory_services> <!-- jndi is based on rmiregistry --> <!-- default lookup service is based on reggie --> <jndi> <!-- true if enabled, false otherwise --> <enabled>true</enabled> <!-- Default value: localhost:10098 --> <url>${com.gs.jndi.url}</url> </jndi> </directory_services> </container> </core> </j_spaces> </com> The <url> tag should include the URL to register into. The default value set using the com.gs.jndi.url is localhost:10098. When starting a space using the following format: SpaceFinder.find("/./mySpace"); The space starts RMI registry embedded and registers into it. This allows remote application to access it via the following URL: SpaceFinder.find("rmi://hostname/./mySpace"); Or: SpaceFinder.find("rmi://hostname:10098/./mySpace"); Jini LookupThe Jini Lookup service allows application to search for running services using multicast (as well as unicast) protocols. It includes several advanced options that you can't find as part of the RMI registry. See more about the Jini lookup service at the Jini Services section. <com> <j_spaces> <core> <container> <directory_services> <jini_lus> <enabled>true</enabled> <!-- If true, will start an embedded LUS and join/register the space into a LUS. Default value: true --> <start-embedded-lus>${com.gs.start-embedded-lus}</start-embedded-lus> <!-- Comma separated list of groups for lookup service Special groups: all = discover all groups none = don't register to any group For example: myGroup,group1,group2,group3 --> <groups>${com.gs.jini_lus.groups}</groups> <!-- Use this option in case multicast discovery is not working properly in any case multicast discovery will not be disabled. --> <unicast_discovery> <!-- Default value: false --> <enabled>${com.gs.jini_lus.unicast_discovery.enabled}</enabled> <lus_host>${java.rmi.server.hostname}</lus_host> </unicast_discovery> </jini_lus> </directory_services> </container> </core> </j_spaces> </com>
JMS ServicesThe Container JMS properties: <com> <j_spaces> <core> <container> <directory_services> <!-- JMS Services: if true, the JMS API supported by GS. The JMS Administrated Objects, such as ConnectionFactories, Destinations etc. must be bonded into a jndi registry. GS JMS is bonded by default in the internal jndi rmi registry. It is possible to use and external jndi registry, such as JBoss jndi reg implementation, in order to use it, the external jndi should be enabled. --> <jms_services> <!-- if true, we enable GS jms support --> <enabled>false</enabled> <!-- Binding jms admin objects in the GS internal rmiReg. --> <internal-jndi> <internal-jndi-enabled>false</internal-jndi-enabled> </internal-jndi> <!-- Binding jms admin objects on an external jndi registry --> <ext-jndi> <ext-jndi-enabled>false</ext-jndi-enabled> </ext-jndi> </jms_services> <directory_services> </container> </core> </j_spaces> </com> Embedded-ServicesThe container can start an HTTP server that is used for code download. <!-- Specify the embedded services which the GigaSpaces container will start --> <embedded-services> <!-- Starts a Webster HTTP Server embedded in the container VM Default value: true --> <httpd> <enabled>${com.gs.embedded-services.httpd.enabled}</enabled> <!-- The additional root(s) to serve code from. This is a semi-colin delimited list of directories. For example dir1;dir2 Default value: null no additional roots. The system uses the predefined roots com.gs.hom/lib;com.gs.home/lib/jini --> <additional-roots></additional-roots> <!-- The host address the server socket HTTPD (Webster) is using is bound to. Relevant for multi NIC environment. Default value: resolved to localhost ip address. --> <explicit-binding-address>${java.rmi.server.hostname}</explicit-binding-address> <!-- The host port the server socket HTTPD (Webster) is using is bound to. Default value: port 9813 but if that is busy it generates an anonymous port--> <explicit-binding-port>${com.gs.embedded-services.httpd.port}</explicit-binding-port> </httpd> </embedded-services> To modify the default setting of the embedded httpd use the following:
The container can also start an embedded Mahalo (Jini Transaction Manager). To do this, run <GigaSpaces Root>\bin\gsInstance.bat/sh and set the following option to true (it is false by default): <embedded-services> <mahalo> <!-- If true, will start an embedded Mahalo Jini Transaction Manager. Default value: false --> <start-embedded-mahalo>${com.gs.start-embedded-mahalo}</start-embedded-mahalo> </mahalo> </embedded-services> Alternatively, you can enable this option in one of the following ways:
|
![]() |
GigaSpaces.com - Legal Notice - 3rd Party Licenses - Site Map - API Docs - Forum - Downloads - Blog - White Papers - Contact Tech Writing - Gen. by Atlassian Confluence |