Java Reference
In-Depth Information
} else if (args.trim().startsWith("install ")) {
DeploymentPackage dp = admin.installDeploymentPackage(new URL(
args.trim().substring("install ".length())).openStream());
out.println(dp.getName() + " " + dp.getVersion());
}
} else {
out.println("Use {list|install <url>|uninstall <name>}");
}
}
private DeploymentAdmin getDeploymentAdmin() {
...
}
}
Like the previous example commands, you more or less map the command onto the
DeploymentAdmin
service interface. You get installed deployment packages using the
listDeploymentPackages()
service method and print their names and versions
B
.
Then, you uninstall an existing deployment package associated with a specified sym-
bolic name using
DeploymentPackage.uninstall()
C
. Finally, you install a deploy-
ment package from the specified
URL
using the
installDeploymentPackage()
service
method
D
. The approach is fairly similar to managing bundles.
To run this example, go to the chapter10/combined-example/ director y of the com-
panion code. Type
ant
to build the example and
java
-jar
launcher.jar
bundles
to
execute it. To interact with the shell, use
telnet
localhost
7070
. This example uses the
Apache Felix Deployment Admin implementation (
http://felix.apache.org/site/
apache-felix-deployment-admin.html
)
. Here's the command in action:
D
Installs
deployment
package
->
dpa install file:org.foo.paint-1.0.dp
org.foo.paint 1.0.0
->
dpa install file:org.foo.paint-2.0.dp
org.foo.paint 2.0.0
->
dpa list
org.foo.paint 2.0.0
->
dpa uninstall org.foo.paint
This session installs the core paint program deployment package. You then update it to
include the fix package for the shapes. You list the installed deployment packages and
then uninstall the deployment package. (Note that the Apache Felix implementation of
Deployment Admin doesn't currently implement the uninstall functionality.) This high-
lights the difference between the
OBR
and Deployment Admin approaches, because you
can manage your bundles as a single unit of deployment rather than individual bundles.
Before concluding our discussion on Deployment Admin, we'll discuss resource
processors. Resource processors are an important part of the Deployment Admin
specification, because they extend
OSG
i deployment beyond bundles.
RESOURCE PROCESSORS
Deployment Admin can process bundle resources in deployment packages by itself;
but when it comes to other types of resources, it needs to enlist the help of
Resource-
Processor
services. A
ResourceProcessor
is a service used to appropriately process
arbitrary resource types; it implements the following interface:
