Archivo de manifiesto de característica de Liberty

Una característica Liberty consta de un archivo de manifiesto de característica y una colección de uno o más paquetes OSGi que proporcionan clases y servicios que corresponden a una prestación concreta en el entorno de tiempo de ejecución Liberty. Puede encontrar la introducción del formato de un manifiesto de característica y el significado de cada cabecera en el archivo de manifiesto.

El archivo de manifiesto de característica en Liberty utiliza el formato de metadatos de servicio de subsistema en la especificación OSGi Enterprise R5. Una característica se define mediante un archivo de manifiesto de característica, o un archivo .mf, que se almacena en el directorio lib/features, y debe utilizar un tipo personalizado de subsistema: osgi.subsystem.feature. Para obtener más información sobre la sintaxis de manifiesto OSGi, consulte la sección 1.3.2 de la especificación principal OSGi.

Nota: En el archivo de manifiesto de característica, los atributos adoptan la forma nombre=valor, pero las directivas adoptan la forma nombre:=valor.
Se definen las siguientes cabeceras:
Tabla 1. Cabeceras de un archivo de manifiesto de característica.

Esta tabla muestra las cabeceras de un archivo de manifiesto de característica en Liberty. La primera columna muestra una lista de cabeceras. La segunda columna muestra la descripción de cada cabecera y la tercera columna indica si la cabecera es necesaria.

Cabecera Descripción Necesario o no
Subsystem-ManifestVersion El formato de la versión del archivo de manifiesto de característica. Debe establecerse en 1. No
Subsystem-SymbolicName El nombre simbólico de la característica y los atributos o directivas.
Subsystem-Version La versión de la característica. Consulte la sección 3.2.5 de la especificación principal de OSGi para ver los detalles de cómo se define. No
Subsystem-Type El tipo de subsistema de la característica. Todas las características son actualmente del mismo tipo de subsistema: osgi.subsystem.feature.
Subsystem-Content El contenido de subsistema de la característica. Es una lista separada por comas de paquetes y subsistemas que son necesarios para ejecutar esta característica. Si desea permitir que se configure la característica automática en el archivo server.xml, debe tener la cabecera de capacidad que contiene las características necesarias, y además definirlas en el contenido del subsistema.

[17.0.0.3 and later]Además, tendrá que especificar el sistema operativo, si el contenido no es válido para todos los sistemas operativos. El atributo de sistema operativo soporta el valor no sensible a las mayúsculas y minúsculas de z/OS. Los demás valores se ignoran y todos los archivos se instalan en todas las plataformas, pero los archivos marcados con z/OS no se instalan en máquinas que no sean z/OS. Se omite cualquier contenido que no es válido para el sistema operativo de instalación.

Subsystem-Localization La ubicación de los archivos de localización de la característica. No
Subsystem-Name Un nombre abreviado, legible para los usuarios, de la característica. Este valor se puede localizar. No
Subsystem-Description Descripción de la característica. Este valor se puede localizar. No
IBM-Feature-Version La versión de este tipo de subsistema. Debe establecerse en 2.
IBM-Provision-Capability La cabecera de capacidad que describe si una característica puede suministrarse automáticamente. No
IBM-API-Package Los paquetes de API que esta característica expone a las aplicaciones, las características de otras extensiones del producto y el kernel de Liberty. No
IBM-API-Service Los servicios OSGi que expone esta característica a las aplicaciones OSGi. No
IBM-SPI-Package Los paquetes de SPI que esta característica expone a las características de otras extensiones del producto y el kernel de Liberty. No
IBM-ShortName Nombre abreviado de la característica. No
IBM-AppliesTo Versión de Liberty a la que se aplica esta característica. No
Subsystem-License Tipo de licencia de esta característica. No
IBM-License-Agreement Prefijo de la ubicación de los archivos del acuerdo de licencia. No
IBM-License-Information Prefijo de la ubicación de los archivos de información de la licencia. No
[18.0.0.1 and later]IBM-Maven-Dependency [18.0.0.1 and later]Las coordenadas Maven de las dependencia de especificación Java™ que son necesarias para esta característica [18.0.0.1 and later]No
IBM-App-ForceRestart Especifica que las aplicaciones se van a reiniciar cuando se instale o se desinstale la característica en un servidor en ejecución. No

