Full Chapter Pro Spring Dynamic Modules For Osgi Service Platforms Expert S Voice in Open Source Rubio Daniel PDF

Pro Spring Dynamic Modules for OSGi
Service Platforms Expert s Voice in

Open Source Rubio Daniel
Visit to download the full and correct content document:
https://textbookfull.com/product/pro-spring-dynamic-modules-for-osgi-service-platform
s-expert-s-voice-in-open-source-rubio-daniel/
More products digital (pdf, epub, mobi) instant
download maybe you interests ...
Spring Persistence with Hibernate Expert s Voice in

Open Source Paul Tepper Fisher Brian D Murphy
https://textbookfull.com/product/spring-persistence-with-
hibernate-expert-s-voice-in-open-source-paul-tepper-fisher-brian-
d-murphy/
Hibernate Recipes A Problem Solution Approach Expert s

Voice in Open Source Mak Gary Guruzu Srinivas
https://textbookfull.com/product/hibernate-recipes-a-problem-
solution-approach-expert-s-voice-in-open-source-mak-gary-guruzu-
srinivas/
Beginning Database Driven Application Development in

Java EE Using GlassFish Expert s Voice in Open Source
Vasiliev Yuli
https://textbookfull.com/product/beginning-database-driven-
application-development-in-java-ee-using-glassfish-expert-s-
voice-in-open-source-vasiliev-yuli/
Pro Hibernate and MongoDB The Expert s Voice Leonard

Anghel
https://textbookfull.com/product/pro-hibernate-and-mongodb-the-
expert-s-voice-leonard-anghel/
Beginning Java with WebSphere Expert s Voice in Java
Janson Robert W
https://textbookfull.com/product/beginning-java-with-websphere-
expert-s-voice-in-java-janson-robert-w/
Beginning Java and Flex Migrating Java Spring Hibernate

and Maven Developers to Adobe Flex Expert s Voice in
Web Development Di Pisa Filippo
https://textbookfull.com/product/beginning-java-and-flex-
migrating-java-spring-hibernate-and-maven-developers-to-adobe-
flex-expert-s-voice-in-web-development-di-pisa-filippo/
JavaFX 2 0 Introduction by Example Expert s Voice in

Java Dea Carl
https://textbookfull.com/product/javafx-2-0-introduction-by-
example-expert-s-voice-in-java-dea-carl/
Pro linux system administration Learn to build systems

for your business using free and open source software
Lieverdink
https://textbookfull.com/product/pro-linux-system-administration-
learn-to-build-systems-for-your-business-using-free-and-open-
source-software-lieverdink/
Pro linux system administration Learn to build systems

for your business using free and open source software
Lieverdink
https://textbookfull.com/product/pro-linux-system-administration-
learn-to-build-systems-for-your-business-using-free-and-open-
source-software-lieverdink-2/
Pro Spring Dynamic
Modules for OSGi™
Service Platforms
■■■
Daniel Rubio
Pro Spring Dynamic Modules for OSGi™ Service Platforms
Copyright © 2009 by Daniel Rubio
All rights reserved. No part of this work may be reproduced or transmitted in any form or by any means,
electronic or mechanical, including photocopying, recording, or by any information storage or retrieval
system, without the prior written permission of the copyright owner and the publisher.
ISBN-13 (pbk): 978-1-4302-1612-4
ISBN-13 (electronic): 978-1-4302-1613-1
Printed and bound in the United States of America 9 8 7 6 5 4 3 2 1
Trademarked names may appear in this book. Rather than use a trademark symbol with every occurrence
of a trademarked name, we use the names only in an editorial fashion and to the benefit of the trademark
owner, with no intention of infringement of the trademark.
Java™ and all Java-based marks are trademarks or registered trademarks of Sun Microsystems, Inc., in the
US and other countries. Apress, Inc., is not affiliated with Sun Microsystems, Inc., and this book was written
without endorsement from Sun Microsystems, Inc.
Lead Editors: Steve Anglin, Tom Welsh
Technical Reviewer: Gerd Wütherich
Editorial Board: Clay Andres, Steve Anglin, Mark Beckner, Ewan Buckingham, Tony Campbell,
Gary Cornell, Jonathan Gennick, Jonathan Hassell, Michelle Lowman, Matthew Moodie,
Duncan Parkes, Jeffrey Pepper, Frank Pohlmann, Ben Renow-Clarke, Dominic Shakeshaft,
Matt Wade, Tom Welsh
Project Manager: Kylie Johnston
Copy Editor: Ami Knox
Associate Production Director: Kari Brooks-Copony
Production Editor: Laura Cheu
Compositor: Susan Glinert Stevens
Proofreader: Liz Welch
Indexer: Brenda Miller
Artist: April Milne
Cover Designer: Kurt Krames
Manufacturing Director: Tom Debolski
Distributed to the book trade worldwide by Springer-Verlag New York, Inc., 233 Spring Street, 6th Floor,
New York, NY 10013. Phone 1-800-SPRINGER, fax 201-348-4505, e-mail orders-ny@springer-sbm.com, or
visit http://www.springeronline.com.
For information on translations, please contact Apress directly at 2855 Telegraph Avenue, Suite 600,
Berkeley, CA 94705. Phone 510-549-5930, fax 510-549-5939, e-mail info@apress.com, or visit http://
www.apress.com.
Apress and friends of ED books may be purchased in bulk for academic, corporate, or promotional use.
eBook versions and licenses are also available for most titles. For more information, reference our Special
Bulk Sales–eBook Licensing web page at http://www.apress.com/info/bulksales.
The information in this book is distributed on an “as is” basis, without warranty. Although every precaution
has been taken in the preparation of this work, neither the author(s) nor Apress shall have any liability to
any person or entity with respect to any loss or damage caused or alleged to be caused directly or indirectly
by the information contained in this work.
The source code for this book is available to readers at http://www.apress.com.
To my family and friends. The ones who put up with the many instances of
“I can’t today . . . ” and “I can’t tommorrow . . . ” that brought about this book.
Contents at a Glance
About the Author . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi

About the Technical Reviewer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xii
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv
■CHAPTER 1 Introducing OSGi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

■CHAPTER 2 Introducing Spring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
■CHAPTER 3 Integrating Spring and OSGi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
■CHAPTER 4 Spring Dynamic Modules for OSGi . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
■CHAPTER 5 SpringSource dm Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
■CHAPTER 6 Versioning with OSGi and Spring . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
■CHAPTER 7 Data Access and Bundle Management
Without SpringSource dm Server . . . . . . . . . . . . . . . . . . . . . . . . . 257
■CHAPTER 8 Web Applications Using Spring and OSGi . . . . . . . . . . . . . . . . . . . . . 303
■CHAPTER 9 Testing with Spring and OSGi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331
■INDEX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361
v
Contents
About the Author . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi

About the Technical Reviewer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xii
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv
■CHAPTER 1 Introducing OSGi ...........................................1
OSGi Concepts and Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

Java’s Virtual Machine, Java Classes, and the
CLASSPATH Variable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
The OSGi Bundle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
The OSGi Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
OSGi Hello World Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Prerequisites and Downloads . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Your First OSGi Bundles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
The Http Service OSGi Bundle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
OSGi Bundle for the Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Updating OSGi Bundles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
OSGi Hello World Application Conclusions . . . . . . . . . . . . . . . . . . . . . 39
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
■CHAPTER 2 Introducing Spring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Spring Concepts and Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

Inversion of Control and Dependency Injection . . . . . . . . . . . . . . . . . 45
Plain Old Java Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Spring Portfolio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Spring Hello World Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Prerequisites and Downloads . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
The Domain Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Persisting the Domain Model with JPA . . . . . . . . . . . . . . . . . . . . . . . 61
Testing Your Domain Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
Using Spring’s MVC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
Deploying on the Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
vii
viii ■C O N T E N T S
■CHAPTER 3 Integrating Spring and OSGi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
OSGi’s Synergy with Spring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

Layers of Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
Application Design: Services and Beans . . . . . . . . . . . . . . . . . . . . . 110
Application Packaging: Dependencies . . . . . . . . . . . . . . . . . . . . . . . 111
Application Servers: Classpath Loaders . . . . . . . . . . . . . . . . . . . . . . 112
OSGi and Spring Hello World Application . . . . . . . . . . . . . . . . . . . . . . . . . 119
Prerequisites and Downloads . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
The Domain Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
Web Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
Deploying Spring-OSGi Bundles . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
■CHAPTER 4 Spring Dynamic Modules for OSGi . . . . . . . . . . . . . . . . . . . . . . 149
Extenders and Fragments in Spring-DM . . . . . . . . . . . . . . . . . . . . . . . . . 149

Registering OSGi Services Through Spring-DM . . . . . . . . . . . . . . . . . . . 153
Locating OSGi Services Through Spring-DM . . . . . . . . . . . . . . . . . . . . . . 161
OSGi Bundle Activities with Spring-DM . . . . . . . . . . . . . . . . . . . . . . . . . . 169
OSGi Fragments with Spring-DM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
■CHAPTER 5 SpringSource dm Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177

Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
OSGi Deployment in the Enterprise . . . . . . . . . . . . . . . . . . . . . . . . . . 178
Spring, OSGi, and Java Integration . . . . . . . . . . . . . . . . . . . . . . . . . . 179
Java EE Native and Shared Library WAR Support . . . . . . . . . . . . . . 181
Tooling and Administration Support . . . . . . . . . . . . . . . . . . . . . . . . . 181
Concepts and Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
Deployment Units . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
Directory Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
SpringSource dm Server Hello World Application . . . . . . . . . . . . . . . . . . 190
Application Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196
Application Bundles, Manifests, and Descriptors . . . . . . . . . . . . . . 208
Building and Deploying the Application . . . . . . . . . . . . . . . . . . . . . . 225
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230
■C O N T E N T S ix
■CHAPTER 6 Versioning with OSGi and Spring . . . . . . . . . . . . . . . . . . . . . . . . 231
Benefits and Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231

