Define a new CI type

You can define new configuration item (CI) types in XL Deploy. When you specify a new type, its base (a concrete Java class or another synthetic type), and its namespace, the new type will become available in XL Deploy. This means the CI type can be a part of deployment packages and created in the Repository browser. Each of the three categories of CIs (deployables, deployeds, and containers) can be defined this way.

You can specify the following information when defining a new type:

Information

Required

Description

type

Yes

The CI type name.

extends

Yes

The parent CI type that this CI type inherits from.

description

No

Describes the new CI.

virtual

No

Indicates whether the CI is virtual (used to group together common properties) or not. Virtual CIs can not be used in a deployment package.

deployable-type

No

The type of deployable CI type that this CI type deploys. Only relevant for deployed CIs.

container-type

No

The type of CI container that this CI type is deployed to. Only relevant for deployed CIs.

generate-deployable

No

The type of deployable CI to be generated. This property is specified as a nested element. Only relevant for deployed CIs.

Define a deployable CI

<typetype="tomcat.DataSource"extends="tomcat.JndiContextElement"deployable-type="jee.DataSourceSpec"description="DataSource installed to a Tomcat Virtual Host or the Common Context"><generate-deployabletype="tomcat.DataSourceSpec"extends="jee.DataSourceSpec"/><propertyname="driverClassName"description="The fully qualified Java class name of the JDBC driver to be used."/><propertyname="url"description="The connection URL to be passed to our JDBC driver to establish a connection."/></type>

You can also copy default values from the deployed type definition to the generated deployable type. Here is an example:

<typetype="tomcat.DataSource"extends="tomcat.JndiContextElement"deployable-type="jee.DataSourceSpec"description="DataSource installed to a Tomcat Virtual Host or the Common Context"><generate-deployabletype="tomcat.DataSourceSpec"extends="jee.DataSourceSpec"copy-default-values="true"/><propertyname="driverClassName"description="The fully qualified Java class name of the JDBC driver to be used."default="{{DATASOURCE_DRIVER}}"/><propertyname="url"description="The connection URL to be passed to our JDBC driver to establish a connection."default="{{DATASOURCE_URL}}"/></type>

Important: When you use generate-deployable, properties that are hidden or that are of kind ci, list_of_ci, or set_of_ci will not be copied to the deployable.

The following example shows an example of defining a deployable manually:

The tc.WarModule CI (a deployed) is generated when a tc.War (a deployable) is deployed to a tc.Server (a container). The new CI inherits all properties from the udm.BaseDeployedArtifact CI and adds the required property changeTicketNumber. The startWeight property is hidden from the user with a default value of 1.

Define an embedded CI

An embedded CI is a CI that is embedded (part of) another CI. The following example shows how to define an embedded CI that represents a portlet contained in a WAR file. The tc.Portlet embedded CI can be embedded in the tc.WarModule deployed CI, also shown:

The tc.WarModule has a portlets property that contains a set of tc.Portlet embedded CIs.

In a deployment package, a tc.War CI and its tc.PortletSpec CIs can be specified. When a deployment is configured, a tc.WarModule deployed is generated, complete with all of its tc.Portlet portlet deployeds.

Define as-containment CI types

One of the properties that you can set for CI types is as-containment. This models the CI as a parent/child containment instead of as a foreign key reference in the JCR tree, ensuring that when the parent CI is undeployed, the child CI will also be undeployed.

The following example shows the use of the as-containment property. Type modifications are needed for foreignDestinationNames and foreignConnectionFactoryNames because properties of kind set_of_ci are not copied to the deployable.