Subsystem-SymbolicName

La sintaxis de esta cabecera coincide con la sintaxis de Bundle-SymbolicName para un paquete. Tiene un nombre simbólico que sigue la sintaxis de estilo de nombres de paquete y, opcionalmente puede utilizar un conjunto de atributos y directivas.

Se da soporte a los siguientes atributos:
  • superseded. Este atributo indica si esta característica está reemplazada por una o varias características o uno o varios elementos de funcionalidad. Tiene uno de los valores siguientes:
    • true: la característica está reemplazada.
    • false: la característica no está reemplazada.
    Este atributo es opcional; el valor predeterminado es false.

    Para obtener más información, consulte Características reemplazadas de Liberty.

  • superseded-by. Este atributo especifica una lista separada por comas de las características que reemplazan a esta característica, si hay alguna, y es opcional.
Se admiten las siguientes directivas:
  • visibility. Esta directiva toma uno de los valores siguientes:
    • public: característica que se considera que es API. Las herramientas de desarrollador admiten la característica, para utilizarla en el archivo server.xml y en la salida de los mensajes.
    • protected: se considera que la característica es SPI. Las herramientas de desarrollador no admiten la característica, para utilizarla en el archivo server.xml o en la salida de los mensajes. Se proporciona la característica para que los extensores puedan utilizarla para crear características de nivel superior.
    • private: (valor predeterminado), la característica es interna al producto. No se admite la característica para utilizarla en el archivo server.xml ni para que las características de extensor hagan referencia a ella. La característica se puede cambiar en cualquier momento, incluso entre fixpacks.
Por ejemplo:
Subsystem-SymbolicName: com.ibm.example.feature-1.0; 
    visibility:=public; superseded=true; superseded-by="com.ibm.example.feature-2.0"
Si un nombre de característica de la lista superseded-by aparece entre corchetes, [], esta característica se ha separado de la característica que la reemplaza. En el ejemplo siguiente, la característica appSecurity-1.0, que contiene las características servlet-3.0 y ldapRegistry-3.0, se reemplaza por la característica appSecurity-2.0, que no contiene las características servlet-3.0 y ldapRegistry-3.0:
IBM-ShortName: appSecurity-1.0
Subsystem-SymbolicName: com.ibm.websphere.appserver.appSecurity-1.0; visibility:=public;
superseded=true; superseded-by="appSecurity-2.0, [servlet-3.0], [ldapRegistry-3.0]"
Para obtener más información, consulte Características separadas.
Procedimientos recomendados: Si las herramientas del desarrollador deben mostrar la característica, debe ser public. Si la característica está disponible sólo para partes de confianza, debe ser protected. Si la característica es interna y está sujeta a cambios en cualquier momento, debe ser private.
  • singleton. Esta directiva toma uno de los valores siguientes:
    • True. La característica es un singleton.
    • False. La característica no es un singleton.

    La directiva singleton es opcional. El valor predeterminado es False.

    Esta directiva se utiliza para declarar que una característica determinada es un singleton. Un singleton indica que solo se puede cargar una sola versión de una característica determinada en el tiempo de ejecución en un momento dato. De forma predeterminada, las características no son singletons. Si la característica es un singleton y la configuración del servidor requiere varias versiones de una característica determinada, el tiempo de ejecución intentará encontrar una versión común que toleren todas las características necesarias. Para obtener más información sobre la tolerancia de versiones, consulte la directiva ibm.tolerates en Subsystem-Content.

    Cuando una característica es un singleton, el valor de nombre simbólico tiene el formato "<singleton feature name >-<singleton version>", donde el nombre y la versión están separados por un guión. El nombre de la característica singleton puede contener guiones, pero los caracteres a continuación del último guión se interpretan como la versión del singleton. Si los caracteres a continuación del último guión no son una versión válida, se utilizará una versión de singleton de 0.0.0 y se usará todo el nombre simbólico como el nombre de singleton. La versión de singleton se utiliza al procesar "ibm.tolerates directives under Subsystem-Content; por ejemplo:
    Subsystem-SymbolicName: com.ibm.example.feature-1.0; 
        visibility:=public; singleton:=true