OSGi Package Versioning Behaviors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235
OSGi Service Versioning Behaviors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238
OSGi Bundle Versioning Behaviors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244
OSGi Fragment Versioning Behaviors . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251
OSGi Spring-DM and SpringSource dm Server
Versioning Behaviors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255
■CHAPTER 7 Data Access and Bundle Management Without

SpringSource dm Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257
Access to RDBMSs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258
Introducing the BND Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267
Hello World Application Revisited Without the SpringSource
dm Server: Data Access and Apache Ivy . . . . . . . . . . . . . . . . . . . . . . 280
Building and Deploying the Application . . . . . . . . . . . . . . . . . . . . . . 287
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301
■CHAPTER 8 Web Applications Using Spring and OSGi . . . . . . . . . . . . . . . 303
Web Bundle Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303

Using Different Web Containers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309
Overriding the Default Extender Value . . . . . . . . . . . . . . . . . . . . . . . 310
Bootstrapping the Web Container . . . . . . . . . . . . . . . . . . . . . . . . . . . 310
Using the Jetty Web Container . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312
Using SSL/TLS with OSGi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315
Setting Up SSL in Apache Tomcat . . . . . . . . . . . . . . . . . . . . . . . . . . 315
Creating a JKS Keystore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316
Fulfilling Apache Tomcat’s SSL Dependencies . . . . . . . . . . . . . . . . 318
Creating the SSL Configuration Fragment . . . . . . . . . . . . . . . . . . . . 318
Installing the Fragment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319
Using Flex with OSGi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320
Laying Out a Flex User Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322
Calling Back to the Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325
Configuring OSGi and Flex . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 327
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330
x ■C O N T E N T S
■CHAPTER 9 Testing with Spring and OSGi . . . . . . . . . . . . . . . . . . . . . . . . . . . 331
Testing with OSGi and Spring-DM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331

Unit and Integration Revisited: Testing OSGi Applications
Without OSGi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332
Spring-DM’s Testing Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 339
Creating a Spring-DM Test Class . . . . . . . . . . . . . . . . . . . . . . . . . . . 341
Downloading Spring-DM Test Dependencies
with Apache Ivy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346
Executing a Spring-DM Test with Apache Ant . . . . . . . . . . . . . . . . . 349
Hello World Application Spring-DM Test . . . . . . . . . . . . . . . . . . . . . . . . . 354
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 359
■INDEX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361
About the Author
■DANIEL RUBIO is a consultant with over 10 years of experience in

enterprise and web technologies. Specializing in web-based archi-
tectures that integrate with back-end systems such as relational
databases, ERPs, and CICS, he’s relied on Java, CORBA, and .NET
technology throughout his career to deliver cost-effective solutions
to the financial and manufacturing industries.
Additionally, he writes articles on emerging technologies for
various content networks in this same space, which include TheServerSide.com, Oracle
Technology Network, SearchSOA.com, and his own blog, WebForefront.com. Currently,
Daniel is founder and technical lead at MashupSoft.com.
xi
About the Technical Reviewer
■GERD WÜTHERICH is a consultant and software architect living in

Hamburg, Germany. His main area of expertise is in building
modular enterprise application systems utilizing OSGi technology,
especially in combination with the Spring Framework. He is the
author of the German OSGi book Die OSGi Service Platform and a
frequent speaker at international conferences. More information is
available at http://www.gerd-wuetherich.de.
xii
Acknowledgments
E ven with prior writing experience, I never thought writing a book would be such a massive
undertaking. I was accustomed to a fast loop between myself and an editor with three or
four e-mail exchanges from proposal to finished article. If it took over a thousand exchanges
simply to help me shape the content of this book, I wouldn’t be surprised.
First off I’d like to acknowledge everyone at Apress. The people involved at the initial
stages of the book—when it was just an idea: Steve Anglin, Dominic Shakeshaft, and Joohn
Choe. The people with whom I interacted once the book got underway all the way to its
end: Kylie Johnston, Tom Welsh, and Matthew Moodie. And the people involved toward
the final stages of this project: Ami Knox, Laura Cheu, and Stephanie Parker. And of course,
every other person at Apress who had a role in this book with whom I didn’t have the
opportunity to interact directly.
For helping me to keep the content accurate on the technical front, special thanks go to
Gerd Wütherich, who served as the book’s technical reviewer, as well as Colin Yates, who
initially took part in the technical review process.
In addition, the book would not have been possible without many articles, documents,
and blog posts by the people who shape OSGi, Spring, and Spring-DM technology, including
Adrian Colyer, Alex Blewitt, Costin Leau, Eric Newcomer, Neil Bartlett, Martin Lippert,
Peter Kriens, Rob Harrop, and Rod Johnson. And of course, the many other people active
in these areas who surely influenced my thought processes, but whom I unfortunately
can’t credit individually due to space constraints and the limitations of memory.
And finally, I thank my family and friends. Although did I evoke long blank stares after
I tried to explain this book’s purpose in layman’s terms, but (in what is perhaps the best
morale support one could ask for), these same people kept asking me about this project’s
progress. I would need too much space to do it individually, so to everyone who asked,
thank you. I consider you a part of this effort for providing face-to-face moral support.
xiii
Introduction
T his book is about OSGi’s role in enterprise Java and how the Spring Dynamic Modules
for OSGi (Spring-DM) fulfills this role.
I first learned about OSGi when the Eclipse IDE started using it in its plug-in architec-
ture. At the time, the versioning and modularity features seemed nicer “for an IDE” than
what was available using stand-alone Java. However, OSGi still seemed something reserved to
the internal workings of an IDE.
Next, I read about Java SE initiatives to incorporate similar modularity features, with OSGi
being a leading contender. Competing in this space were JSR-277, “Java Module System,”
and JSR-291, “Dynamic Component Support for Java,” the latter based on OSGi principles.
Knowing that OSGi might very well influence the Java language itself—via Java SE—
raised my interest in OSGi and how it could be applied to scenarios in the enterprise
Java space.
It didn’t take much research to find out that some Java EE application server vendors
had relied on those same OSGi features to design their products. But in much the same
way as the Eclipse IDE, OSGi still seemed reserved to the internal workings of a product. So
I was still left with a big question: could OSGi influence enterprise Java applications in some
other way? When I discovered Spring-DM, the answer became clear: yes.
OSGi along with Spring-DM will make you rethink the way you design Java applications.
Support for runtime versioning is probably one of the biggest changes you will appreciate.
Running multiple versions of the same class in a JVM instance is a difficult task in stand-
alone Java, requiring the use of custom class loaders.
With OSGi this is not the case. No longer will you need to check your CLASSPATH variable
to avoid running multiple JARs with the same name that may contain conflicting classes.
OSGi eliminates this burden, letting you install and run as many different JAR versions as
required in a single JVM instance.
This same approach will also play a part in your enterprise Java applications. The typical
enterprise Java application is packaged as a Web Archive (WAR) or Enterprise Archive
(EAR), monolithic formats containing every dependency used by an application. While
these formats are warranted due to the way in which Java EE application servers (containers)
operate—providing class isolation for each application—OSGi will make these heavyweight
formats look irrelevant, since it can manage versioning and class isolation at a another level.
Additionally, WARs and EARs often contain the same staple JARs, such as logging, Java
frameworks, or special libraries, leading to multiple instances of the same JAR taking up
valuable memory resources in application servers. By avoiding WARs and EARs, OSGi can
manage a single JAR, with different versions, that is shared across various applications.
xv
xvi ■I N T R O D U C T I O N
As a consequence of applying OSGi principles to enterprise Java applications, the

deployment infrastructure—Java EE application servers—will also reveal some weak-
nesses. That is why you also need to learn about SpringSource dm Server, a new breed
of Java EE application server designed to accommodate the special features of OSGi and
Spring-DM.
Once you’ve got a feel for OSGi’s packaging approach and the benefits it brings in terms
of runtime versioning and class isolation, you can start to think about OSGi services. Though
not a prerequisite for using OSGi’s other features, OSGi services will allow your applica-
tions to expose and consume business logic in more manageable pieces.
Instead of having application JARs expose and access Java classes available in other JARs,
as is typically done, OSGi allows you to expose and consume prebuilt services contained
in JARs. This allows business logic to become more manageable, since you don’t have to
access individual classes, but rather just query an OSGi service to obtain an end result
more quickly.
Still, don’t think you need to rely on the entire Spring Framework as a prerequisite to
use OSGi in your enterprise Java applications. Spring-DM simply makes it easier to use
OSGi in your applications employing the principles set forth by this framework. The purpose
of Spring-DM is that you won’t have to learn or deal with the OSGi API directly, but rather
rely on dependency injection and descriptors—tenets of the Spring Framework—to work
with OSGi.
As a technologist, you may well ask yourself whether OSGi and Spring-DM are the future,
or just alternatives to other approaches that are likely to surpass them. I can point you to
various sources that indicate that both OSGi’s and Spring-DM’s futures are solid.
Project Jigsaw is one of the catalysts that makes OSGi a frontrunner in the race for
incorporating a module system into Java SE. For more details on this project, I will point
you to a post from Mark Reinhold, Principal Engineer at Sun Microsystems for JavaSE, on
the subject and its relation to OSGi: http://blogs.sun.com/mr/entry/jigsaw.
As far as Spring-DM is concerned, its principles now form part of RFC-124, “A Component
Model for OSGi,” which itself forms part of OSGi’s 4.2 release, so its relevance is more than
assured in the OSGi ecosystem. For more details on this last initiative, I can point you to two
sources, one by Eric Newcomer, Chief Technology Officer at IONA, http://blogs.iona.com/
newcomer/archives/000578.html, and another by Adrian Colyer, Chief Technology Officer
at SpringSource, http://blog.springsource.com/2008/09/01/early-draft-of-osgi-service-
platform-release-42-specification-now-available/.
To what extent OSGi and Spring-DM will form part of your day-to-day tasks as a Java
developer is still questionable, but that they will steadily gain influence should be without
question. You need not look as far as the previous resources to observe the traction both
technologies are gaining in terms of standardization—explore the contents of this book to
discover for yourself the benefits they bring to Java development.
■I N T R O D U C T I O N xvii
Who This Book Is For

