Support OSGi classloading in Guice

[gissuebot]

From mcculls on April 20, 2007 05:33:19

Here's a simple patch that lets you use Guice on OSGi (including method interception)

For a more detailed example see my local sandpit project: https://scm.ops4j.org/repos/ops4j/laboratory/users/stuart/peaberry it doesn't do a lot at the moment but it does successfully use several Guice features.

Attachment: gist    _GUICE_OSGI.patch_

Original issue: http://code.google.com/p/google-guice/issues/detail?id=94

[gissuebot]

From kevinb9n on April 20, 2007 07:48:25

(No comment was entered for this change.)

Owner: crazyboblee
Labels: -Type-Defect Type-Enhancement

[gissuebot]

From mcculls on April 25, 2007 09:44:18

Hi, I've taken this a bit further and extended the patch to also update the build process.

It now adds OSGi metadata to the Guice jar using the Bnd bundle tool from http://www.aqute.biz/Code/Bnd .

With this patch and the bnd-0.0.130.jar (which needs to be copied to lib/build) the Guice Jar can be dropped straight into an OSGi framework without any further wrapping or embedding.

Attachment: gist    _GUICE_OSGI_TRUNK.patch_ Binary attachments: bnd-0.0.130.jar

[gissuebot]

From mcculls on May 15, 2007 22:45:17

Refactored patch wrt. latest trunk changes, and updated BND library to 0.0.134

Attachment: gist    _GUICE_OSGI_TRUNK_20070516.patch_ Binary attachments: bnd-0.0.134.jar

[gissuebot]

From dev2null on May 16, 2007 09:14:45