Subsystem-Content

Esta cabecera define el contenido de la característica, tanto para el tiempo de ejecución, como para la instalación. Sigue la misma sintaxis de cabecera que la especificación Subsystem con la sintaxis siguiente:
Subsystem-Content ::= content ( ',' content )*
        content ::= unique-name ( ';' parameter )*
        unique-name ::= unique-name        (see OSGi core spec section 1.3.2)
unique-name utiliza el formato de las cabeceras Bundle-SymbolicName o Subsystem-SymbolicName. Se da soporte a los siguientes atributos:
  • version: el rango de versiones que deben coincidir cuando se busca un paquete. Sólo se seleccionan los paquetes en este rango. Un ejemplo típico del rango de versiones es [1,1.0.100).
  • type: el tipo de contenido que se suministra. Puede especificar cualquier valor para indicar el tipo de contenido; algunos tipos darán como resultado paquetes instalados e iniciados en la entorno OSGi de un servidor que utiliza la característica, todos los tipos hacen que se incluya el contenido en un paquete de instalación que incluye la característica. Los valores siguientes están predefinidos:
    • osgi.bundle - Este es el valor predeterminado e indica un paquete OSGi que se debe proporcionar en el marco de trabajo OSGi del servidor y del paquete de instalación.
    • osgi.subsystem.feature - Este valor indica que la característica se debe proporcionar tanto en el marco de trabajo OSGi del servidor, como en un paquete de instalación. Estas características tienen que utilizar el nombre especificado en la cabecera Subsystem-SymbolicName.
    • jar - Este valor indica que un archivo JAR se debe incluir en un paquete de instalación y se selecciona utilizando una combinación de un rango versiones, un valor de ubicación, o ambos.
    • file - Este valor indica que el archivo identificado en el atributo location se debe incluir en un paquete de instalación.