Java developers who use the Spring Framework and are looking to take advantage of OSGi
features as well as Java developers in general looking to explore OSGi’s role on server-side
development will benefit.
How This Book Is Structured

Chapter 1 provides an introduction to OSGi. It includes a detailed look at the concepts and
benefits of using OSGi with Java. It also contains a sample application to help you familiarize
yourself with how OSGi applications are structured and deployed.
Chapter 2 provides an introduction to the Spring Framework. It includes a detailed look
at the core concepts that have made this framework so popular in enterprise Java applica-
tions. It also contains a comprehensive application that illustrates various areas covered
by the framework, such as persistence through Relational Database Management Systems
(RDBMS), Model-View-Controller (MVC) design, integration testing, and deployment to a
web container. Though anyone familiar with the Spring Framework should be able to skip
this chapter, I recommend that you take a look at the sample application, since future
chapters involve redesigned versions of this same application.
Chapter 3 provides an introduction to integrating Spring and OSGi. It includes a detailed
look at the various layers—as they relate to enterprise Java applications—that need to be
contemplated in order to integrate Spring and OSGi. In addition, it also contains a sample
application that illustrates how Spring-DM is used in the overall design of an application.
Chapter 4 covers Spring-DM in depth. It includes an overview of fragments and
extenders—OSGi concepts—and how they relate to Spring-DM. It also covers the various
Spring-DM elements used inside Spring-type descriptors for registering and looking up
OSGi services.
Chapter 5 provides an introduction to the SpringSource dm Server. It includes a
detailed look at why this software eases the deployment of OSGi and Spring-DM applica-
tions, as well as the concepts you need to familiarize yourself with in order to use it. In
addition, it contains a sample application that illustrates how to design and deploy an
application using an RDBMS. (This is a version of the application introduced in Chapter 2.)
Chapter 6 covers OSGi versioning. It includes a series of case scenarios and the entire
spectrum of OSGi versioning behaviors, which includes package versioning, bundle
versioning, fragment versioning, and versioning cases applicable to Spring-DM and the
SpringSource dm Server. A discussion on OSGi split packages is also included.
Chapter 7 covers data access and bundle management without the SpringSource dm
Server. It takes a detailed look at deploying full-fledged applications without the provi-
sions of the SpringSource dm Server. This includes a detailed look at RDBMS access in the
context of OSGi, bundle dependency management using Apache Ivy, and using BND to
xviii ■I N T R O D U C T I O N
transform JARs into OSGi-compliant bundles. It also contains a sample application ported
from Chapter 5.
Chapter 8 covers web applications in the context of Spring-DM. It zooms in on how
web applications are delegated and processed by an OSGi’fied web container. It also
contains application samples for enabling Secure Socket Layer (SSL) or https:// web sites,
working with Flex applications, and using the Jetty web server, all in the context of Spring-
DM. These last applications are ported from the application presented in Chapter 7.
Chapter 9 covers Spring-DM testing. It includes a detailed look at the Spring-DM testing
framework and how it facilitates the creation of tests in the context of Spring-DM. In addi-
tion, it provides working tests for the applications designed in earlier chapters.
Prerequisites
The book requires working knowledge of the Java programming language.
Downloading the Code

The source code for this book is available to readers at http://www.apress.com in the
Source Code section of this book’s home page. Please feel free to visit the Apress web site
and download all the code there. You can also check for errata and find related titles
from Apress.
Contacting the Author

You can contact me at osgi@webforefront.com.
CHAPTER 1
■■■
Introducing OSGi
O SGi—originally an acronym for Open Services Gateway Initiative—emerged in 1999 to

address the needs of the embedded device market. Close to 30 companies, many of which
were already invested in the language of the time, Java, worked to develop this initiative,
designed to use that language to target the embedded device market for the home.1
1999 was a crazy year in the technology sector, with everything under the sun showing
some type of promise in the whirlwind dot-com mania that ensued. It was a time to dream
big, be ambitious, and think outside the box more than ever, and the architects behind
OSGi did just that, envisioning a set of features missing in the Java platform at the time.
Chaotic though its time of inception was, OSGi’s design has proved resilient and has
helped it to expand into many markets that employ Java software. Let’s take a 100,000-foot
view of OSGi’s primary feature set before we zoom in on the details of its working parts.
Hot-pluggability was one feature envisioned by the OSGi expert group, a technical term
referring to a system capable of being altered without interrupting its ongoing operation.
Today high-end disk arrays are perhaps the most common hot-pluggable item in the IT
sector, allowing any disk failure to be corrected without the need for a system to be shut
down, thus guaranteeing 24-hour availability.
In the embedded device for the home circa 1999, hot-pluggability was not common. So
you need only imagine the ripple effect a device failure could have on a networked home
or the angst of rebooting this type of system if any one device needed to be repaired or
reinstalled.
Another target pursued by OSGi members was that of autodiscovery, whereby one
device is capable of reusing software present in another device. Here again, in retrospect
to the year 1999, embedded devices were severely limited in terms of memory and storage
resources, so that a device autodiscovering and reusing software present in another device
was a highly desirable trait.
If you were to draw OSGi’s focus areas in terms of bull’s-eyes, hot-pluggability and
autodiscovery would likely be the most visible features from 100,000 feet, with a common
pattern of dynamic behavior emerging between the two.
1. Peter Kriens, “How OSGi Changed My Life,” ACM Queue Vol. 5, No. 8 ( January/February 2008) 1
2 CHAPTER 1 ■ INTRODUCING OS GI
When a damaged disk is replaced on a hot-pluggable disk array, it is said to have been
dynamically configured, since no system shutdown ever takes places. Similarly, an auto-
discovery process by its very definition is something that takes place dynamically; since
no intervention takes places, dependencies are simply autodiscovered.
So if you attempted to summarize the essence behind hot-pluggability and autodiscov-
erability, you would likely agree that all this entails dynamic behavior, which is why OSGi
defines itself as a dynamic module system for Java.2
So it is that today you can see OSGi’s feature set influencing the Java ecosystem, arising
from its origins in the embedded market and spreading to the automotive sector, smart
phones, development tools, and more recently, Java’s de facto standard for server-side
platforms, Java Enterprise Edition (EE).
Armed with this brief overview, let’s dig deeper into where these concepts are applied
in the architecture of a Java application, and what new concepts you need to familiarize
yourself with in order to put OSGi’s feature set to work.
OSGi Concepts and Architecture

Let’s begin the same way most maps illustrating travel routes start out, using a “you are
here” point of reference to illustrate how a non-OSGi Java application evolves into one
using OSGi.
Java’s Virtual Machine, Java Classes, and the

CLASSPATH Variable
Class files made up of bytecode—it doesn’t get any more basic than that for a Java applica-
tion, no matter what operating system you are targeting or whether you’re using 32 bits
or 64 bits, have 64KB or 4GB of memory, or are using the oldest or latest Java version. The
architecture imposed by Java itself forces any application to use class files made up of
bytecode to deliver on Java’s mantra, “write once, run everywhere,” via the Java Virtual
Machine (JVM).
Well, this is excellent for all the benefits of using the JVM, but let’s examine how it is
these class files made up of bytecode interact with the JVM. I will start by mentioning that
a JVM requires precise instructions on where to locate class files needed by the applica-
tions running on it, a process that is achieved using the CLASSPATH variable.
The CLASSPATH variable is a colon- or semicolon-separated list—the former for Unix,
the latter for Windows—containing the location of each class file needed to properly execute
an application running on a JVM. Though individually declaring class files inside the
CLASSPATH variable is possible, declaring groups of classes as a unit is far more typical.
2. OSGi Alliance, “OSGi Technology—The Solution,” http://www.osgi.org/About/Technology#Solution

C HA PTER 1 ■ INTRODUC IN G OSGI 3
The unit format used for the purpose of grouping Java classes is the JAR format, or Java
Archive, which is nothing more than a zipped file containing associated class files.
So it is that once a JVM is started, its bootstrapping classes go on to form part of the
JVM’s memory footprint, with the remaining classes declared in the CLASSPATH variable
being loaded into memory as they are needed by applications.
The mechanism is simple, so simple in fact, that besides the special flag—Xbootclasspath,
which allows the JVM to load certain class files or JAR files before the core Java classes
(a.k.a. bootstrapping classes)—there is no way to add more sophisticated behaviors to the
way the CLASSPATH variable and Java classes interact. In this case, simplicity gives the
following characteristics to your JVM and the applications executing on it:
• One class name and version per class loader (a JVM uses one class loader by default):
Classes are accessible on a last declared–last loaded basis. This means that if for
some reason the same class or multiple JARs containing the same class are declared, it
will be the bytecode contained in the last declared class that is considered valid for
that particular JVM instance. This can have the most serious repercussions when
deploying multiple classes or JAR files, each dependent on different versions of the
same class, as only one class by name can form part of a JVM instance. Class loaders
are an exception to this rule; see the sidebar “Class Loaders: Custom Class Loading
in a JVM” for more background on this concept.
• No dependency awareness between JARs: There is no awareness outside the internal

