Chapter 5. What is new?

While a relatively young project, each version of Gemini Blueprint (even minor ones) offers new functionality. This chapter is a guide to the new and improved feature and intended as a high-level, short summary. Please follow the appropriate links for more in-depth information.

This section includes the updates from Spring Dynamic Modules (Spring DM) project:

5.1. Gemini Blueprint

5.1.1. OSGi 4.2 Blueprint Reference Implementation (RI)

Gemini Blueprint served as the basis for the Blueprint Container specification, introduced by OSGi 4.2. Gemini Blueprint stands as the RI for the aforementioned specification, providing the Blueprint API and implementation out of the box. Various aspect of Gemini Blueprint have been adjusted for consistency to the Blueprint specification. For more information on the two models, see Chapter 6, OSGi 4.2 Blueprint Container for more information.

5.1.2. Java 5

Gemini Blueprint requires JDK 5 to run (or compile). The framework code has been revised to take advantage of the JDK 5 features such as language improvements, concurrency and generics: for example, various enum-like classes used by the exporter and importer API have been deprecated and replaced with proper Java 5enums. Considerable effort has been spent to keep the code backwards compatible however, it is recommended to compile the code against the Gemini Blueprint 2.x code and perform sanity checks before upgrading.

5.1.3. Spring 3.x

Besides the Java 5 upgrade, Gemini Blueprint requires Spring 3.x to get access to the latest framework features and JDK optimizations.

5.1.4. Service Importer Improvements

Gemini Blueprint provides several improvements for service imports (whether single or collection based) in terms of speed, configuration and service lifecycle. Section 9.2, “Defining References To OSGi Services” provides more details.

5.1.5. Java 2 Security Integration

Continuing the work in Spring DM 1.2.x, Gemini Blueprint executes all user code using its credentials (the managed bundle permissions). See Appendix A, Security Integration for more information.

5.2. Spring DM 1.2.x

5.2.1. Java 2 Security Integration

Since 1.2.x, Spring DM is aware of secured environments by making use of dedicated privileged blocks for executing security sensitive code. Thus, Spring DM can run as a trusted library without requiring escalated permissions for its managed bundles. See Appendix A, Security Integration for more information.

5.2.2. Compendium Services Support

1.2.x provides integration with the Configuration Admin, part of the OSGi compendium services. Chapter 11, Compendium Services provides more details on the topic.

5.2.3. Changed Spring DM Symbolic Names

Since 1.2.0 M2, the Spring DM bundles symbolic names have been aligned with Spring's 2.5.6+. Thus the prefix org.springframework.bundle.osgi has been changed to org.eclipse.gemini.blueprint; for example Spring DM extender symbolic name was changed from org.springframework.bundle.osgi.extender to org.eclipse.gemini.blueprint.extender (notice the missing bundle word). Additionally, the documentation has been updated to reflect Spring 2.5.6+ symbolic names.

5.2.4. Usage of SpringSource Enterprise Bundle Repository (EBR)

To minimize the number of repositories used and the confusion caused by OSGified vs non-OSGified artifacts especially to users using SpringSource dm Server, after 1.2.0 RC1, Spring DM aligned as many of its dependencies as possible with SpringSource EBR. In practice this means that Spring framework artifacts, such as spring-aop.jar can be now found as org.springframework.aop.jar; We apologize for any inconvenience created to users relying on these naming conventions.