Se admiten las siguientes directivas:
  • location: la ubicación del paquete. Para un paquete o tipo JAR, este valor puede ser una lista separada por comas de directorios que representan una vía de búsqueda. Para cualquier tipo, este valor podría ser una única entrada que apunta directamente al recurso y se podría especificar como un URL de archivo. Las vías de acceso podrían ser absolutas o relativas. Las vías de acceso relativas se resuelven en relación a la ubicación de la extensión del producto que contiene la característica. Para una característica de usuario, se utiliza la ubicación de la extensión de producto predeterminada, que es ${wlp.user.dir}/extension. La ubicación de las extensiones de producto no predeterminadas se declara en la propiedad com.ibm.websphere.productInstall en su archivo de propiedades en el directorio ${wlp.install.dir}/etc/extensions.
    Por ejemplo:
    Subsystem-Content: com.ibm.websphere.appserver.api.basics; version="[1,1.0.100)"; type=jar; location:="dev/api/ibm/,lib/",
                       com.ibm.websphere.appserver.spi.application; 
    				   location:="dev/spi/ibm/com.ibm.websphere.appserver.spi.application_1.0.0.jar"; type="jar",
                       com.ibm.websphere.appserver.spi.application_1.0.0-javadoc.zip;
    				   location:="dev/spi/ibm/javadoc/com.ibm.websphere.appserver.spi.application_1.0.0-javadoc.zip"; type="file"
  • start-phase - La fase de inicio cuando el paquete se debe iniciar durante el arranque del sistema. La directiva start-phase puede tener uno de los valores siguientes:
    • SERVICE: este valor indica la primera fase. De forma predeterminada, se correlaciona con un nivel de inicio de 9.
    • CONTAINER: este es el valor predeterminado si no se proporciona ningún atributo start-fase. Indica la fase del contenedor en la que se inician los contenedores de aplicaciones. De forma predeterminada, se correlaciona con un nivel de inicio de 12.
    • APPLICATION: este valor indica la última fase en la que se inician las aplicaciones.
    Los paquetes también pueden definirse para que se inicien justo antes o después de estas fases añadiendo _LATE para ser posteriores o _EARLY para ser anteriores a la fase clave. Por lo tanto, si desea que se ejecuten inmediatamente después de la fase de contenedor, utilice CONTAINER_LATE, y si desea que se ejecuten antes de la fase de APPLICATION, utilice APPLICATION_EARLY.
  • ibm.tolerates: especifica la versión o versiones de singleton alternativas de una característica singleton,type=osgi.subsystem.feature, que se suministrará al sistema si hay conflictos de versión.

    El nombre exclusivo especifica el nombre simbólico de la versión preferida de una característica singleton. Si se sabe que la característica incluida funciona con otras versiones de singleton de una característica singleton determinada, estas versiones de singleton se pueden especificar utilizando la directiva ibm.tolerates. Esto proporciona mayor compatibilidad con la característica de definición en caso de que otras características definan valores de versión necesarios en conflicto de una característica singleton determinada.

    Las versiones de singleton que se listan en la directiva ibm.tolerates solo se utilizan en el caso de un conflicto de versión. La ordenación de las versiones que se listan en la directiva ibm.tolerates no es significativa; se puede seleccionar cualquier versión listada en la directiva ibm.tolerates para satisfacer los requisitos de dependencia.

    La versión o versiones toleradas de una característica singleton determinada se deben listar explícitamente en la directiva ibm.tolerates. Utilice comas para separar una lista de versiones toleradas. No se da soporte a la especificación de un rango de versiones.

    Por ejemplo:
    Subsystem-Content: com.ibm.websphere.appserver.example.featureA-1.1; ibm.tolerates:="1.2"; type="osgi.subsystem.feature",
                       com.ibm.websphere.appserver.example.featureB-1.1; ibm.tolerates:="1.2, 1.4, 1.6"; type="osgi.subsystem.feature"
    Nota:

    Las versiones toleradas no son transitivas. Esto impide que se seleccione automáticamente sin haberla probado una característica de la que dependa su característica para dar soporte a una versión posterior de una característica.

    Por ejemplo: la característica de usuario featureC-1.1 incluye sipServlet-1.1 en la cabecera Subsystem-Content de su archivo de manifiesto. sipServlet-1.1 incluye servlet-3.0 y tolera servlet 3.1. Si featureC-1.1 se ha escrito antes de que existiera servlet-3.1 y a continuación se ha añadido servlet-3.1 y lo tolera la característica utilizada por él (sipServlet-1.1), featureC-1.1 debe decidir si también tolera servlet-3.1.

    Si configura el archivo server.xml para que tenga las dos características siguientes:
    <feature>usr:featureC-1.1</feature> // incluye: sipServlet-1.1
    <feature>websocket-1.0</feature> // esta característica requiere servlet-3.1
    Verá que aparecerá un mensaje de error similar al siguiente:
    CWWKF0033E: Las características singleton servlet-3.0 y servlet-3.1 no se pueden cargar simultáneamente. 
    Las características usr:featureC-1.1 y websocket-1.0 configuradas incluyen una o más características que causan el conflicto. 
    La configuración no está soportada; actualice server.xml para eliminar características incompatibles.

    Se ha notificado este error porque featureC-1.1 no se ha seleccionado para tolerar servlet-3.1 y por lo tanto debe tener servlet-3.0, y websocket-1.0 no da soporte a servlet-3.0 y por lo tanto debe tener servlet-3.1.

    La solución es para featureC-1.1 para depender también directamente de servlet-3.0 y tolerar servlet-3.1.

For AIX platformsFor HP UNIX platformsFor LINUX platformsFor Solaris platformsFor IBM i platformsSe admite la directiva siguiente:
  • ibm.executable - Añade el permiso de ejecución al archivo asociado, según el valor actual de umask, cuando el valor se establece en "true". Cualquier otro valor implicará que no se emprenda ninguna acción. En la tabla siguiente se muestra el valor actual de umask y la clase que obtiene el permiso de ejecución.
    Tabla 2. Ejemplos de valores de umask y clases con permisos de ejecución establecidos mediante ibm.executable
    Umask Permisos de ejecución otorgados a la clase
    022 propietario, grupo, otras
    023 propietario, grupo
    055 propietario

Subsystem-Localization

Esta cabecera especifica la ubicación de los archivos de localización de la característica.

Por ejemplo:
Subsystem-Localization: OSGI-INF/l10n/loc

Subsystem-Name

Utilice esta cabecera para suministrar un nombre abreviado, legible para el usuario, de la característica. Puede especificar una serie literal o un nombre de propiedad. Si especifica un nombre de propiedad, se puede localizar el valor.

Por ejemplo
Subsystem-Name: %name
donde el valor de name se define en un archivo de propiedades en la ubicación especificada en la cabecera Subsystem-Localization (loc.properties en el ejemplo anterior), con el formato siguiente:
name=nombre_característica

Subsystem-Description

Utilice esta cabecera para proporcionar una descripción de la característica. Puede especificar una serie literal o un nombre de propiedad. Si especifica un nombre de propiedad, se puede localizar el valor.

Por ejemplo
Subsystem-Description: %desc
donde el valor de desc se define en un archivo de propiedades en la ubicación especificada en la cabecera Subsystem-Localization (loc.properties en el ejemplo anterior), con el formato siguiente:
desc=descripción_característica

IBM-Provision-Capability

Las características suministradas automáticamente son características que tienen la cabecera IBM-Provision-Capability en el manifiesto. Esta cabecera describe otras características que deben ser suministrados para que esta característica se suministre automáticamente. Cuando liste las demás características, utilice la cabecera Subsystem-SymbolicName de la característica. Cuando se configuran características en el archivo server.xml, runtime comprueba si se han cumplido las capacidades de las características de suministro automático y, en caso afirmativo, se suministran de forma automática.

El formato de la cabecera IBM-Provision-Capability utiliza filtros LDAP de OSGi estándar.

IBM-API-Package

Esta cabecera se utiliza para indicar qué paquetes de API están visibles para las aplicaciones. Se coincide con la sintaxis de la cabecera Export-Package. Esto significa que es una lista separada por comas de paquetes de API, pero cada paquete de API puede tener varios atributos.

Se admite el atributo siguiente:
  • type: el tipo de paquete de API. El atributo type puede tener uno de los valores siguientes:
    • spec: indica una API proporcionada por un cuerpo estándar como, por ejemplo, javax.servlet o org.osgi.framework.
    • ibm-api: indica una API de valor añadido proporcionada por IBM®.
    • api: indica una API definida por el usuario. Éste es el valor predeterminado.
    • third-party: indica una API que está visible, pero no está controlada por IBM. Normalmente, son paquetes de código abierto.
    • internal: indica paquetes que no son de API que se deben exponer a las aplicaciones para que funcionen. Puede utilizarse si se ha mejorado, o entramado, el código de bytes del código Java para añadir referencias al código interno en el tiempo de ejecución.
Por ejemplo:
IBM-API-Package: javax.servlet; type="spec",
                 com.ibm.websphere.servlet.session; type="ibm-api",
                 com.ibm.wsspi.webcontainer.annotation; type="internal"

IBM-API-Service

Esta cabecera se utiliza para indicar qué servicios de la característica están visibles para las aplicaciones OSGi. La característica debe registrar también el servicio en el registro de servicios OSGi.

Tiene la siguiente sintaxis:
IBM-API-Service ::= service ( ',' service )*
                    service ::= service-name ( ';' attribute )*
                    service-name ::= unique-name
service-name es la clase Java o el nombre de interfaz del servicio. Los atributos se interpretan como las propiedades de servicio de los servicios.
Por ejemplo:
IBM-API-Service: com.ibm.example.service.FeatureServiceOne; 
                 myServiceAttribute=myAttributeValue,
                 com.ibm.example.service.FeatureServiceTwo