You might want to use bnd 0.0.135 or later if running on Windows or else the ant script fails. (0.0.134 still keeps a file handle to the input jar files that's wrapped).

[gissuebot]

From mcculls on June 23, 2007 01:21:49

FYI, see http://wiki.ops4j.org/confluence/display/ops4j/Guice-OSGi for further work combining Guice and OSGi.

[gissuebot]

From dev2null on July 04, 2007 01:02:16

I'd like to include Guice in an Eclipse RCP application where OSGi support is needed. Stuarts class loading patch has worked fine for my initial tests. Any chance that the basic patch will be applied to Guice?

[gissuebot]

From mario.scalas on July 20, 2007 05:21:16

I'm interested too in using Guice along OSGi bundles.

[gissuebot]

From alex.horn on July 20, 2007 06:17:10

I agree. OSGi is practically speaking an Inversion of Control framework. There are different ways of managing services within OSGi. The OSGi compendium, for instance, introduces Declarative Services as an alternative to handling services manually. The downside of Declarative Services is that it introduces an XML configuration file that is responsible to bind and unbind services (read inject and release service providers).

Guice, however, does a fine job of leveraging annotation (as opposed to XML) to meet developers’ dependency injection needs. I truly think Guice is a perfect fit for OSGi component model programming because it has the capability to do the same as Declarative Services but in a Java-friendly way.

[gissuebot]

From bslesinsky on July 21, 2007 11:26:34

It's not my decision and I know very little about OSGi, but I'm guessing that we should leave any OSGi-specific adapters to be done as an extension outside of Guice, by the folks who have expertise in it.  This way it doesn't confuse the folks who are not using OSGi.

It looks like the intent of the patch to Guice is to allow it to be configured to create classes using a custom class loader.  Can this patch be refactored as a generic hook that can then be used by a guice-osgi extension?

[gissuebot]

From alex.horn on July 21, 2007 12:49:17

Looking at the path, I think your observations are accurate. An extension would serve the project better because we could make changes to the OSGi functionality without breaking non-OSGi injection mechanism. Maybe it's not even a matter of introducing new annotations but simply sub-classing the existing Guice implementation classes and overwriting the necessary methods. Then, if someone wants to use OSGi, all they would need to do is pull in the guice-osgi jar and off they go (which would inhibit them from using non-OSGi mechanism though). The original author of the patch may have suggestions on what he thinks is best to refactor his patch.

[gissuebot]

From bslesinsky on July 21, 2007 15:22:57

The main thing is to clarify the contract for the hook, so that we can write unit tests to ensure that it continues to work, or alternately to provide a heads-up when it changes.

[gissuebot]

From mcculls on July 22, 2007 06:37:57

FYI, the latest form of the patch (currently done as a m2 project - see above link) could easily be split into a generic classloader hook, possibly using the factory pattern?, and an OSGi specific extension that provides the @OSGiService bindings.

I'd like to keep OSGi service injection as separate annotations, as this provides a controlled migration for existing Guiced and non-Guiced projects, rather than assuming that every dependency injection should go via the OSGi service registry.

I'll have a go at refactoring it this week - using a factory approach to provide classloaders would also allow the OSGi implementation to do some (weak) caching to avoid creating duplicate 'bridge' classloaders...

[gissuebot]

From alex.horn on July 22, 2007 15:29:35

As you put time and effort into this patch, I am interested as far as how you envision the Guice/OSGi solution to compare to the native Service Component Runtime strategy (i.e. declarative services).

[gissuebot]

From bslesinsky on July 22, 2007 22:49:06

I did some reading about OSGi and much of the above makes more sense to me now.

It seems like Guice itself should be considered a library rather than as a service. There's no notion of starting or stopping Guice.  I suppose that you could make any library into a service, and that would make it easier to upgrade the library used by a long-running JVM to a new version and remove the old version when no clients depend on it anymore.  However, if that's the case, shouldn't this be solved generically for all Java libraries?

There's also an impedance mismatch between Guice injection and OSGi services, in that Guice injects a hard reference to some instance without any notion of it being a service that might disappear, while much of the point of OSGi is that services can appear and disappear at runtime.  So, I think I agree that having a separate @OSGiService annotation makes sense because there are really two different concepts.  (Although, possibly something might be done with Guice scopes?)

[gissuebot]

From dev2null on July 23, 2007 00:51:18

Are there other class loader strategies that you think may be needed or would the GuiceClassLoader from the original path cover the known needs?

[gissuebot]

From mcculls on July 23, 2007 01:35:23

I think making it a generic classloader hook (using a factory pattern) is best, as while the GuiceClassLoader from the original patch is fine for OSGi, it would result in a lot of unnecessary classloaders for standard environments which only have, say, one app classloader.

Providing a hook would also allow other containers to use their custom classloaders with Guice.

[gissuebot]

From mcculls on July 23, 2007 01:58:02

alex.horn:

the Guice-OSGi lab work is complementary to declarative services, in that both inject service dependencies, but declarative services does more wrt. handling component life-cycle. However, it should be possible to implement DS on top of Guice-OSGi, by providing code to read the component's XML metadata and turn it into bindings. You could also use DS and Guice-OSGi together in the same application.

what's more interesting is the new OSGi component model RFP (inspired by Spring-OSGi) which is still being designed - it would be great to have this working on both Spring and Guice, as it would hopefully indicate a good design choice

btw, I was running an OSGi tutorial a few months ago and demo'd some of the Guice-OSGi work, and people seemed to pick up the concept much quicker than with DS ... I'd like to think this was due to the annotations, but can't say for sure!

[gissuebot]

From mcculls on July 23, 2007 02:08:54

bslesinsky:

OSGi already supports multiple versions of a library running in the same process, and dynamic updating of libraries without having to restart - this is separate to the OSGi service registry. So Guice could be a library bundle running alongside a Guice-OSGi bundle that provided service dependency injection.

Interesting thought about scopes: bundles have a well-defined lifecycle, so a bundle scope may be possible...

BTW, wrt. impedance mismatch, you see the same issue with Spring-OSGi where proxies help bridge the gap

[gissuebot]

From bslesinsky on July 23, 2007 09:58:16

Well, I still have basic questions about OSGi:

One is whether it's good practice in OSGi to make every Java library its own bundle.  Do Guice's dependencies need to be bundles as well?  Or on the other hand, suppose that the Guice-OSGI bundle simply included the Guice library and its dependencies? That seems somewhat simpler.

It seems like both approaches have been taken for Jetty; I found a page for the org.osgi.service.http.HttpService as provided by Oscar, which seems to use Jetty. On the other hand, Jetty seems to be its own bundle now.

Also, I haven't figured out yet how you keep a reference to an OSGi service in a way that allows it to go away.  The org.osgi.service.component.ComponentInstance interface seems very similar to Guice's Provider interface.  Is that what people use?

[gissuebot]

From mcculls on July 24, 2007 02:19:33

> whether it's good practice in OSGi to make every Java library its own bundle.

no set practice: having a bundle for every library is good in that you can update each library individually, rather than having to re-build and update a bundle containing lots of libraries, each time one of them changes.

however, making every library a bundle can sometimes be overkill in that you end up with a mass of bundles to manage. Also sometimes you'd like to embed a library inside a bundle, as an implementation detail (ie. not exported)

luckily these days there are lots of tools that help you create and manage bundles, so refactoring libraries between bundles is not that difficult.

(one of the more popular is the BND tool, see http://aqute.biz/Code/Bnd )

at the minimum, all that is required to turn a library into an OSGi bundle is the addition of metadata to the jar manifest - however, some libraries need additional code to take part in the OSGi lifecycle (ie. for cleanup)

> Do Guice's dependencies need to be bundles as well? Or on the other hand, suppose > that the Guice-OSGI bundle simply included the Guice library and its dependencies? > That seems somewhat simpler.

at the moment the Guice-OSGi bundle includes the Guice library, plus dependencies because then people only need to pull in one bundle (the dependencies are mostly hidden implementation details - except aopalliance, which forms part of the API)

> It seems like both approaches have been taken for Jetty; I found a page for the > org.osgi.service.http.HttpService as provided by Oscar, which seems to use Jetty.

yes, the old oscar implementation of the HttpService embedded a version of Jetty

> On the other hand, Jetty seems to be its own bundle now.

also true, but only for recent versions (they've added OSGi metadata to the jar) this means that the Jetty library can be installed into an OSGi framework as-is, and exports packages - but doesn't provide an implementation of the HttpService

> Also, I haven't figured out yet how you keep a reference to an OSGi service in > a way that allows it to go away. The org.osgi.service.component.ComponentInstance > interface seems very similar to Guice's Provider interface. Is that what people > use?

the low-level way to access services is via a ServiceReference (indirect handle) using listeners to find out when services appear and go away. However, most people will use ServiceTrackers or a more high-level approach such as DS to get services.

a ServiceTracker can tell you when services come and go (via subclassing or giving it a customizer) and has methods that return one or more actual service instances, valid at the time of the call. (of course services can go at any time, so you must be prepared for exceptions!)

Guice-OSGi uses ServiceTrackers to provide service instances via an injected proxy.

DS will do the tracking for you and call methods when services come and go, passing in the service instance (kind of like dynamic DI) - also DS can register and start services on your behalf, when their dependencies are satisfied (or even on-demand)

for a good tutorial on OSGi, take a look at Neil Bartlett's series of articles: http://neilbartlett.name/blog/osgi-articles HTH

[gissuebot]

From colin.mailinglist on July 24, 2007 10:00:35

This looks interesting, I'm going to give it a spin and see how it works.

One comment about the comparison between DS and Guice-OSGi - one of the principal reasons behind DS was the ability to register and manage services without loading all the classes involved, which is why the service descriptions are in metadata. In a large system (e.g. Eclipse) this is a big deal, and this advantage is lost when using annotations, unless you come up with some clever way to scan the class files using ASM or something. However this is probably not a problem for the vast majority of projects.

Cheers, Colin

[gissuebot]

From bslesinsky on July 25, 2007 11:25:38

> at the moment the Guice-OSGi bundle includes the Guice library, plus dependencies > because then people only need to pull in one bundle (the dependencies are mostly > hidden implementation details - except aopalliance, which forms part of the API)

Okay, I think we should stick to this, so there is no reason for Guice itself to know about bundles.

> the low-level way to access services is via a ServiceReference (indirect handle) > using listeners to find out when services appear and go away.

I see that OSGi uses reference-counting using getService() and ungetService().  However, what is this reference count used for, since it doesn't prevent a service from becoming unavailable, or a hard reference from being garbage-collected?

A Guice Provider has get() but no unget().  It's recommended that an instance should call get() each time it needs the object rather than caching references, but there also seems to be an assumption that an object doesn't go out of scope during a method call, which has been true for the scopes we have so far.  We also don't have any listeners yet, or support for a whiteboard model; the proposed addition of multibindings is sort of like a static version of the whiteboard pattern.  See: https://code.google.com/p/google-guice/issues/detail?id=37 > (of course services can go at any time, so you must > be prepared for exceptions!)

How do services usually handle this?

[gissuebot]

From dev2null on July 25, 2007 13:13:30

A class loader hook mechanism may still be useful. It would be great it I could shared code using plain Guice in different environments, e.g use it both in an OSGi container, a webapp and in a "normal" Java application.

Currently plain Guice cannot work in an OSGi container and Guice-OSGi introduces a dependency on OSGi. I'd like to include Guice in a Eclipse RCP application that uses legacy code with lots of Singletons and static dependencies. The legacy code is shared with other non-OSGi applications and therefor should not depend on Guice-OSGi.

The other reason for adding hooks to the standard Guice distribution is of course that Guice-OSGi would no longer need to maintain a separate patch set:)

Finally, packaging Guice with a bundle manifest would allow hiding non-api classes as described in https://code.google.com/p/google-guice/issues/detail?id=121 and https://code.google.com/p/google-guice/issues/detail?id=16

[gissuebot]

From mcculls on July 26, 2007 03:39:47

here's a prototype patch against guice trunk that adds a generic classloader hook mechanism to Guice, using the usual system property / META-INF services technique.

two basic implementations are provided - DefaultClassLoaderFactory which provides classic Java classloading and ContainerClassLoaderFactory which attempts to bridge between non-hierarchical classloaders (as found in OSGi).

it also adds basic OSGi metadata to the manifest (non-generated) but this isn't essential - it's just a nice-to-have for those who'd like to drop the Guice lib straight into an OSGi framework.

if you'd like to use this with OSGi, apply the patch to trunk and rebuild the jar. You should then be able to use this with OSGi, if you set this system property:

   -Dcom.google.inject.ClassLoaderFactory=        com.google.inject.internal.ContainerClassLoaderFactory

if anyone spots any typos / bugs / possible improvements just give me a shout :)

Attachment: gist    _GUICE_ISSUE_94_GENERIC_CLASSLOADING_HOOK.patch_

[gissuebot]

From bslesinsky on July 26, 2007 10:05:38

It seems like there is still a fair amount of OSGi magic going on.  Can you explain how non-hierarchical classloaders work in OSGi?

Why use a system property?  How about:

Guice.createInjector(classLoaderFactory, modules);

Then each injector can be configured to do class loading its own way, and this should make the code much easier to test.

[gissuebot]

From mcculls on July 27, 2007 09:47:00

Actually the only OSGi magic in the last patch was the manifest entries.

The system property and META-INF/services lookup code is a common Java approach for customizing jars at runtime (see commons logging, etc.)

Anyway, I agree about making it easier to test, so have refactored it to use the construction approach you suggested - this required more changes to the core though, as previously it was using static methods to enhance and proxy the types.

The attached patch only adds the hook and a default implementation - it doesn't add any metadata, or alternative implementations. Haven't had a chance to try it out on OSGi yet as I'll need to write a new adapter...

Let me know if I'm on the wrong track :)

PS. http://www.eclipsezone.com/articles/eclipse-vms has a good discussion     about the non-hierarchical classloaders (ie. doesn't always delegate     first to parent) and issues wrt. bundles/plugins which may not know     in advance who is going to use them

Attachment: gist    _GUICE_ISSUE_94_CLASSLOADING_HOOK_REFACTOR.patch_

[gissuebot]

From geoff.hill.au on September 04, 2007 04:31:45

What do I apply this latest patch to? I don't have any GuiceCodeGen.java in my guice sources - fresh from svn trunk.

BTW - this looks cool.

[gissuebot]

From mcculls on September 05, 2007 21:28:45

Hi Geoff,

GuiceCodeGen.java was based on GuiceFastClass.java (refactored and extended) - unfortunately this detail got lost in the patch generated from subversion...

I'm attaching an updated patch which is based on today's trunk, applies cleanly and compiles with all tests passing (note it will leave GuiceFastClass.java as an empty file)

Attachment: gist    _GUICE_ISSUE_94_TRUNK_20070906.patch_

[gissuebot]

From mario.scalas on September 10, 2007 02:20:50

How does the patch relate with http://wiki.ops4j.org/confluence/display/ops4j/Guice-OSGi ? The latter supports OSGi services and is built on top of Guice (I believe 1.1-branch): does it work with the current guice trunk and this patch?

[gissuebot]

From mcculls on September 10, 2007 02:34:33

this patch is an evolution of the work I started with "Guice-OSGi" and incorporates suggestions from various people so Guice can work with all sorts of containers that require custom classloaders, not just OSGi.

I haven't updated Guice-OSGi to use this patch, but it shouldn't take too long - just been busy with other projects (and moving house!)

[gissuebot]

From mcculls on October 02, 2007 09:14:16

FYI, I'm now maintaining the classloader hook patch at: https://peaberry.googlecode.com/svn/trunk/patches/ClassLoaderHook.txt and regularly update it so it applies cleanly to trunk.

[gissuebot]

From mcculls on November 28, 2007 23:34:13

Note: patch has been refactored to: http://peaberry.googlecode.com/svn/trunk/patch/ClassLoaderHook.txt

[gissuebot]

From mcculls on March 31, 2008 00:49:39

some design doc: https://code.google.com/p/peaberry/wiki/Patch_ClassLoaderHook

[gissuebot]

From limpbizkit on June 04, 2008 22:55:47

(No comment was entered for this change.)

Labels: Milestone-Release2.0

[gissuebot]

From limpbizkit on June 25, 2008 08:44:06

I'm working on applying mcculls' latest patch. It should fix the OSGi issue and the memory leak issue. http://peaberry.googlecode.com/svn/trunk/patch/ClassLoaderHook.txt

Owner: limpbizkit

[gissuebot]

From limpbizkit on June 29, 2008 16:06:16

Stuart's done a great job on this and what we've got is fantastic. Guice now will play-nice in an OSGi container like Eclipse. Even more, our internal/ package is no longer visible. Very nice.

Stuart's patch is applied but I've temporarily turned it off. To activate it, use -Dguice.custom.loader=true. I'm anxious about a few things with this patch:  - injection into package-private methods  - test coverage of class unloading

Status: Started

[gissuebot]

From limpbizkit on July 03, 2008 14:27:18

Fixed. Stuart's latest changes address the package-private problem.

Status: Fixed

[gissuebot]

From annemartens1 on February 16, 2009 07:33:27

Dear OSGi-Guice team,

I'm confused what the current requirements to use Guice with OSGi are. On the peaberry page, it is said that the Guice trunk now includes the changes to support OSGi. Does this mean I can make Guice work with OSGi without downloading peaberry, if I do not want to use peaberry's extra features?

I want to use a third-party framework that uses Guice in my application. The framework itself is also not a plugin yet, thus I'm trying to make it one (I added plugin.xml, dependencies, exports, ...). Currently, a guice-snapshot20090205.jar is included in the framework's plugin and some packages of it are exported in the plugin.xml. The rest of my application does not use Guice.

I still experience class loading problems (com.google.inject.internal.cglib.reflect.FastClass), so probably this has not been enough? I have set -Dguice.custom.loader=true, but no other arguments (are there any?)

Thanks a lot in advance for you help!

Kind regards, Anne

[gissuebot]

From mcculls on February 22, 2009 07:39:17

Hi Anne, I've just written up a wiki page about Guice and OSGi: https://code.google.com/p/google-guice/wiki/OSGi Guice trunk produces an OSGi bundle: you can drop it directly into an OSGi container without needing peaberry (this just adds support for dynamic services). One caveat: AOP with package-private methods is not viable in OSGi because we cannot bridge the classloaders (see the wiki page for full details).

If you're still having trouble feel free to post a message on the Guice-OSGi group ( http://groups.google.com/group/guice-osgi ) with some more details about your setup.

[gissuebot]

From a.shewring on May 22, 2009 05:26:45

I'm having the same issue as Anne is, namely

java.lang.NoClassDefFoundError: com/google/inject/internal/cglib/reflect/FastClass

I am using the Guice 2.0 release jar. Modifying the manifest by adding com.google.inject.internal.cglib.reflect to the list of Export-Package directives does not solve it (an ugly, drastic solution in any case).

Incidentally I also needed to add

com.google.inject.internal;version="1.2"

to the guice-2.0.jar's manifest in order for the org.google.assistedinject bundle to be resolved. That bundle's manifest also required modification as it was importing its own package (com.google.inject.assistedinject;version="[1.2,2)")!

Lastly, the shipped aopalliance.jar is not an OSGi bundle. For Guice 1.0 I used the attached com.springsource.org.aopalliance-1.0.0.jar from the SpringSource Enterprise Repository instead.

Please reopen this issue as there are clearly outstanding problems when running Guice and the AssistedInject extension under OSGi. I cannot upgrade as a result.

Binary attachments: com.springsource.org.aopalliance-1.0.0.jar

[gissuebot]

From mcculls on May 22, 2009 06:05:24

Be aware there are a couple of OSGi patches that are not in Guice 2.0: https://code.google.com/p/google-guice/issues/detail?id=311 https://code.google.com/p/google-guice/issues/detail?id=337 https://code.google.com/p/google-guice/issues/detail?id=343 These are all scheduled for release 2.1

Only issue 343 relates to the core Guice jar (the others are related to extensions, such as AssistedInject ) and 343 is the issue relating to Anne's example, so there's no need to re-open this particular issue as there are existing issues already open. Issue 343 only applies if you are attempting to proxy a system class like Anne was (in Anne's case it was java.util.Random) - however you will see the same exception stack about not finding FastClass whenever Guice is not able to bridge between the client type and the CGLIB code.

In particular, if you try to proxy a package-private type then it is impossible for Guice to bridge the client and CGLIB code together due to security restrictions in Java's classloading mechanism as explained in the wiki: https://code.google.com/p/google-guice/wiki/OSGi So please check the failing binding and make sure the types are protected or public.

If you want a copy of Guice 2.0 with the patch for issue 343 applied then you can get this from the peaberry project at https://code.google.com/p/peaberry/ (look at the Maven dependencies in the wiki, or check out the trunk and look in lib/build). But remember this is only necessary if you need to proxy system types and I have several OSGi projects that successfully use Guice 2.0 without needing this patch.

To use extensions like AssistedInject in OSGi you will either have to wait for the 2.1 release (which won't be as long a wait as 2.0) or you can download the Guice 2.0 source, apply the patches from the issues listed above, and rebuild the distribution.

As for the AOP Alliance jar, the version distributed with Guice does not have OSGi metadata because it's the original binary - whether Guice should ship a modified version has never really come up before as you can easily get an OSGi version of this jar from other distributions like peaberry or the Spring bundle repository.

But if you want OSGi metadata added to Guice's AOP Alliance jar feel free to open a new issue to cover this - the one question is where this modified jar should then be put on the Maven repository, as it is clearly not the official jar once modified and should therefore probably go under a different groupId (this is why it's much better for the original distributor to add OSGi metadata rather than get all downstream distributors to add it and use different bundle symbolic names, like Spring does).

In summary: check the bindings for private types, try out the Guice binary from the peaberry project to make sure you're not running into Issue 343 - if all else fails send a note to the Guice-OSGi mailing list at guice-osgi@googlegroups.com along with more details about your code and perhaps even a testcase.

[gissuebot]

From mcculls on May 22, 2009 06:12:12

Also a quick comment about:

> That bundle's manifest also required modification as it was importing > its own package (com.google.inject.assistedinject;version="[1.2,2)")

This is recommended best-practice in OSGi, bundles should import their own exports to help improve substitutability, see: http://www.osgi.org/blog/2007/04/importance-of-exporting-nd-importing.html So importing your own exports is not the issue here - once you apply the patches in issues 311 and 337 to add the necessary bridging and fragment directives then you can use AssistedInject in OSGi, and it will still be importing its own exports.

[gissuebot]

From a.shewring on May 22, 2009 14:47:01

@mcculls

Thank you very much for your detailed explanations and for pointing out the OSGi best practice for substitutability. Am pleased to say that the attached bundles work correctly after patching the source and running the Ant dist target. I'm attaching them here for the convenience of others in the same situation who like to live on the bleeding edge.

Binary attachments: guice-2.0.jar, guice-assistedinject-2.0.jar