packaging namespace used in the Java classes themselves and whatever caution is
exerted by the creator of each JAR as to which classes depend on one another. At
best, this can cause the tiresome burden of hunting down unmet class dependen-
cies in an application, or at worst, the versioning clashes already mentioned.
• No modifications to a running JVM: Unless a JVM instance is completely stopped

and restarted again, no upgrade can be performed on either classes or JARs.
CLASS LOADERS: CUSTOM CLASS LOADING IN A JVM
A JVM can support multiple classes by the same name and different version but only using custom class
loaders.
By default a JVM has two class loaders, a bootstrap class loader for JVM classes and a system
class loader for classes declared in the CLASSPATH variable. Additional class loaders can provide isola-
tion for multiple classes by the same name and different version. The following diagram illustrates this
class loader hierarchy.
However, adding more class loaders requires using Java APIs, making class loaders an integral part
of an application’s design that have to be contemplated from the outset. For this reason, most applica-
tions rely on the single-system class loader provided by the JVM, complicating the use of multiple classes
by the same name and different version.
Java EE application servers are the perfect example of class loader use, providing an environment
running on a JVM in which multiple Java applications are deployed. In such cases, class loaders are
fundamental to avoid conflicts between applications running on a server. The subject of class loaders
and Java EE application servers is expanded in Chapter 3.
At first sight, these characteristics may seem minor or even be seen as unreasonable
criticism by someone who is just looking for drawbacks in Java’s CLASSPATH variable and
class file loading. But if thoroughly analyzed, you can conclude they contribute heavily to
some errors and undesired behaviors that are all too common in Java applications.
One such error is that of class-loading conflicts, on occasion referred to as “JAR Hell”
or simply observed as java.lang.IncompatibleClassChangeError. This type of error is
increasingly common in JVMs used for deploying enterprise applications, given the size of
these applications and their often intertwined relationships.
If a sufficiently large application of this kind is deployed on a JVM, it can be extremely
difficult to debug and correct. That can happen, for example, if an application relies on
both library A and library B, and each of these libraries in turn relies on different versions
of the same XML parser or application logger.
Similarly, another error that can be attributed to the characteristics of the CLASSPATH
variable is java.lang.OutOfMemoryException, which is thrown when a JVM cannot allocate
more memory to fulfill its operations. This error is often associated with memory leaks,
due to circular references or unallocated objects in the life cycle of an application.
Last but not least, let’s not forget java.lang.ClassNotFound, which indicates an appli-
cation is missing one particular class in the classpath in order to fulfill its intended purpose.
Since each JAR file does not explicitly indicate what classes it needs or what it can offer the
outside world, solving a java.lang.ClassNotFoundException error can become a pretty
expensive trial-and-error process of adding and removing classes to the CLASSPATH vari-
able, with the potential of introducing versioning conflicts.
The characteristics of the JVM and CLASSPATH also make it awkward, and perhaps risky,
to make changes to a running Java application. When an application is running on a
stand-alone workstation or PC, it may seem trivial to stop and restart it. But as uptime
requirements get more demanding, and availability more essential, it becomes steadily
less acceptable to stop a JVM for class upgrades.
As you’ve probably realized, most of the JVM and CLASSPATH issues presented in the
preceding text exist because they are overlooked by the current JVM technology curve. So
let’s now shift our attention to OSGi’s feature set, which solves many of these issues, and
get moving toward an OSGi-based architecture.
The OSGi Bundle

If there is a central theme to OSGi, it is that of a bundle. A bundle is a group of Java classes
and additional resources equipped with a detailed manifest on all its contents, as well as
additional services needed to give the included group of Java classes more sophisticated
behaviors, to the extent of deeming the entire aggregate a component.3
The first thing you need to realize is that an OSGi bundle is a JAR file. This statement has
one very important consequence: OSGi’s primary building block is not a radical departure
from the packaging model used throughout the Java world; it’s simply a richer type of JAR file.
Still, you may question why the need to reinvent a proven format like a JAR. As it turns
out, a JAR file’s contents are isolated from every other surrounding Java class and action
that occurs inside the JVM, so how do you make a JAR file aware of its surroundings?
This is actually quite easy. State what a JAR file needs to be informed about, what it
requires from the outside world, and what it can offer outsiders. How? By adding OSGi
headers to the MANIFEST.MF file already included in a JAR.4
A MANIFEST.MF file is a simple text file attached to an underlying JAR structure—inside
the META-INF directory—that contains information about its contents. In the case of OSGi
headers, these values express numerous behaviors that allow its contents to reap the
benefits of dynamic loading and all the virtues this entails. Listing 1-1 illustrates a basic
MANIFEST.MF file with OSGi headers.
3. OSGi Alliance, “OSGi Technology—Conclusion,” http://www.osgi.org/About/Technology#Conclusion

4. Sun Microsystems, “Java Archive ( JAR) files,” http://java.sun.com/j2se/1.5.0/docs/guide/jar/
index.html
Listing 1-1. MANIFEST.MF File with OSGi Headers
Bundle-Name: Hello World

Bundle-Description: A Hello World bundle for Pro-Spring OSGi
Bundle-Version: 1.0.0
Bundle-Activator: com.apress.springosgi.ch1.Activator
Export-Package: com.apress.springosgi.ch1;version="1.0.0"
Import-Package: org.osgi.framework;version="1.3.0"
The meaning of the contents in Listing 1-1 is as follows:
• Bundle-Name: Simply assigns a short name to the bundle
• Bundle-Description: Expresses a lengthier description for what the bundle will do
• Bundle-Version: Designates a version number to the bundle
• Bundle-Activator: Indicates the class name to be invoked once a bundle is activated
• Export-Package: Expresses what Java packages contained in a bundle will be made

available to the outside world
• Import-Package: Indicates what Java packages will be required from the outside
world, in order to fulfill the dependencies needed in a bundle
OSGI MANIFEST HEADERS
For those of you wishing to explore the full set of available OSGi manifest headers, you can browse
through the Appendix, which contains a complete list of values. The Appendix is available online at the
Apress web site in the Book Extras section at http://www.apress.com/book/view/9781430216124.
OSGi’s dynamic behavior can best be understood by first looking at the use of Export-
Package and Import-Package, given that these values set the stage for a leaner and smarter
packaging format than that offered by JAR files.
By explicitly declaring these values, a JAR file transformed into an OSGi bundle can
effectively avoid including all but its utmost essential packages and also expose its core
packages to the benefit of other bundles running in the same system. Notice how Listing 1-1
assigns Java package values to the manifest headers Import-Package and Export-Package.
This allows OSGi to dynamically import packages from other bundles, as well as export
packages so they can be dynamically discovered by other bundles. This makes an applica-
tion’s JARs smaller and smarter in terms of the classes it uses.
Also notice how the imported and exported packages in Listing 1-1 are appended with
version values. This further classifies the package version needed by a bundle, as well
as the hosted package version available to other bundles. Note that if version values are
omitted, packages are assumed to be unique.
CLASS LOADERS REVISITED: THE OSGI WAY
A benefit to using OSGi’s bundle format is that an OSGi environment assigns a class loader to each
bundle. This design is the basis on which the OSGi headers Export-Package and Import-Package
function, with each class loader working as a gateway exposing and accessing only those packages
explicitly declared in a manifest.
However, these class loaders are not the same as those created via Java APIs and added to a JVM’s
system class loader; these are OSGi-administered class loaders. The difference could not be more crit-
ical, because instead of designing a class loader hierarchy yourself, OSGi automatically creates one for
you based on bundles. The following diagram illustrates this class loader hierarchy:
So where does this leave the CLASSPATH variable and a JVM’s default class loaders? In the same
place, everything keeps running under the system class loader. It only means an OSGi environment
manages a separate class loader hierarchy, which is in contact with the parent system class loader.
Still, another important piece that has dynamic implications in this OSGi manifest is
the value pertaining to Bundle-Activator. Whereas Export-Package and Import-Package
simply contain values to packages that would otherwise form part of a standard JAR file,
the value for Bundle-Activator—which is a Java class in itself—contains logic that imple-
ments OSGi services.
OSGi services are a critical step to understanding OSGi’s “big picture,” so with a keen
eye read and reread the following paragraphs if necessary until you firmly grasp the concept.
Loosely speaking, an OSGi bundle can have three types of services:
• Management services that are completely agnostic to the business logic contained in
the Java packages that make up the bundle
• Infrastructure services that support the business logic contained in the packages
that make up the bundle
• Business services that expose actual business logic contained in the Java packages
that make up bundle
Referring back to the OSGi manifest you just saw, the class assigned to Bundle-Activator
contains services related to the life cycle of a bundle—what actions to take once a bundle
is loaded into memory—and hence can be considered a management service.
Though not explicitly shown in this OSGi manifest, other types of classes can be asso-
ciated with a bundle containing infrastructure services. When I use the term “infrastructure
services,” it’s to exert the idea of a supporting role for the business logic contained in an
application: services like logging, I/O, HTTP (the Web’s protocol), and XML parsing are
generally considered supportive of the business logic.
In this case, whatever business logic is packed inside an OSGi bundle can make use of
these services in the same dynamic context offered by OSGi. At this juncture, it might not
be entirely clear what you gain by using OSGi services for application logging or XML parsing,
but every bit of infrastructure service reuse is that much code you don’t have to rewrite.
Finally comes the business service, which is perhaps the type of service you may already be
familiar with, providing results on everything from a basic computation to something as
sophisticated as a data query.
The use of all these services is one reason why OSGi bundles are often referred to as
components, since they give that additional behavior generally associated with compo-
nents to the core business logic contained in a bundle. Additionally, these services have
also influenced the tagging of OSGi as a technology for enabling service-oriented archi-
tecture (SOA).
The OSGi specification sets forth a series of predefined services, so up next the discus-
sion will focus on this subset of OSGi services as you familiarize yourself with the actual
OSGi framework.
■Note The OSGi specification makes no distinction between services as it’s expressed in this last section.
In order to help explain the concept of a bundle, this division of management, infrastructure, and business
services was made to let you know some of OSGi’s services are there to serve the bundle itself, others to
support the business logic contained in a bundle, and others to expose business logic. In the remainder of the
book, you will see the term “service” used universally no matter what purpose it serves for a bundle.
The OSGi Framework