Si una aplicación OSGi desea utilizar los servicios proporcionados por la cabecera IBM-API-Service, la aplicación debe incluir una referencia Blueprint al servicio para que el servicio se suministre a la aplicación.

Por ejemplo:
<?xml version="1.0" encoding="UTF-8"?>
<blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0">
	<reference id="FeatureServiceOneRef"
			interface="com.ibm.example.service.FeatureServiceOne" />
</blueprint>

Para que un paquete de una aplicación OSGi pueda utilizar un servicio, el paquete de la interfaz debe estar disponible para dicho paquete, lo que significa que el paquete de interfaz debe especificarse mediante una cabecera Import-Package en el archivo de manifiesto del paquete de consumo. El paquete de interfaz también debe especificarse mediante una cabecera Export-Package en un paquete de características y especificarse en la cabecera IBM-API-Package del archivo de manifiesto de la característica. El servicio proporcionado por una característica debe registrarse en el registro de servicios OSGi utilizando la interfaz BundleContext OSGi o cualquier otro mecanismo como Blueprint o los servicios declarativos. Para obtener más información, consulte los apartados Desarrollo de un paquete OSGi con la activación simple y Composición de características avanzadas utilizando servicios declarativos de OSGi.

IBM-SPI-Package

Cuando cree su propia característica de Liberty, instálela en la extensión del producto del usuario. Cualquier otra característica que esté instalada en la extensión del producto del usuario podrá acceder a todos los paquetes de su característica. No obstante, si desea que una característica que está instalada en otra extensión de producto acceda a un paquete en su característica, debe listar el nombre de paquete en la cabecera IBM-SPI-Package.

Cualquier paquete que se liste en la cabecera IBM-SPI-Package debe ser exportado por un paquete de la característica de Liberty, apareciendo en la lista de la cabecera Export-Package del archivo de manifiesto de paquete.

IBM-ShortName

Esta cabecera es un nombre abreviado de una característica que puede utilizar para especificar una característica en el archivo server.xml. Si no hay ninguna cabecera IBM-ShortName en el archivo de manifiesto, se utiliza Subsystem-SymbolicName de forma predeterminada. La cabecera IBM-ShortName solo es válida para las características públicas.

IBM-AppliesTo

Esta cabecera especifica la versión de Liberty a la que se aplica esta característica. Proporcione una lista de elementos separados por comas, cada uno en la forma siguiente:
ID_producto; productVersion=versión_producto; productInstallType=tipo_instalación_producto; productEdition=ediciones_producto

Si proporciona más de un elemento, el valor de ID_producto debe ser distinto para cada uno.

El valor de productVersion puede ser una versión exacta, por ejemplo 8.5.5.7, o una versión mínima, indicada mediante la versión que finaliza con un signo más, +, por ejemplo 8.5.5.7+.

El valor de productEdition puede ser una edición única o una lista de ediciones separadas por comas colocada entre comillas.

Por ejemplo:
IBM-AppliesTo: com.ibm.websphere.appserver; productVersion=8.5.5.6; productInstallType=Archive; productEdition="BASE,DEVELOPERS,ND"

Subsystem-License

Esta cabecera define el tipo de licencia de esta característica. Si proporciona un valor para la cabecera Subsystem-License y no proporciona valores para las cabeceras IBM-License-Agreement y IBM-License-Information, se muestra al usuario el valor de la cabecera Subsystem-License para que la acepte durante la instalación.

Si ya hay una característica instalada con el mismo valor de cabecera Subsystem-License, no se muestra la licencia ni se busca la aprobación de licencia durante la instalación. Si las dependencias en la cabecera Subsystem-Content significan que hay dos o más características que se van a instalar que tienen el mismo valor de cabecera Subsystem-License, el usuario solo tiene que aceptar la licencia una vez durante la instalación.

Por ejemplo:
Subsystem-License: L-JTHS-93TMHH
Subsystem-License: http://www.apache.org/licenses/LICENSE-2.0.html

