OSGi

使用 eclipse 的 export -> "deployable plugins and fragments" 导出 bundle jar 到 Felix 目录下，该 jar 会被放到一个叫 plugins 的目录下，而不是默认的 bundle 目录下。这两个目录，或者说在 osgi 环境下 bundle 与 plugin 有区别吗？答案是没有区别，只是 felix 将一个 osgi 服务叫做 bundle，而 eclipse 通常称其为 plugin 而已： 所以在 osgi 的语境下我们认为：
bundle = Deployable service = plugin，一般就是个jar包。

All these restrictions are enforced via a specific OSGi classloader. Each bundle has its own classloader . Access to restricted classes is not possible.

A bundle is the OSGi term for a component for the OSGi framework

In the context of OSGi, where a typical application depends on multiple class loaders (one for each bundle), it is important to understand that the fully-qualified class name—for example, org.foo.Hello—is not sufficient to identify a loaded class uniquely. In general, a loaded class is uniquely identified by combining the classloader identity with the fully-qualified class name.

Import-Package：the packages that it needs to run
Export-Package：the packages that it may export for other bundles to use
Bundle-RequiredExecutionEnvironment：the execution environment that it requires

Chapter 5. Bundles and Application Contexts
The unit of deployment (and modularity) in OSGi is the bundle (see section 3.2 of the OSGi Service Platform Core Specification). A bundle known to the OSGi runtime is in one of three steady states: installed, resolved, or active. Bundles may export services (objects) to the OSGi service registry, and by so doing make these services available for other bundles to discover and to use. Bundles may also export Java packages, enabling other bundles to import the exported types.
In Spring the primary unit of modularity is an application context, which contains some number of beans (objects managed by the Spring application context). Application contexts can be configured in a hierarchy such that a child application context can see beans defined in a parent, but not vice-versa. The Spring concepts of exporters and factory beans are used to export references to beans to clients outside of the application context, and to inject references to services that are defined outside of the application context .
There is a natural affinity between an OSGi bundle and a Spring application context. Using Spring Dynamic Modules, an active bundle may contain a Spring application context, responsible for the instantiation, configuration, assembly, and decoration of the objects (beans) within the bundle. Some of these beans may optionally be exported as OSGi services and thus made available to other bundles, beans within the bundle may also be transparently injected with references to OSGi services.

After a refreshPackages operation, packages exported by older versions of updated bundles, or packages exported by uninstalled bundles, are no longer available.

When a Spring-powered bundle is stopped, the application context created for it is automatically destroyed.

If a Spring-powered bundle that has been stopped is subsequently re-started, a new application context will be created for it.

The Spring extender recognizes a bundle as "Spring-powered" and will create an associated application context when the bundle is started and one or both of the following conditions is true:
The bundle path contains a folder META-INF/spring with one or more files in that folder with a '.xml' extension.
META-INF/MANIFEST.MF contains a manifest header Spring-Context.