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

(No comment was entered for this change.)

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

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

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

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).

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.

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?

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

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

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.

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?

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.

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.

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...

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).

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?)

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?

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.

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!

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

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?

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

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

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?

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

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

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.

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

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.

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

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?

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!)

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.

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

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

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

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

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

(No comment was entered for this change.)

Labels: Milestone-Release2.0

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

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

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

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

Status: Fixed

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

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.

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

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.

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.

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