Author: mcculls
Date: Sun Feb 22 07:21:52 2009
New Revision: 861
Modified:
wiki/OSGi.wiki
Log:
Edited wiki page through web user interface.
Modified: wiki/OSGi.wiki
==============================================================================
--- wiki/OSGi.wiki (original)
+++ wiki/OSGi.wiki Sun Feb 22 07:21:52 2009
@@ -1,22 +1,32 @@
#summary Using Guice in an OSGi container
=OSGi=
-OSGi is a dynamic module system, used in many projects including
[http://www.eclipse.org/ Eclipse] and [https://glassfish.dev.java.net/
Glassfish]. Guice integrates with OSGi via the third-party
[http://code.google.com/p/peaberry/ peaberry] project.
+[http://www.osgi.org/ OSGi] is a dynamic module system used in many
projects including [http://www.eclipse.org/ Eclipse] and
[https://glassfish.dev.java.net/ GlassFish]. A module in OSGi is known as a
bundle - basically a JAR with additional metadata. This metadata describes
the bundle's identity, what packages it needs, and what it provides. Guice
added OSGi metadata in its second release, which means you can now install
it as a bundle on any modern OSGi container.
-===What are the benefits of peaberry?===
-Peaberry exposes a fluent API to publish and consume OSGi services.
+OSGi containers also provide a shared service registry, which supports
dynamic collaboration between bundles by letting them publish and consume
services on-the-fly in the same JVM. Guice can integrate with the OSGi
service registry via the third-party *[http://code.google.com/p/peaberry/
peaberry]* extension.
-You can inject OSGi services, just like any other Guice binding. When that
service is reloaded, the binding transparently continues to work.
+===Can I use Guice in an OSGi environment without peaberry?===
+Short answer: yes!
-You can expose bound types as OSGi services.
+Long answer: Guice is a valid OSGi bundle which contains code to
transparently support AOP inside OSGi containers. You can share module
bindings and injectors between your OSGi bundles and use method
interception on public methods, without needing the peaberry extension.
-===Can I use Guice in an OSGi environment without peaberry?===
-Yes.
+===What are the benefits of peaberry?===
+peaberry exposes a fluent API to publish and consume _dynamic services_.
It provides integration with the OSGi service registry out of the box and
has plug-in support for other registry-based service frameworks. Think of
peaberry as the equivalent of [http://www.springsource.org/osgi Spring
Dynamic-Modules], but with the type-safety and performance of Guice, and
the ability to work with other service frameworks - not just OSGi.
-===What are the constraints of using Guice's OSGi support?===
-Guice uses [ClassLoading bytecode generation] for AOP, faster reflection,
and to proxy circular dependencies. If you dynamically unload an OSGi
module, it's necessary to unload the generated bytecode as well. Otherwise
each time the application is dynamically reloaded, memory will be leaked.
+With peaberry you can inject OSGi services just like any other Guice
binding. The bindings remain valid and transparently continue to work as
services are updated. You can inject `Export` handles that let you publish
and unpublish instances (or bound types) as OSGi services. You can even use
a form of _outjection_ to watch for changes in injected services.
-The simplest solution is to *use dynamic module reloading sparingly*. It's
usually fine to do a full JVM shutdown when a production service is
upgraded. This also avoids problems like serialization-compatibility for
HTTP session objects.
+Last, but definitely not least, peaberry brings OSGi service support to
your existing Guice application without introducing any OSGi specific
types. You can switch between a fixed Java instance or an OSGi service for
the same injection point just by changing your binding modules.
-Otherwise, you need to make sure that reflectively-invoked members are
visible to the generated bytecode. In particular, *avoid intercepting
package-private methods*.
+===What are the constraints of using Guice's OSGi support?===
+Guice uses [ClassLoading bytecode generation] for AOP, faster reflection,
and to proxy circular dependencies. The generated bytecode must be able to
see both the original client type (available from the client classloader)
and AOP internals (available from the Guice classloader), but in OSGi these
classloaders will be isolated from one another. The client classloader will
only see its own types and imports, while Guice will only see its own types
and imports.
+To support AOP in OSGi without requiring clients to know about AOP
internals, or vice-versa, Guice automatically creates and manages _bridge_
classloaders that bridge between client and Guice classloaders. The bridge
classloaders also support eager unloading of proxy classes, which reduces
the potential for memory leaks when reloading bundles.
+This is only possible when the types involved are *not package-private*
(because by definition package-private types are not visible from other
classloaders). If you attempt to use AOP on package-private types while
running inside an OSGi container you will see the following exception:
+{{{
+ ClassNotFoundException: com.google.inject.internal.cglib.core.ReflectUtils
+}}}
+because bridging wasn't possible. If you need to use AOP with
package-private types or methods in OSGi then you can always put Guice and
the AOP Alliance JAR on the main classpath and use the
`org.osgi.framework.bootdelegation` property to expose the Guice packages,
like so:
+{{{
+ "-Dorg.osgi.framework.bootdelegation=org.aopalliance.*,com.google.inject.*"
+}}}
+You can still dynamically unload and reload bundles when using
bootdelegation with Guice, but you would need to restart the JVM to replace
the Guice bundle itself. This is much less likely to happen compared to
upgrading client bundles, and it's usually fine to do a full shutdown when
a key production service is upgraded. This also avoids potential problems
like serialization-compatibility for HTTP session objects.
\ No newline at end of file
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"google-guice-dev" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/google-guice-dev?hl=en
-~----------~----~----~----~------~----~------~--~---
