Debian::Javahelper::Manifest(3) Javahelper Debian::Javahelper::Manifest(3)NAME
Debian::Javahelper::Manifest - Javahelper representation of a Jar Manifest
SYNOPSIS
use Debian::Javahelper::Java;
my $manifest = ...;
my $main_sec = $manifest->get_section(MAIN_SECTION);
# Create if it does not exist.
my $file_sec = $manifest->get_section("java/lang/Object.class", 1);
DESCRIPTION
This module is used to represent a Java Manifest.
Constants
MAIN_SECTION
A constant denoting the main section of the manifest.
Exported by default.
Methods
Debian::Javahelper::Manifest->new()
Creates a new manifest. It will only contain the main section with the Manifest-Version attribute.
$manifest->get_section($name[, $create])
Returns the section denoted by $name. If this section does not exist, then it will either return undef or (if $create is a truth-value)
create a new empty section with that name.
Use the MAIN_SECTION constant to access the main section of the manifest.
$manifest->get_sections()
Returns a list of all sections in $manifest. The main section will always be the first in the list, but the remaining sections can come
in any order (and this order can change in later invocations).
Modifying the list will not change which sections are present in $manifest, but modifying a section in this list will also update the
section in the manifest.
$manifest->merge($other)
Merge all entries in $other into $manifest. All sections in $other will be added to $manifest if they are not already present.
If an attribute in a given section is only present in one of the two manifests, then that attribute and its value will be in $manifest
after merge returns.
If the attribute in a given section is present in both manifests, then the value from $other will be used.
This can be used to make a deep copy a manifest:
my $copy = Debian::Javahelper::Manifest->new();
$copy->merge($orig);
SEE ALSO Debian::Javahelper::Java(3) - had parse/write methods for manifests. Debian::Javahelper::ManifestSection(3) - for how sections are
handled.
AUTHOR
Niels Thykier <niels@thykier.net>
COPYRIGHT AND LICENSE
Copyright 2010 by Niels Thykier
This module is free software; you may redistribute it and/or modify it under the terms of GNU GPL 2.
0.43 2011-02-17 Debian::Javahelper::Manifest(3)
Check Out this Related Man Page
smf_bootstrap(5) Standards, Environments, and Macros smf_bootstrap(5)NAME
smf_bootstrap - service management facility boot, packaging, and compatibility behavior
DESCRIPTION
The service management facility defines a series of conventions for importing the configuration contained within a service manifest or pro-
file into a repository.
Manifest loading at boot
At system start, svc.startd(1M) run in default mode begins processing the manifests located in /var/svc/manifest and importing new or
changed manifests into the repositorty.
The decision to import a service manifest is based on the existence of a property group in the svc:/smf/manifest service with the following
characteristics:
o The name of the property group is the name of the imported manifest with non-alphanumeric characters replaced by underscore (_) char-
acters.
o The properties of the property group are set based on the manifest contents.
The manifest is not reimported in the event that configuration changes are made to the repository by an administrator. Such configuration
changes might include the deletion of one or more services or service instances contained within the manifest. The /var/svc/manifest/site
directory is provided for site-specific customizations.
The deletion of a property group by means of svccfg(1M) or libscf(3LIB) interfaces allows the manifest to be reimported on a subsequent
system boot.
Manifest handling during packaging operations
Service manifests within packages are identified with the class manifest. Class action scripts that install and remove service manifests
are included in the packaging subsystem. When pkgadd(1M) is invoked, the service manifest is imported.
When pkgrm(1M) is invoked, instances in the manifest that are disabled are deleted. Any services in the manifest with no remaining
instances are also deleted.
Stability declarations
Each service group and each property group delivered in a manifest should declare a stability level based on attributes(5) definitions.
With knowledge of the stability level, an application developer can determine the likelihood that feature development based on the exis-
tence or components of a service or object is likely to remain functional across a release boundary.
In an smf(5) context, the stability value also identifies the expected scope of the changes to properties within the property group across
a release boundary for the service, which can include patches for that service. The following two sections discuss this in more detail.
Property overrides
The service_bundle(4) document type definition includes an override attribute that is applicable to each property in a service manifest. If
set to true, the attribute instructs svccfg(1M) and other manifest import tools to replace the current value of a property in the reposi-
tory with the one from the manifest. If the override attribute is absent or present but set to false, the current value in the repository
is preserved.
Property groups declared as Stable do not contain override attributes on enclosed properties. Property groups declared as Evolving do so
only to correct an erroneous setting. Property groups declared as Unstable can contain overrides on any property. The exception to this
behavior is for the stability property itself, which can be modified to identify incipient change to the interface presented by the ser-
vice.
Property group deletion
The service_bundle(4) document type definition includes a delete attribute, applicable to each property group in a service manifest. If set
to true, the delete attribute instructs svccfg(1M) and other manifest import tools to delete this property group from the repository. If
the delete attribute is absent or present but set to false, the property group in the repository is preserved.
Property groups declared as Stable or Evolving are not deleted. Property groups declared as Unstable can be deleted across any release
boundary.
Profile application
The first time the existence of each of the three service profiles listed below is detected, svc.startd(1M) automatically applies the pro-
file.
/var/svc/profile/generic.xml
/var/svc/profile/platform.xml
/var/svc/profile/site.xml
The svc:/smf/manifest service is used in a similar fashion.
Additional service profiles that characterize the activation of various groups of service instances might be present in /var/svc/profile.
None of the /var/svc/profile profiles are automatically applied to the repository. A profile can be manually applied or re-applied using
svcadm(1M).
SEE ALSO pkgadd(1M), pkgrm(1M), svcadm(1M), svccfg(1M), svc.startd(1M), libscf(3LIB), service_bundle(4), attributes(5), smf(5), smf_security(5)NOTES
The present version of smf(5) does not support multiple repositories.
SunOS 5.10 27 Aug 2004 smf_bootstrap(5)