Support OSGi classloading in Guice

[GoogleCodeExporter]

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.

Original issue reported on code.google.com by mccu...@gmail.com on 20 Apr 2007 at 9:33

Attachments:

• GUICE_OSGI.patch

[GoogleCodeExporter]

Original comment by kevin...@gmail.com on 20 Apr 2007 at 2:48

• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

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.

Original comment by mccu...@gmail.com on 25 Apr 2007 at 4:44

Attachments:

• GUICE_OSGI_TRUNK.patch
• bnd-0.0.130.jar

[GoogleCodeExporter]

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

Original comment by mccu...@gmail.com on 16 May 2007 at 5:45

Attachments:

• GUICE_OSGI_TRUNK_20070516.patch
• bnd-0.0.134.jar

[GoogleCodeExporter]

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

Original comment by dev2n...@gmail.com on 16 May 2007 at 4:14

[GoogleCodeExporter]

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

Original comment by mccu...@gmail.com on 23 Jun 2007 at 8:21

[GoogleCodeExporter]

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?

Original comment by dev2n...@gmail.com on 4 Jul 2007 at 8:02

[GoogleCodeExporter]

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

Original comment by mario.scalas@gmail.com on 20 Jul 2007 at 12:21

[GoogleCodeExporter]

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.

Original comment by alex.h...@gmail.com on 20 Jul 2007 at 1:17

[GoogleCodeExporter]

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?

Original comment by bslesinsky on 21 Jul 2007 at 6:26

[GoogleCodeExporter]

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.

Original comment by alex.h...@gmail.com on 21 Jul 2007 at 7:49

[GoogleCodeExporter]

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.

Original comment by bslesinsky on 21 Jul 2007 at 10:22

[GoogleCodeExporter]

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

Original comment by mccu...@gmail.com on 22 Jul 2007 at 1:37

[GoogleCodeExporter]

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

Original comment by alex.h...@gmail.com on 22 Jul 2007 at 10:29

[GoogleCodeExporter]

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

Original comment by bslesinsky on 23 Jul 2007 at 5:49

[GoogleCodeExporter]

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

Original comment by dev2n...@gmail.com on 23 Jul 2007 at 7:51

[GoogleCodeExporter]

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.

Original comment by mccu...@gmail.com on 23 Jul 2007 at 8:35

[GoogleCodeExporter]

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!

Original comment by mccu...@gmail.com on 23 Jul 2007 at 8:58

[GoogleCodeExporter]

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

Original comment by mccu...@gmail.com on 23 Jul 2007 at 9:08

[GoogleCodeExporter]

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?

Original comment by bslesinsky on 23 Jul 2007 at 4:58

[GoogleCodeExporter]

> 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

Original comment by mccu...@gmail.com on 24 Jul 2007 at 9:19

[GoogleCodeExporter]

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

Original comment by colin.ma...@gmail.com on 24 Jul 2007 at 5:00

[GoogleCodeExporter]

> 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: http://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?

Original comment by bslesinsky on 25 Jul 2007 at 6:25

[GoogleCodeExporter]

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 
http://code.google.com/p/google-guice/issues/detail?id=121 and
http://code.google.com/p/google-guice/issues/detail?id=16

Original comment by dev2n...@gmail.com on 25 Jul 2007 at 8:13

[GoogleCodeExporter]

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

Original comment by mccu...@gmail.com on 26 Jul 2007 at 10:39

Attachments:

• GUICE_ISSUE_94_GENERIC_CLASSLOADING_HOOK.patch

[GoogleCodeExporter]

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.

Original comment by bslesinsky on 26 Jul 2007 at 5:05

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

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

Original comment by mccu...@gmail.com on 27 Jul 2007 at 4:47

Attachments:

• GUICE_ISSUE_94_CLASSLOADING_HOOK_REFACTOR.patch

[GoogleCodeExporter]

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.

Original comment by geoff.hi...@gmail.com on 4 Sep 2007 at 11:31

[GoogleCodeExporter]

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)

Original comment by mccu...@gmail.com on 6 Sep 2007 at 4:28

Attachments:

• GUICE_ISSUE_94_TRUNK_20070906.patch

[GoogleCodeExporter]

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?

Original comment by mario.scalas@gmail.com on 10 Sep 2007 at 9:20

[GoogleCodeExporter]

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

Original comment by mccu...@gmail.com on 10 Sep 2007 at 9:34

[GoogleCodeExporter]

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.

Original comment by mccu...@gmail.com on 2 Oct 2007 at 4:14

[GoogleCodeExporter]

Note: patch has been refactored to:

   http://peaberry.googlecode.com/svn/trunk/patch/ClassLoaderHook.txt

Original comment by mccu...@gmail.com on 29 Nov 2007 at 7:34

[GoogleCodeExporter]

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

Original comment by mccu...@gmail.com on 31 Mar 2008 at 7:49

[GoogleCodeExporter]

Original comment by limpbizkit on 5 Jun 2008 at 5:55

• Added labels: Milestone-Release2.0

[GoogleCodeExporter]

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

Original comment by limpbizkit on 25 Jun 2008 at 3:44

[GoogleCodeExporter]

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

Original comment by limpbizkit on 29 Jun 2008 at 11:06

• Changed state: Started

[GoogleCodeExporter]

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

Original comment by limpbizkit on 3 Jul 2008 at 9:27

• Changed state: Fixed

[GoogleCodeExporter]

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

Original comment by annemart...@gmail.com on 16 Feb 2009 at 3:33

[GoogleCodeExporter]

Hi Anne, I've just written up a wiki page about Guice and OSGi:

  http://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.

Original comment by mccu...@gmail.com on 22 Feb 2009 at 3:39

[GoogleCodeExporter]

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.

Original comment by a.shewr...@gmail.com on 22 May 2009 at 12:26

Attachments:

• com.springsource.org.aopalliance-1.0.0.jar

[GoogleCodeExporter]

Be aware there are a couple of OSGi patches that are not in Guice 2.0:

   http://code.google.com/p/google-guice/issues/detail?id=311
   http://code.google.com/p/google-guice/issues/detail?id=337
   http://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:

   http://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 http://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.

Original comment by mccu...@gmail.com on 22 May 2009 at 1:05

[GoogleCodeExporter]

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.

Original comment by mccu...@gmail.com on 22 May 2009 at 1:12

[GoogleCodeExporter]

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

Original comment by a.shewr...@gmail.com on 22 May 2009 at 9:47

Attachments:

• guice-2.0.jar
• guice-assistedinject-2.0.jar