You’re now aware of a few benefits that OSGi’s bundle architecture can bring to your
applications, such as the Import and Export package mechanisms that lay the foundations
for sharing classes, but what about those OSGi services than can also be integrated into
bundles? What are they all about? Figure 1-1 illustrates the various layers that make up the
OSGi framework, many of which map to the different types of services.
Figure 1-1. OSGi framework layers
Most of these OSGi layers possess a comprehensive API—like you would expect in any
other Java framework—with which it’s possible to dictate the required service behaviors
for each bundle through Java classes, which are associated to the bundle through its
corresponding manifest.
For now, I won’t bog down this introductory discussion on the OSGi framework with
the dense subject of API classes and methods, but rather state what each of these layers
brings to the table and the capabilities it offers OSGi bundles.
The Security Layer

This subset of the OSGi framework refers to everything related to the security rights of a
bundle. Based on the Java 2 security architecture, it defines how a bundle can be digitally
signed and how security checks can be enforced in the context of the framework.
As OSGi security is based on the Java 2 security model, there is no OSGi security service
API. Instead the framework relies on the presence of this former API to provide security
functionality to a bundle.
As far as the actual security checks are concerned, these are integrated with the OSGi
service APIs pertaining to the life-cycle layer, which is described in the upcoming paragraphs.
The Module Layer

Much like the security layer, the module layer doesn’t have any specific service API, but
rather defines the modularization characteristics needed by the framework itself.
In this sense, the module layer defines the anatomy of a bundle, the corresponding
manifest values it needs to support (which you can find in the Appendix), and how the
class-loading architecture should function, the latter of which would primarily be of
interest to those creating an OSGi framework implementation and not necessarily those
using it.
So let’s move on to an OSGi layer with a little more depth: the life-cycle layer.
The Life-Cycle Layer

The life-cycle layer defines and manages the various states an OSGi bundle can find itself
in at any time, which include the following:
• Active state: Indicates a bundle has been loaded into the actual JVM footprint
• Uninstalled state: Indicates a bundle is effectively uninstalled, meaning no verifica-

tion process has taken place
• Installed state: Indicates a bundle has been validated and is prepared to be activated
• Resolved state: Indicates all dependencies declared for a bundle have been resolved
• Starting state: Indicates a bundle is in the process of transitioning to an active state
• Stopping state: Indicates a bundle is in the process of being stopped

The transition of a bundle from each of these states is caused by either an administra-
tive console in which a user inputs some of these changes or the framework performing
dynamically based on what other actions are taking place in dependent bundles. Figure 1-2
illustrates the life cycle of an OSGi bundle.
Update or
Refresh
Install
Installed
Starting
Start Resolve Update or
Refresh
Uninstall
Active Resolved
Stop
Uninstall
Stopping
Uninstalled
Figure 1-2. OSGi bundle life cycle
Events are another subject inevitably related to life cycles and state changes. In OSGi’s
case, each state transition in the life cycle of a bundle is associated to an event—such as
on install, on update, or on start—which in turn corresponds to an API listener method
that can be used to invoke other services at the time each event presents itself.
If you look back at the OSGi manifest in Listing 1-1, you’ll realize you’re already familiar
with the concept. The Java class assigned to Bundle-Activator is precisely a class containing
OSGi API methods like start() and stop() that are listening for a bundle to enter and exit
its active state, respectively. As for the logic executed inside these methods, it can be pretty
much open-ended like any other Java class, though it’s more likely to contain logic related
to other OSGi services.
Another aspect related to the life cycle of a bundle is its context. If you are familiar with
developing server-side Java with servlets, a context in OSGi works in the same way. It simply
serves as a proxy for the underlying component in the process of executing operations,
such as the following:
• Installing new bundles into an OSGi environment
• Interrogating other bundles installed in an OSGi environment
• Obtaining a persistent storage area
• Registering services in an OSGi environment
• Retrieving service objects of registered services
• Subscribing or unsubscribing to events broadcast by an OSGi environment
Each bundle upon starting is assigned a context, which is constantly accessed to perform
these operations and is destroyed once a bundle is stopped.
With this I’ve covered the bulk of available services in the OSGi life-cycle layer, though
other operations you may encounter in this layer include update methods for a bundle,
the capability to retrieve manifest headers, querying security permissions, and accessing
resources.
Next, you will learn about a closely knit companion to the life cycle that comprises the
last and most extensive layer of the OSGi framework: the service layer.
The Service Layer

Let’s start by clearing up what exactly is implied by the term “service” in this layer, since
in today’s software world the term often has different connotations. A service in OSGi is a
Java object inside a bundle, which is listed in an OSGi service registry for the benefit of
other bundles running in the same JVM.
Based on this, a bundle only has a few courses of action with a service. It can register a
service, it can search for a service, or it can opt to receive notifications when a service changes.
The actual composition of a Java object functioning as a service is a little more compre-
hensive, since as mentioned earlier it can fulfill many duties. The recommended practice
for OSGi services, though, is that they be composed of a Java interface accompanied by an
implementing Java class. This decoupling favors changes to a Java object, without disturbing
the interface on which services are published.
Next, let’s investigate the service interfaces that OSGi provides out of the box—those
that form part of every OSGi distribution. Table 1-1 shows a description of all the OSGi
service interfaces as of OSGi v.4.1
Table 1-1. OSGi Service Interfaces

OSGi Service Function/Purpose
Logging Provides the facilities to log information and retrieve current or older
logger data
Http Service Allows formation to be sent and received from OSGi using HTTP, the
Web’s protocol
Device Access Facilitates the coordination of automatic detection and attachment of
existing devices
Configuration Admin Allows an operator to set the configuration information of
deployed bundles
Metatype Allows services to specify the type information of data (metadata) to
use as arguments
Preferences Offers an alternative, more OSGi-friendly mechanism to using Java’s
default java.util.Properties for storing preference
User Admin Provides authorization based on who runs the code, instead of using
the Java code-based permission model
Wire Admin Comprises an administrative service used to control the wiring
topology (Note that this is intended to be used by user interface
or management programs that control the wiring of services.)
IO Connector Offers an extendable communication API capable of handling
different communication protocols, on different networks,
firewalls, and intermittent connectivity
Initial Provisioning Defines how a management agent can make its way to the
service platform
UPnP Device Service Specifies how OSGi bundles can be developed to interoperate with
Universal Plug and Play (UPnP) devices
Declarative Addresses some of the complications that arise when the OSGi service
model is used for larger systems and wider deployments
Event Admin Provides an interbundle communication mechanism based on a
publish-and-subscribe model
Deployment Admin Standardizes access to some of the responsibilities of the management
agent
Auto Configuration Defines the format and processing rules that allow the autoconfiguration
of bundles
Application Admin Simplifies the management of an environment with many different
types of applications that are simultaneously available
Another random document with
no related content on Scribd:
phosgene and chloropicrin, phosgene and superpalite, and
phosgene and diphenylchloroarsine have been found.
Fig. 26.—Interior of a Shell Dump.
The English introduced the use of projectors in the Spring of