IBM-License-Agreement

Esta cabecera especifica el prefijo de la ubicación de los archivos del acuerdo de licencia. Proporcione la vía de acceso de archivo en el archivado de subsistema de los archivos LA_idioma, hasta, pero sin incluir, el carácter "_" (la herramienta de instalación añade el código de idioma). Si no se ha aceptado la licencia, el usuario debe aceptar la licencia al instalar la característica. Los archivos de licencia se copian en el directorio de instalación de Liberty.

Por ejemplo:
IBM-License-Agreement: lafiles/LA

IBM-License-Information

Esta cabecera especifica el prefijo de la ubicación de los archivos de información de la licencia. Proporcione la vía de acceso de archivo en el archivado de subsistema de los archivos LI_idioma, hasta, pero sin incluir, el carácter "_" (la herramienta de instalación añade el código de idioma). Si no se ha aceptado la licencia, el usuario debe aceptar la licencia al instalar la característica. Los archivos de licencia se copian en el directorio de instalación de Liberty.

Por ejemplo:
IBM-License-Information: lafiles/LI
[18.0.0.1 and later]

IBM-Maven-Dependency

Esta cabecera especifica las coordenadas Maven de las dependencias de la especificación Java que son necesarias para esta característica. Proporcione una lista de elementos separados por comas, cada uno en el formato siguiente: IdGrupo:IdArtefacto:versión. Ejemplo:
IBM-Maven-Dependency: javax.servlet:javax.servlet-api:3.1.0

IBM-App-ForceRestart

Esta cabecera hace que las aplicaciones se reinicien al instalar la característica en un servidor en ejecución o eliminarla. Esta cabecera puede tomar uno de los valores siguientes:
  • install: reinicia las aplicaciones cuando se instala la característica.
  • uninstall: reinicia las aplicaciones cuando se desinstala la característica.
  • install: reinicia las aplicaciones cuando se instala o se desinstala la característica.

Ejemplo de archivo de manifiesto de característica

En el ejemplo siguiente se muestra la definición de la característica example-1.0. El atributo visibility público permite que esta característica se especifique directamente en los archivos de configuración de servidor (server.xml); se incluye también en la lista desplegable de características que se muestran en la vista Configuración de servidor de las herramientas de desarrollador y está disponible para la inclusión en características que están en otras extensiones del producto. Si se instala esta característica en la extensión del producto usr de una instalación de tiempo de ejecución, se puede configurar en un servidor incluyendo el código siguiente en el archivo server.xml:
<featureManager>
	<feature>usr:example-1.0</feature>
</featureManager>
La configuración de esta característica en un servidor da como resultado el paquete especificado, com.ibm.example.bundle1, instalado e iniciado en la infraestructura OSGi del entorno de ejecución del servidor. El paquete de API único, com.ibm.example.publicapi, es visible para todas las aplicaciones de ese servidor, excepto para las aplicaciones Java EE configuradas para no tener visibilidad para el tipo de paquete api. Las aplicaciones OSGi deben importar explícitamente el paquete si desean utilizarlo. Los dos paquetes SPI, com.ibm.example.spi.utils y com.acme.spi.spiservices, son visibles para todo el código de característica del servidor, como lo es el paquete de API.
IBM-Feature-Version: 2
Subsystem-ManifestVersion: 1.0
Subsystem-SymbolicName: com.ibm.example-1.0; visibility:=public
Subsystem-Version: 1.0.0.qualifier
Subsystem-Type: osgi.subsystem.feature
Subsystem-Content: com.ibm.example.bundle1; version="1.0.0"
Subsystem-Localization: OSGI-INF/l10n/loc
Manifest-Version: 1.0
Subsystem-Name: %name
Subsystem-Description: %desc
IBM-API-Package: com.ibm.example.publicapi; type="api"
IBM-SPI-Package: com.ibm.example.spi.utils, com.ibm.example.spi.spiservices
IBM-ShortName: example-1.0

Icono que indica el tipo de tema Tema de referencia

Nombre de archivo: rwlp_feat_definition.html