OSGi

  

一个 web 项目，可以通过将各个 layer（prensentation - service - model - dao）的 classes，单独打成 jar， 实现 development time modularity. 但是，这些 module 最终还是需要作为 war 的依赖部署到web container 中，任何一个jar的变更，还是需要重新部署整个war。
OSGi带来的是，是 runtime module system.比如在不用重新部署整个web项目的情况单独升级某个dao jar。



An introduction to OSGi:
http://www.developerfusion.com/article/84923/an-introduction-to-osgi/


OSGi Modularity - Tutorial：
http://www.vogella.com/tutorials/OSGi/article.html

引用

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

引用

1.2. Bundle vs. plug-in
In Eclipse the smallest unit of modularization is a plug-in. The terms plug-in and bundle are (almost) interchangeable. An Eclipse plug-in is also an OSGi bundle and vice versa.

所以在 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.

Apache Felix Framework Usage Documentation:
http://felix.apache.org/documentation/subprojects/apache-felix-framework/apache-felix-framework-usage-documentation.html

引用

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

OSGi and Class Loader：
https://access.redhat.com/documentation/en-US/Red_Hat_JBoss_Fuse/6.0/html/Managing_OSGi_Dependencies/files/BCL-ClassLoader.html

引用

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.

Remote services(aka, Dosgi - distributed osgi)：
http://blog.akquinet.de/2009/09/14/dynamokos-dealing-with-dynamism-in-osgi-distributed-web-applications/



eclipse 下 osgi 项目的创建与 deploy：
https://blogs.oracle.com/arungupta/entry/totd_126_creating_an_osgi


Introduction to the Apache Felix DependencyManager – part two
http://arnhem.luminis.eu/introduction-apache-felix-dependencymanager-part-2/


常见 OSGI MANIFEST.MF configs：

引用

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

Spring DM
http://docs.spring.io/osgi/docs/current/reference/html-single/

引用

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.

OSGi Specification, 6.0:
http://www.osgi.org/download/r6/osgi.core-6.0.0.pdf


The difference between a jar and a bundle：
http://konigsberg.blogspot.com/2009/04/difference-between-jar-and-bundle.html


Discovering the future of Java
http://javadepend.wordpress.com/2012/10/31/discovering-the-future-of-java/

SpringSource to move dmServer to Eclipse – OSGi not ready for mainstream?
http://www.theserverside.com/discussions/thread.tss?thread_id=59183