1917. They have a decided advantage over shell in that they hold a
larger volume of gas and readily lend themselves to surprise attacks.
As the Germans say, “the projector combines the advantages of gas
clouds and gas shell. The density is equal to that of gas clouds and
the surprise effect of shell fire is also obtained.”
Toward the close of the war, the Germans made use of a mixture
of phosgene and pumice stone. A captured projector contained
about 13 pounds of phosgene and 5½ pounds of pumice. There
seems to be some question as to the value of such a procedure.
Lower initial concentrations are secured; this is due, in part of
course, to the smaller volume of phosgene in the shell containing
pumice. Pumice does seem to keep the booster from scattering the
phosgene so high into the air, and at the same time does not prevent
the phosgene from being liberated in a gaseous condition. This
would indicate that pumice gives a more even and uniform
dispersion and a more economical use of the gas actually used.
Owing to its non-persistent nature (the odor disappears in from
one and a half to two hours) and to its general properties, phosgene
really forms an ideal gas to produce casualties.
Action on Man
Phosgene acts both as a direct poison and as a strong lung
irritant, causing rapid filling of the lungs with liquid. The majority of
deaths are ascribed to the filling up of the lungs and consequently to
the suffocation of the patients through lack of air. This filling up of the
lungs is greatly hastened by exercise. Accordingly, all rules for the
treatment of patients gassed with phosgene require that they
immediately lie down and remain in that position. They are not even
allowed to walk to a dressing station. The necessity of absolute quiet
for gassed patients undoubtedly partly accounts for the later habit of
carrying out a prolonged bombardment after a heavy phosgene gas
attack. The high explosive causes confusion, forcing the men to
move about more or less and practically prevents the evacuation of
the gassed. In the early days of phosgene the death rate was unduly
high because of lack of knowledge of this action of the gas. Due to
the decreased lung area for oxygenizing the air, a fearful burden is
thrown on the heart, and accordingly, those with a heart at all weak
are apt to expire suddenly when exercising after being gassed.
As an illustration of the delayed action of phosgene, a large scale
raid made by one of the American divisions during its training is
highly illuminating.
This division decided to make a raid on enemy trenches which
were situated on the opposite slope of a hill across a small valley. Up
stream from both of the lines of trenches was a French village in the
hands of the Germans. When the attack was launched the wind was
blowing probably six or seven miles per hour directly down stream
from the village, i.e., directly toward the trenches to be attacked. The
usual high explosive box barrage was put around the trenches it was
intended to capture.
Three hundred Americans made the attack. During the attack a
little more than three tons of liquid phosgene was thrown into the
village in 75- and 155-millimeter shells. The nearest edge of the
village shelled with phosgene was less than 700 yards from the
nearest attacking troops. None of the troops noticed the smell of
phosgene, although the fumes from high explosive were so bad that
a few of the men adjusted their respirators. The attack was made
about 3 a.m., the men remaining about 45 minutes in the vicinity of
the German trenches. The men then returned to their billets, some
five or six kilometers back of the line. Soon after arriving there, that
is in the neighborhood of 9 a.m., the men began to drop, and it was
soon discovered that they were suffering from gas poisoning. Out of
the 300 men making the attack 236 were gassed, four or five of
whom died.
The Medical Department was exceedingly prompt and vigorous in
the treatment of these cases, which probably accounted for the very
low mortality.
This is one of the most interesting cases of the delayed action
that may occur in gassing from phosgene. Here the concentration
was slight and there is no doubt its effectiveness was largely due to
the severe exercise taken by the men during and after the gassing.
It should be remarked in closing that while gas officers were not
consulted in the planning of this attack, a general order was shortly
thereafter issued requiring that gas officers be consulted whenever
gas was to be used.
CHAPTER VII
LACHRYMATORS
Without question the eyes are the most sensitive part of the body
so far as chemical warfare is concerned. Lachrymators are
substances which affect the eyes, causing involuntary weeping.
These substances can produce an intolerable atmosphere in
concentrations one thousand times as dilute as that required for the
most effective lethal agent. The great military value of these gases
has already been mentioned and will be discussed more fully later.
There are a number of compounds which have some value as
lachrymators, though a few are very much better than all the others.
Practically all of them have no lethal properties in the concentrations
in which they are efficient lachrymators, though we must not lose
sight of the fact that many of them have a high lethal value if the
concentration is of the order of the usual poison gas. The
lachrymators are used alone when it is desired to neutralize a given
territory or simply to harrass the enemy. At other times they are used
with lethal gases to force the immediate or to prolong the wearing of
the mask.
A large number of the lachrymators contain bromine. In order to
maintain the gas warfare requirements, it was early decided that the
bromine supply would have to be considerably increased. The most
favorable source of bromine is the subterranean basin found in the
vicinity of Midland, Michigan. Because of the extensive experience of
the Dow Chemical Co. in all matters pertaining to the production of
bromine, they were given charge of the sinking of seventeen
government wells, capable of producing 650,000 pounds of bromine
per year. While the plant was not operated during the War, it was
later operated to complete a contract for 500,000 pounds of bromine
salts. They will be held as a future war asset of the United States.
The principal lachrymators used during the War were:
Bromoacetone,
Bromomethylethylketone,
Benzyl bromide,
Ethyl iodoacetate,
Bromobenzyl cyanide,
Phenyl carbylamine chloride.
Chloropicrin is something of a lachrymator, but it has greater

value as a toxic gas.
Halogenated Ketones
One of the earliest lachrymators used was bromoacetone.
Because of the difficulty of obtaining pure material, the commercial
product, containing considerable dibromoacetone and probably
higher halogenated bodies, was used. The presence of these higher
bromine derivatives considerably decreased its efficiency as a
lachrymator. The preparation of bromoacetone involved the loss of
considerable bromine in the form of hydrobromic acid. This led the
French to study various methods of preparation, and they finally
obtained a product containing 80 per cent bromoacetone and 20 per
cent chloroacetone, which they called “martonite.” As the war
progressed, acetone became scarce, and the Germans substituted
methylethylketone, for which there was little use in other war
activities. This led to the French “homomartonite.”
Various other halogen derivatives of ketones have been studied
in the laboratory, but none have proven of as great value as
bromoacetone, either from the standpoint of toxicity or lachrymatory
power.
Bromoacetone may be prepared by the action of bromine (liquid
or vapor) upon acetone (with or without a solvent). Aqueous
solutions of acetone, or potassium bromide solutions of bromine,
have also been used.
Pure bromoacetone is a water clear liquid. There are great
differences in the properties ascribed to this body by different
investigators. This probably is due to the fact that the monobromo
derivative is mixed with those containing two or more atoms of
bromine. A sample boiling at 126-127° and melting at -54°, had a
specific gravity of 1.631 at 0°. It has a vapor pressure of 9 mm. of
mercury at 20°.
While bromoacetone is a good lachrymator, it possesses the
disadvantage that it is not very stable. Special shell linings are
necessary, and even then the material may be decomposed before
the shell is fired. The Germans used a lead-lined shell, while
considerable work has been carried out in this country with enamel
lined shell. Glass lined shell may also be used. It is interesting to
note that, while bromoacetone decomposes upon standing in the
shell, it is stable upon detonation. No decomposition products are
found after the explosion, and even unchanged liquid is found in the
shell. It may be considered as having a low persistency, since the
odor entirely disappears from the surface of the ground in twenty-
four hours.
Bromoacetone was also used by the Germans in glass hand
grenades (Hand-a-Stink Kugel) and later in metal grenades. The
metal grenades weighed about two pounds and contained about a
pound and a half of the liquid.
Martonite was prepared by the French in an attempt more
completely to utilize the bromine in the preparation of bromoacetone.
They regenerated the bromine by the use of sodium chlorate:
NaClO₃ + 6HBr = NaCl + 3Br₂ + 3H₂O

In practice sulfuric acid is used with the sodium chlorate, so that
the final products are sodium acid sulfate and a mixture of 20 per
cent chloroacetone and 80 per cent bromoacetone, according to the
reaction:
5(CH₃)₂CO + 4Br + H₂SO₄ + NaClO₃ =

4CH₂BrCOCH₃ + CH₂ClCO CH₃ + NaHSO₄ + 3H₂O.
This product is equally as effective as bromoacetone alone and is
very much cheaper to manufacture. In general its properties
resemble very closely those of bromoacetone.
German Manufacture of Bromoacetone

and Bromomethylethyl ketone[17]
These two products were prepared by identical methods. About
two-thirds of the product produced by the factory was prepared from
methylethyl ketone which was obtained from the product resulting
from the distillation of wood. The method employed was to treat an
aqueous solution of potassium or sodium chlorate with acetone or
methylethyl ketone, and then add slowly the required amount of
bromine. The equation for the reaction in the case of acetone is as
follows:
CH₃COCH₃ + Br₂ = CH₂BrCOCH₃ + HBr

