google-code-export / google-guice

Automatically exported from code.google.com/p/google-guice
Apache License 2.0
2 stars 1 forks source link

Some guice extensions do not resolve under OSGi. #311

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
AssistedInject
Miltibindings
ThrowingProviders

All of these use com.google.inject.internal and therefore their bundles
import it. The Guice bundle however (rightfully) does not export this
package. The result is that the bundles containing each of the above
extensions can never be resolved. I have solved this for myself by
repackaging guice togather with the three extensions under one bundle (so
internal remains hidden). But this is ugly. 
The internal stuff used by these extensions does not seem so vitally
private - more like stand alone utilities. The cleanest solution would be
to make it public in some (more limited?) form:

com.google.inject.internal.Errors
com.google.inject.internal.ErrorsException
com.google.inject.internal.Annotations.getKey
com.google.inject.internal.UniqueAnnotations

Original issue reported on code.google.com by Rinsvind@gmail.com on 15 Jan 2009 at 5:15

GoogleCodeExporter commented 9 years ago
Ideally Annotations and UniqueAnnotations could be moved to the util package, 
while I
guess Errors and ErrorsException could either be moved to a new errors package, 
the
top-level package, or the util package too.

Once these classes are in non-internal packages the extensions should resolve 
OK.

Original comment by mccu...@gmail.com on 20 Jan 2009 at 5:04

GoogleCodeExporter commented 9 years ago
@mcculls is it possible to expose the classes in internal to extensions? I'd 
prefer we not release these APIs 
externally yet. Does OSGi have a 'friend' concept?

Also, is there a tool that can validate my OSGi bundles to test for problems 
like this one?

Original comment by limpbizkit on 26 Jan 2009 at 1:28

GoogleCodeExporter commented 9 years ago
If you want to keep these classes internal but expose them to extensions, then 
the
best solution is to mark the extensions as fragments that attach to the main 
Guice
bundle. Fragment bundles use the same classloader as their host and will 
therefore
see internal packages.

(there are other "friend" style mechanisms in Equinox, but these are 
non-standard)

I've attached a patch that adds the necessary fragment headers and cleans up 
some
import statements as well. FYI: you may see a few Bnd warnings about 
non-matching
referrals, but these can be safely ignored.

Regarding a tool to validate OSGi bundles, you can use Bnd to verify the 
content:

  java -jar lib/build/bnd-0.0.305.jar print -verify build/dist/*-snapshot.jar

which will report the missing internal import for the extensions and other extra
bundles. Note these problems will still be reported even when the extensions are
marked fragments, but it won't now cause a problem in practice.

Also the main Guice bundle will always report a couple of missing imports:

  com.google.common.base
  com.google.inject.internal.asm.util

both due to some indirect/string references that are never used at runtime.

For a better test of the actual bundles you could use one of the OSGi 
frameworks and
check the bundles all install and resolve. OSGi integration testing is 
unfortunately
still ad-hoc these days (tooling is being developed as I type ;)

I don't have much time this month (or next!) but I could provide some tests 
later on
this year if you're interested. Until then feel free to look at the following 
links:

  http://wiki.ops4j.org/display/ops4j/Pax+Runner

  http://felix.apache.org/site/apache-felix-file-install.html

You can use Pax-Runner to download and setup an OSGi framework (say the 
reference
implementation, Equinox) and deploy the FileInstall bundle. This monitors a 
folder
and installs any JARs you add, and uninstalls any that are removed.

(shameless plug: the OSGi in Action book might also help 
http://manning.com/hall/)

Original comment by mccu...@gmail.com on 27 Jan 2009 at 6:28

Attachments:

GoogleCodeExporter commented 9 years ago
I'd like to get this patch into Guice 2.1 if possible.

Original comment by mccu...@gmail.com on 30 Mar 2009 at 10:59

GoogleCodeExporter commented 9 years ago

Original comment by limpbizkit on 26 Apr 2009 at 9:36

GoogleCodeExporter commented 9 years ago
This patch didn't make it into 2.0, so rescheduling it for 2.1

Original comment by mccu...@gmail.com on 21 May 2009 at 9:02

GoogleCodeExporter commented 9 years ago
Will make sure this patch is up-to-date as part of my general OSGi cleanup for 
2.1

Original comment by mccu...@gmail.com on 31 Oct 2009 at 4:02

GoogleCodeExporter commented 9 years ago
Folded this into http://code.google.com/p/google-guice/issues/detail?id=439

Original comment by mccu...@gmail.com on 4 May 2010 at 10:17