11.2 Application Object
| Description | An application in open-spaces is a collection of processing units.
|
Contained
Lists |
| 1 |
| Name | jar |
| Type | jar
|
| Description | The list of jarBases (including the processingUnitList and the gridJarList) within this application.
|
| Indexed property | name |
|
| |
| 2 |
| Name | processingUnit |
| Type | processingUnit
|
| Description | The list of jarBases (including the processingUnitList and the gridJarList) within this application.
|
| Indexed property | name |
|
| |
| 3 |
| Name | deploymentOption |
| Type | deploymentOption
|
| Description | The list of deployment-options for the application. The processing-unit can also have a list of deployment-options.
The deployment-options defined at the application level are the default options for the application as a whole. If the name and
location in the application deployment-option matches the name and location in the processing-unit deployment-option then the
processing-unit's deployment-option will take precedence.
|
| Indexed property | name |
|
| |
| 4 |
| Name | machineEstate |
| Type | machineEstate
|
| Description | The machine-estate is the list of machines that can be used in the deployment process.
The machine-estate is independent of the deployment-options so that a machine-estate can be used in multiple deployments.
The link between a machine-estate and and a specific deployment is the allocation attribute on the deployment-option.
You only need specify names for machines for a fixed estate (in-house or data-center), where the machines exist physically.
When you deploy to a cloud environment, you only need to specify the class and count of machines you need;
the actual machines will be allocated dynamically.
|
| Indexed property | name |
|
| |
| 5 |
| Name | coordinator |
| Type | coordinator
|
| GenerateAllList | false |
|
| |
| 6 |
| Name | dataSource |
| Type | dataSource
|
| GenerateAllList | false |
|
|
Inherited
properties |
|
11.2.1 Property 'configProperties'
|
| Description | There are three configProperties values available:
- in the application - this gives an overall default for any values that are not specified at a lower level
- in the deployment - this gives a per-deployment value.
For example, deployments to Amazon EC2 and to in-house machines will need different values for the transaction logger.
You could specify one value in the application's configProperties for in-house testing,
and then override it with per-deployment values for Amazon deployments.
- puDeployment values. This is the most precedent value.
There aren't many CloudTran properties that need specifying at this level.
However there may be application-specific test values that need specifying at the PU deployment level.
This property is a multi-line value, which should be in the format of Java properties (i.e. lines of "property=value").
|
| Type | String |
11.2.2 Property 'constraintExceptionType'
|
| Description | The constraintExceptionType is the type of the exception which is thrown if the constraint fails.
It can be any valid class name - probably defined by a 'jwclass'. It could be, for example, a specific class of business exception which should be thrown for this constraint.
If this is not in the same package as the build module (e.g. in the EJB Jar or Ear), then the name should be qualified by the package name.
The constraintExceptionType is available on constraints, objects and assemblies, and can also be set in the top level properties build file (e.g. build.jwp).
Because this is a delegated property, the actual value used is whichever instance is encountered first, working up from the validation object.
This means it is very easy to specialise the exceptions thrown in part of the specification tree (e.g. one session EJB), leaving the rest unchanged.
Failing any value at all, 'RuntimeException' is used ... but clearly this should not be used in production systems.
|
| Type | String |
11.2.3 Property 'customTemplateDirectory'
|
| Description | This only needs to be specified if you want to customize the standard generation templates for your requirements; you can ignore it otherwise.
If specified, this should be the template directory (equivalent to the standard resource/x/control level)
which defines the specific properties and templates you want to implement.
|
| Type | String |
11.2.4 Property 'description'
|
11.2.5 Property 'esb'
|
| Description | This is the default enterprise service bus to be used in the messaging of this application.
Normally, you only need to specify the ESB type here - because most applications only use one ESB.
If message processor model elements - senders, receiver, subscriber, browser - do not specify an ESB type,
the value specified here is used.
If your application has multiple service buses, you can specify the standard one here.
Then you just need to specify the esb on other models elements that use non-standard ESBs.
The current configuration allows you to specify Mule 3 as your default ESB.
Mule 3 is under development, so currently "Mule 3" ends up using Mule 2.2.1.
|
| Type | String |
| Choices |
| none (default) |
| mule_2.2.1 |
| mule_3.0.0 |
|
11.2.6 Property 'fifo'
|
| Description | This is the application-level default for the FIFO (first-in, first-out) property for JavaBeans.
As this is a delegated value, the 'fifo' properties in spaces and JavaBeans will
delegate up to the value - so it sets the default for all other objects.
The default for this value is normally false,
so JavaBeans in spaces will <b><u>not</u></b> be guaranteed to be read/taken in the same order they were written.
This follows the GigaSpaces defaults where fifo is false.
You can override this default by setting fifo=true in resources/giga-spaces/control/application/component.properties.
See customization 10 (in the directory jeewiz/customizations/giga-spaces).
|
| Type | boolean |
11.2.7 Property 'generateRestService'
|
| Description | This determines whether all the services in this application should be exposed as RESTful service.
This sets the default if the generateRestService not specified for a given service.
The default can be overridden by specifying tru or false for the specific service.
|
| Type | boolean |
| Default | false |
11.2.8 Property 'name'
|
| Description | The name for the Application EAR file.
|
| Type | String |
| Default | TheApplication |
11.2.9 Property 'package'
|
| Alias | namespace |
| Description | This is the package attribute: it declares the name of the package that this interface (or class, or entity, etc.) belongs to.
It can be used on
- reference types (interfaces and classes) and all their derivatives
- associations
- assemblies of model-objects
- containers of same, like jars.
It uses delegation of responsibility to search its parent chain. For example, in the J2EE realm, this means that the package can be specified on (working up the containment chain):
- an entity,
- or its ejb-jar,
- or the application,
- or in the assembly
- or in the build properties '.jwp' file.
If none of these is specified the package will be null.
Null packages are not recommended but legal for simple Java builds.
For larger systems, null packages are not allowed.
The combination of the package and class name (i.e. the fully-qualified Java classname) must be unique
across all reference types and their derivatives in a build.
|
| Type | String |
11.2.10 Property 'saas'
|
| Description | This flag will signals to the generator that the application should be SaaS ready.
If it is set to true all entity will have an extra field which identifies the company. Some interfaces will also change
to include the compmany/tenant id, so every company will be able to work with only it's own data.
|
| Type | boolean |
11.2.11 Property 'versionControl'
|
| Description | This to allow the modeller the ability to override the application's policy on version-control. Currently the system default is true.
This allows the modeller the ability to switch it off at the application level without having to amend every entity
|
| Type | boolean |
| Default | true |
|