Ten kg.-mols of acetone or methylethyl ketone were used in a
single operation. About 10 per cent excess of chlorate over that
required to oxidize the hydrobromic acid formed in the reaction was
used. The relation between the water and the ketone was in the
proportion of 2 parts by weight of the former to 1 part by weight of
the latter. For 1 kg.-mol. wt. of the ketone, 10 per cent excess over 1
kg. atomic-weight of bromine was used.
The reaction was carried out either in earthenware vessels or in
iron kettles lined with earthenware. The kettles were furnished with a
stirrer made of wood, and varied in capacity from 4,000 to 5,000
liters. They were set in wooden tanks and cooled by circulating
water. The chlorate was first dissolved in the water and then the
ketone added. Into this mixture the bromine was allowed to run
slowly while the solution was stirred and kept at a temperature of
from 30° to 40° C. The time required for the addition of the bromine
was about 48 hrs. When the reaction was complete, the oil was
drawn off into an iron vessel and stirred with magnesium oxide in the
presence of a small amount of water in order to neutralize the free
acid. It was then separated and dried with calcium chloride. At this
point a sample of the material was taken and tested. The product
was distilled to tell how much of it boiled over below 130° when
methylethyl ketone had been used. If less than 10 per cent distilled
over, the bromination was considered to be satisfactory. If, however,
a larger percentage of low boiling material was obtained, the product
was submitted to further bromination. The material obtained in this
way was found on analysis to contain slightly less than the
theoretical amount of monobromoketone.
It was finally transferred by suction or by pressure into tank-
wagons. At first lead-lined tanks were used, but later it was found
that tanks made of iron could be substituted. In order to take care of
the small amount of hydrobromic acid, which is slowly formed, a
small amount of magnesium oxide was added to the material. The
amount of the oxide used was approximately in the proportion of 1
part to 1000 parts of ketone. When the magnesium oxide was used,
it was found that the bromoketone kept without appreciable
decomposition for about 2 months. The yield of the product from 580
kg. of acetone (10 kg.-mol. wts.) was 1,100 kg. The yield from 720
kg. of methylethyl ketone (10 kg.-mol. wts.) was 1,250 kg.
Halogenated Esters
The use of ethyl iodoacetate was advocated at a time when the
price of bromine seemed prohibitive. Because of the relative price of
bromine and iodine under ordinary conditions, it is not likely that it
would be commonly used. However, it is an efficient lachrymator and
is more stable than the halogenated ketones, so that on a smaller
scale it might be advisable to use it.
It is prepared by the reaction of sodium iodide upon an alcoholic
solution of ethyl chloroacetate. It is a colorless oil, boiling at 178-
180° C. (69° C. at 12 mm.) and having a density of about 1.8. It is
very much less volatile than bromoacetone, having a vapor pressure
of 0.54 mm. of mercury at 20° C. Ethyl iodoacetate is about one-third
as toxic as bromoacetone, but has about the same lachrymatory
value.
Aromatic Halides
“Benzyl bromide” was also used during the early part of the war,
usually mixed with bromoacetone. The material was not pure benzyl
bromide, but the reaction product of bromine upon xylene, and
should perhaps be referred to as “xylyl bromide.”
Pure benzyl bromide is a colorless liquid, boiling at 198-199° C.,
and having an odor reminiscent of water cress and then of mustard
oil. The war gas is probably a mixture of mono- and dibromo
derivatives, boiling at 210-220° C., and having a density at 20° C. of
1.3. The mixture of benzyl and xylyl bromides used by the Germans
was known as “T-Stoff,” while the mixture of 88 per cent xylyl
bromide and 12 per cent bromoacetone was called “Green T-Stoff.”
As in the case of the halogenated acetones, it is necessary to
use lead lined shell for these compounds. Enamel and glass lined
shell may be used and give good results. While they are difficult of
manufacture, satisfactory methods were being developed at the
close of the war.
“T-Stoff” may be detected by the nose in concentrations of one
part in one hundred million of air, and will cause profuse
lachrymation with one part in a million. It is a highly persistent
material and may last, under favorable circumstances, for several
days. While it is relatively non-toxic, French troops were rendered
unconscious by it during certain bombardments in the Argonne in the
summer of 1915.
A number of derivatives of the benzyl halides have been tested
and some have proven to be very good lachrymators. The difficulty
of their preparation on a commercial scale has made it inadvisable to
use them, and especially inasmuch as bromobenzyl cyanide has
proven to be such a valuable compound.
Bromobenzyl Cyanide
Bromobenzyl cyanide is, chemically, α-bromo-α-tolunitrile, or
phenyl-bromo-acetonitrile, C₆H₅CHBrCN. It is prepared by the
action of bromine upon benzyl cyanide.
Benzyl cyanide is prepared by the action of sodium cyanide upon
a mixture of equal parts of 95 per cent alcohol and benzyl chloride.
The benzyl chloride in turn is obtained by the chlorination of toluene
at 100°. The material must be fairly pure in order that the benzyl
cyanide reaction may proceed smoothly. The cyanide is subjected to
a fractional distillation and that part boiling within 3 degrees (the pure
product boils at 231.7° C.) is treated with bromine vapor mixed with
air. It has been found necessary to catalyze the reaction by sunlight,
artificial light or the addition of a small amount of bromobenzyl
cyanide.
The product obtained from this reaction, if the hydrobromic acid
which is formed is carefully removed by a stream of air, is sufficiently
pure for use as a lachrymator. It melts from 16 to 22° C., while the
pure product melts at 29° C. It cannot be distilled, even in a high
vacuum. It has a low vapor pressure and thus is a highly persistent
lachrymator.
Bromobenzyl cyanide is about as toxic as chlorine, but is many
times as effective a lachrymator as any of the halogenated ketones
or aromatic halides studied. It has a pleasant odor and produces a
burning sensation on the mucous membrane.
Like the other halogen containing compounds, lead or enamel
lined shell are necessary for preserving the material any length of
time. In all of this work the United States was at a very marked
disadvantage. While the Allies and the Germans could prepare
substances of this nature and use them in shell within a month, the
United States was sure that shell filled at Edgewood Arsenal
probably would not be fired within three months. This means that
much greater precautions were necessary, both as to the nature of
the shell lining and as to the purity of the “war gas.”
The question of protection against lachrymatory gases was never
a serious one. During the first part of the war this was amply
supplied by goggles. Later, when the Standard Respirator was
introduced, it was found that ample protection was afforded against
all the lachrymators. Their principal value is against unprotected
troops and in causing men to wear their masks for long periods of
time.
The comparative value of the various lachrymators mentioned
above is shown in the following table:
Bromobenzyl cyanide 0.0003
Martonite 0.0012
Ethyl iodoacetate 0.0014
Bromoacetone 0.0015
Xylyl bromide 0.0018
Benzyl bromide 0.0040
Bromo ketone 0.011
Choroacetone 0.018
Chloropicrin 0.019
The figures give the concentration (milligram per liter of air)
necessary to produce lachrymation. The method used in obtaining
these figures is given in Chapter XXI.
CHAPTER VIII
CHLOROPICRIN
During the spring of 1917, strange reports came from the Italian
front that the Germans were using a new war gas. This gas, while it
did not seem to be very poisonous, had the combined property of
being a lachrymator and also of causing vomiting. Large number of
casualties resulted through the men being forced to remove their
masks in an atmosphere filled with lethal gases. The gas had the
additional and serious disadvantage of being a very difficult one to
remove completely in the gas mask. The first American masks were
very good when chlorine or phosgene was considered but were of no
value when chloropicrin was used.
One of the interesting facts of chemical warfare is that few if any
new substances were discovered and utilized during the three years
of this form of fighting. Chlorine and phosgene were well known
compounds. And likewise, chloropicrin was an old friend of the
organic chemist. So much so, indeed, that several organic
laboratories prepared the compound in their elementary courses.
Chloropicrin was first prepared by the English chemist,
Stenhouse, in 1848, by the action of bleaching powder upon a
solution of picric acid. This was followed by a careful study of its
physical and chemical properties, few of which have any connection
with its use as a poison gas. The use of picric acid as an explosive
made it very desirable that other raw materials should be used.
Chloroform, which is the ideal source theoretically (since chloropicrin
is nitro-chloroform, Cl₃CNO₂), gave very poor yields. While it may be
prepared from acetone, in fair yields, acetone was about as valuable
during the war as was picric acid. Practically all the chloropicrin used
was prepared from this acid as the raw material.
Manufacture
In the manufacture of chloropicrin the laboratory method was
adopted. This consisted simply in passing live steam through a
mixture of picric acid and bleaching powder. The resulting
chloropicrin passes out of the still with the steam. There was a
question at first whether a steam jacketed reaction vessel should be
used, and whether stirrers should be introduced. Both types were
tested, of which the simpler form, without steam jacket or stirrer,
proved the more efficient.
Fig. 27.—Interior of Chloropicrin Plant.
The early work was undertaken at the plant of the American

Synthetic Color Company at Stamford, Connecticut. Later a large
plant was constructed at Edgewood Arsenal. At the latter place ten
stills, 8 by 18 feet, were erected, together with the necessary
accessory equipment. The following method of operation was used:
The bleach is mixed with water and stirred until a cream is
formed. This cream is then pumped into the still along with a solution
of calcium picrate (picric acid neutralized with lime). When the
current of live steam is admitted at the bottom of the still, the
temperature gradually rises, until at 85° C. the reaction begins. The
chloropicrin passes over with the steam and is condensed. Upon
standing, the chloropicrin settles out, and may be drawn off and is
then ready for filling into the shell. The yield was about 1.6 times the
weight of picric acid used.
Properties
Chloropicrin is a colorless oil, which is insoluble in water, and
which can be removed from the reaction by distillation with steam. It
boils at 112° C. and will solidify at -69° C. At room temperature it has
a density of 1.69 and is thus higher than chloroform (1.5) or carbon
tetrachloride (1.59). At room temperature it has a vapor pressure of
24 mm. of mercury. It thus lies, in persistency, between such gases
as phosgene on the one hand, and mustard gas on the other, but so
much closer to phosgene that it is placed in the phosgene group.
Chloropicrin is a very stable compound and is not decomposed
by water, acids or dilute alkalies. The reaction with potassium or
sodium sulfite, in which all the chlorine is found as potassium or
sodium chloride, has been used as an analytical method for its
quantitative determination. The qualitative test usually used consists
in passing the gas-air mixture through a heated quartz tube, which
liberates free chlorine. The chlorine may be detected by passing
through a potassium iodide solution containing starch, or by the use
of a heated copper wire gauze, when the characteristic green color is
obtained.
An interesting physiological test has also been developed. The
eye has been found to be very sensitive to chloropicrin. The gas
affects the eye in such a way that its closing is practically involuntary.
A measurable time elapses between the instant of exposure and the
time when the eye closes. Below 1 or 2 parts per million, the average
eye withstands the gas without being closed, though considerable
blinking may be caused. Above 25 parts, the reaction is so rapid as
to render proper timing out of the question. But with concentrations
between 2 and 25 parts, the subject will have an overpowering
impulse to close his eye within 3 to 30 seconds. The time may be
recorded by a stop watch and from the values thus determined a
calibration curve may be plotted, using the concentration in parts per
million and the time to zero eye reaction. Typical figures are given
below. It will be noted that different individuals will vary in their
sensitivity, though the order is the same.
Conc. A B
p.p.m. Seconds Seconds
20.0 4.0 5.0
15.0 5.4 5.4
10.0 7.5 7.5
7.5 9.0 10.0
5.0 13.0 15.0
2.5 18.0 30.0
Fig. 28.—Calibration Curve of Eyes for Chloropicrin.
Protection
Because of the stability of chloropicrin, the question of protection
resolves itself into finding an absorbent which is very efficient in
removing the gas from air mixtures. Fortunately such an agent was
found in the activated charcoal used in the American gas mask. The
removal of the gas appears to take place in two stages. In the first,
the gas is adsorbed in such a way that the long-continued passage
of air does not remove it. In the second, the gas is absorbed, and
this, really excess gas, is removed by pure air passing over the
charcoal. The relation of these two factors has an important bearing
on the quality of charcoal to be used in gas masks. It appears that up
to a certain point an increase of the quality is desirable: beyond this,
it is of doubtful value.
Unlike phosgene, chloropicrin is absorbed equally well at all
temperatures. Moisture on the other hand has a very decided effect.
It appears that charcoal absorbs roughly equivalent weights of
chloropicrin and of water; the presence of water in the charcoal thus
displaces an approximately equal amount of chloropicrin.
In the study of canisters it has been found that the efficiency time
is approximately inversely proportional to the concentration.
Formulas have been calculated to express the relation existing
between concentration and life of the canister, and also between the
rate of flow of the gas and the life.
While water seems to have a decidedly marked effect upon the
life of a canister, this is not true of other gases, and the efficiency of
the canister for each gas is not decreased when used in a binary
mixture.
Tactical Uses
Because of the high boiling point of chloropicrin it can only be
used in shell. The German shell usually contained a mixture of
superpalite (trichloromethyl chloroformate) and chloropicrin, the
relative proportions being about 75 to 25. These were called Green
Cross Shell, from the peculiar marking on the outside of the shell.
Mixtures of phosgene and chloropicrin (50-50) have also been used.
The Allies have used a mixture of 80 per cent chloropicrin and 20
per cent stannic chloride (so-called N. C.). This mixture combines
the advantages of a gas shell with those of a smoke shell, since the
percentage of stannic chloride is sufficiently high to form a very good
cloud. In addition to this, it is believed that the presence of the
chloride increases the rate of evaporation of the chloropicrin. It has
been claimed that the chloride decreases the amount of
decomposition of the chloropicrin upon the bursting of the shell, but
careful experiments appear to show that this decomposition is
negligible and that the stannic chloride plays no part in it. This
mixture was being abandoned at the close of the war.
This N. C. mixture has also been used in Liven’s projectors and
in hand grenades. The material is particularly fitted for hand
grenades, owing to the low vapor pressure of the chloropicrin, and
the consequent absence of pressures even on warm days. As a
matter of fact, it was the only filling used for this purpose, though
later the stannic chloride was changed, owing to the shortage of tin,
to a mixture of silicon and titanium chlorides.
While chloropicrin is sufficiently volatile to keep the strata of air
above it thoroughly poisonous, it is still persistent enough to be
dangerous after five or six hours.
CHAPTER IX
DICHLOROETHYLSULFIDE
“MUSTARD GAS”
The early idea of gas warfare was that a material, to be of value as

