10.4 Application zip file content criteria

The application zip file contains all of the component files that make up an OSGi application. In order for the Application Manager to accept this as a valid application, certain criteria must be met:

•Must contain one file with a “.descriptor” extension containing the key-value pairs described above.

•Must contain at least one bundle (JAR), PAR, or WAR file.

•All application component files must be valid OSGi artifacts. That is, all JAR, PAR, and WAR files must contain a manifest file with valid OSGi meta-data in it.

•The application must be self-contained, in that any third party dependency not already delivered by the SDN Controller must be included with the application. Note that in most cases you must convert the third party JARs into OSGi bundles or embed the third party content in the application. The details on how to accomplish this is beyond the scope of this manual and you should consult the appropriate OSGi/Virgo reference documentation.

•By default, all JAR files must be signed by a trusted authority. Note that this can be disabled in the controller. See “Running the SDN Controller Without Jar-Signing Validation ” (page 68).

•You may also sign the application zip file itself. Verifying that application zip files have been properly signed, have not been modified, and use a trusted certification can be enabled through the the AppManager "verifyZips" property value in "Configurations". If enabled, only applications that are signed by a trusted authority can be downloaded to the controller.

•The application must be properly signed by an authority that is recognized by the SDN Controller. For the SDN Controller to recognize a trusted authority, the public certificate used to sign the jar and/or zip files must be placed into the /opt/sdn/admin/sdnjar_trust.jks keystore.

A Virgo Plan file will be used if provided, but is not required. The Application Manager will only deploy JAR, PAR, WAR, Plan, and “.properties” files. Other files in the application zip file are ignored unless they are declared as an artifact in a Plan file.

10.5 Application state and OSGi artifacts

In the default state, or when an application has been started, it is in the ACTIVE state and is servicing requests. Application states include the following:

Table 7 Application States

State

Description

ACTIVE

The application is running and servicing requests.

 

 

STAGED

A new application has been downloaded to the controller and is ready to be installed.

 

 

UPGRADE_STAGED

A new version of an existing running application has been downloaded to the controller and the new

 

version is ready to be installed (upgrade/downgrade).

 

 

INSTALLING

A transitive state indicating a new application is in the process of being installed.

 

 

UPGRADING

A transitive state indicating the existing application is being stopped and a new version of the

 

application is being installed.

 

 

CANCELING

A transitive state indicating a non-installed version of an application is being deleted from the controller.

 

 

DISABLING

A transitive state indicating the application is in the process of being disabled (stopping).

 

 

DISABLED

The application is disabled (stopped). A disabled application is not automatically started when the

 

controller restarted.

 

 

ENABLING

A transitive state indicating the application is being started.

 

 

10.4 Application zip file content criteria 99