a war gas, should have a relatively high vapor pressure. This would, of
course, provide a concentration sufficiently high to cause casualties
through inhalation of the gas-ladened air. The introduction of “mustard
gas” (dichloroethylsulfide) was probably the greatest single
development of gas warfare, in that it marked a departure from this
early idea, for mustard gas is a liquid boiling at about 220° C., and
having a very low vapor pressure. But mustard gas has, in addition, a
characteristic property which, combined with its high persistency,
makes it the most valuable war gas known at the present time. This
peculiar property is its blistering effect upon the skin. Very low
concentrations of vapor are capable of “burning” the skin and of
producing casualties which require from three weeks to three months
for recovery. The combination of these properties removed the
necessity for a surprise attack, or the building up of a high
concentration in the first few bursts of fire. A few shell, fired over a
given area, were sufficient to produce casualties hours and even days
afterwards.
Mustard gas, chemically, is dichloroethylsulfide (ClCH₂CH₂)₂S.
The name originated with the British Tommy because the crude
material first used by the Germans was suggestive of mustard or
garlic. Various other names were given the compound, such as
“Yellow Cross,” from the shell markings of the Germans; “Yperite,” a
name used by the French, because the compound was first used at
Ypres; and “blistering gas,” because of its peculiar effect upon the
skin.
Historical
It seems probable that an impure form of mustard gas was
obtained by Richie (1854) by the action of chlorine upon ethyl sulfide.
The substance was first described by Guthrie (1860), who recognized
its peculiar and powerful physiological effects. It is interesting in this
connection to note that Guthrie studied the effect of ethylene upon the
sulfur chlorides, since this reaction was the basis of the method finally
adopted by the Allies.
The first careful investigation of mustard gas, which was then only
known as dichloroethylsulfide, was carried out by Victor Meyer (1886).
Meyer used the reaction between ethylene chlorhydrin and sodium
sulfide, with the subsequent treatment with hydrochloric acid. All the
German mustard gas used during 1917 and 1918 was apparently
made by the use of these reactions, and all the early experimental
work of the Allies was in this direction.
Mustard gas was first used as an offensive agent by the Germans
on July 12-13, 1917, at Ypres. According to an English report, the
physiological properties of mustard gas had been tested by them
during the summer of 1916. The Anti-Gas Department put forward the
suggestion that it should be used for chemical warfare, but at that time
its adoption was not approved. This fact enabled the English to quickly
and correctly identify the contents of the first Yellow Cross dud
received. It is not true, as reported by the Germans, that the material
was first diagnosed as diethylsulfide.
The tactical value of mustard gas was immediately recognized by
the Germans and they used tremendous quantities of it. During ten
days of the Fall of 1917, it is calculated that over 1,000,000 shell were
fired, containing about 2,500 tons of mustard gas. Zanetti states that
the British gas casualties during the month following the introduction of
mustard gas were almost as numerous as all gas casualties incurred
during the previous years of the war. Pope says that the effects of
mustard gas as a military weapon were indeed so devastating that by
the early autumn of 1917 the technical advisers of the British, French,
and American Governments were occupied upon large scale
installations for the manufacture of this material.
Preparation and Manufacture

Full Chapter Pro Spring Dynamic Modules For Osgi Service Platforms Expert S Voice in Open Source Rubio Daniel PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Full Chapter Pro Spring Dynamic Modules For Osgi Service Platforms Expert S Voice in Open Source Rubio Daniel PDF

Uploaded by

Copyright:

Available Formats

Pro Spring Dynamic Modules for OSGi

Service Platforms Expert s Voice in

Spring Persistence with Hibernate Expert s Voice in

Hibernate Recipes A Problem Solution Approach Expert s

Beginning Database Driven Application Development in

Pro Hibernate and MongoDB The Expert s Voice Leonard

Beginning Java and Flex Migrating Java Spring Hibernate

JavaFX 2 0 Introduction by Example Expert s Voice in

Pro linux system administration Learn to build systems

Pro linux system administration Learn to build systems

About the Author . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi

■CHAPTER 1 Introducing OSGi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

About the Author . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi

■CHAPTER 1 Introducing OSGi ...........................................1

OSGi Concepts and Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

■CHAPTER 2 Introducing Spring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

Spring Concepts and Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

■CHAPTER 3 Integrating Spring and OSGi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

OSGi’s Synergy with Spring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

■CHAPTER 4 Spring Dynamic Modules for OSGi . . . . . . . . . . . . . . . . . . . . . . 149

Extenders and Fragments in Spring-DM . . . . . . . . . . . . . . . . . . . . . . . . . 149

■CHAPTER 5 SpringSource dm Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177

■CHAPTER 6 Versioning with OSGi and Spring . . . . . . . . . . . . . . . . . . . . . . . . 231

Benefits and Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231

■CHAPTER 7 Data Access and Bundle Management Without

■CHAPTER 8 Web Applications Using Spring and OSGi . . . . . . . . . . . . . . . 303

Web Bundle Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303

■CHAPTER 9 Testing with Spring and OSGi . . . . . . . . . . . . . . . . . . . . . . . . . . . 331

Testing with OSGi and Spring-DM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331

■DANIEL RUBIO is a consultant with over 10 years of experience in

■GERD WÜTHERICH is a consultant and software architect living in

As a consequence of applying OSGi principles to enterprise Java applications, the

Who This Book Is For

How This Book Is Structured

Downloading the Code

Contacting the Author

O SGi—originally an acronym for Open Services Gateway Initiative—emerged in 1999 to

OSGi Concepts and Architecture

Java’s Virtual Machine, Java Classes, and the

2. OSGi Alliance, “OSGi Technology—The Solution,” http://www.osgi.org/About/Technology#Solution

• No dependency awareness between JARs: There is no awareness outside the internal

• No modifications to a running JVM: Unless a JVM instance is completely stopped

CLASS LOADERS: CUSTOM CLASS LOADING IN A JVM

The OSGi Bundle

3. OSGi Alliance, “OSGi Technology—Conclusion,” http://www.osgi.org/About/Technology#Conclusion

Listing 1-1. MANIFEST.MF File with OSGi Headers

Bundle-Name: Hello World

The meaning of the contents in Listing 1-1 is as follows:

• Bundle-Name: Simply assigns a short name to the bundle

• Bundle-Description: Expresses a lengthier description for what the bundle will do

• Bundle-Version: Designates a version number to the bundle

• Bundle-Activator: Indicates the class name to be invoked once a bundle is activated

• Export-Package: Expresses what Java packages contained in a bundle will be made

OSGI MANIFEST HEADERS

CLASS LOADERS REVISITED: THE OSGI WAY

The OSGi Framework

Figure 1-1. OSGi framework layers

The Security Layer

The Module Layer

The Life-Cycle Layer

• Uninstalled state: Indicates a bundle is effectively uninstalled, meaning no verifica-

• Starting state: Indicates a bundle is in the process of transitioning to an active state

• Stopping state: Indicates a bundle is in the process of being stopped