Guice Servlet Jar doesn't deploy in OSGi container(s)

[GoogleCodeExporter]

The MANIFEST has 

Export-Package: ..., com.google.inject.internal, ...

And then:

Import-Package: ..., com.google.inject.internal;version="[1.2,2)", ...

As the package is .internal, and looking at its contents - this shouldn't be 
exported/imported at all.  Otherwise the package should be exported with a 
version >= 1.2 and < 2.

Simplest fix: manually edit the MANIFEST, removing all references to 
com.google.inject.internal

(btw: Guice rocks, thankyou)

Original issue reported on code.google.com by ear...@gmail.com on 14 Jun 2010 at 8:00

[GoogleCodeExporter]

Correction: The guice-servlet Jar actually requires access to internal packages 
from the main Guice Jar..

The internal dependencies of the main Guice Jar need to be exported or 
duplicated inside the extension guice-servlet's Jar.

Original comment by ear...@gmail.com on 14 Jun 2010 at 11:00

[GoogleCodeExporter]

This should be fixed in trunk by issue 439:

  http://code.google.com/p/google-guice/issues/detail?id=439

The servlet jar is now a fragment of the core guice jar, so it can see its 
internals.

If you have time, please try the trunk build and report back if that works for 
you.

Original comment by mccu...@gmail.com on 17 Jun 2010 at 4:02

[GoogleCodeExporter]

I had a similar problem that I 'fixed' by changing the manifest target allowing 
the internal package to be exported.  Feels filthy, but unless the servlet jar 
can work without the internal jars that is the only way to deploy in OSGi.

Original comment by ts.ma...@gmail.com on 17 Jun 2010 at 4:02

Attachments:

• common.xml

[GoogleCodeExporter]

^ts.marsh that's not the only way... you can use fragments to solve this in 
OSGi (see latest trunk)

Original comment by mccu...@gmail.com on 17 Jun 2010 at 4:04

[GoogleCodeExporter]

guice-servlet fragment works perfectly (tested on felix 2.0.2).

For the javax.inject Jar just needed to add a MANIFEST.MF with minimal OSGi 
info:
Manifest-Version: 1.0
Export-Package: javax.inject
Bundle-Name: javax.inject
Bundle-SymbolicName: javax.inject

But guessing because javax.inject is part of the Guice build and not part of 
the distribution and users should therefore acquire this Jar elsewhere.

Thanks Stuart =)

Original comment by ear...@gmail.com on 18 Jun 2010 at 10:07

[GoogleCodeExporter]

Using fragments to resolve this issue, however, has one ungly side effect. The 
com.google.inject.servlet package doesn't resolve anymore in eclipse. While 
this might be IDE specific (indeed the bundle works when deployed in an OSGi 
container), I think using fragments here is not the right solution. Correct me 
if I'm wrong, but Fragments are a means to extend the class path of a host 
bundle. The guice-servlet bundle, however, is not an extension of the guice 
bundle, but it is a bundle offering complementary functionality and uses(!) the 
guice bundle. Therefore I agree with ts.march that defining a rasonable API 
seems to be the only reasonable approach to resolve this issue. Using 
Fragments, to me, seems like a dirty fix. What is the reason for declaring some 
of the packages as bundle private when they are obviously required outside?

BTW, the issue in eclipse can easily be resoved by adding the guice-servlet jar 
explicitly to the class path of your own bundle. Then eclipse resolves the 
package.

Original comment by kodeman...@googlemail.com on 15 Oct 2010 at 11:22

[GoogleCodeExporter]

Until the servlet code is refactored to not depend on internal guice packages, 
fragments are the best solution.
Wrt. the issue on Eclipse - as the jars deploy fine on an OSGi container then 
that sounds like a bug in Eclipse.

PS. at the moment the servlet code is a tightly-coupled extension to Guice, so 
using fragments is OK here.

Original comment by mccu...@gmail.com on 15 Oct 2010 at 4:14

[GoogleCodeExporter]

I know this issue is somewhat old but I also struggled with the fragment 
bundles in the latest snapshot. However, I found a magic manifest entry at 
http://dev.eclipse.org/mhonarc/lists/equinox-dev/msg02501.html

Eclipse-ExtensibleAPI: true

Adding this to the Guice core bundle removes the compilation error in Eclipse 
and deploys as expected.

Original comment by arthur.carlsson@gmail.com on 23 Nov 2010 at 6:49

[GoogleCodeExporter]

Did some digging and although the OSGi spec allows fragments to add to the 
exported API (and Eclipse/Equinox does in fact support this at runtime) it 
looks like Eclipse/PDE needs "Eclipse-ExtensibleAPI: true" to allow this at 
compile-time. This sounds more like a bug in PDE (inconsistency between 
compile-time and runtime) so I'd like to hear more about how to recreate the 
compilation error so I can check and feedback to the PDE people.

Original comment by mccu...@gmail.com on 23 Nov 2010 at 8:39

[GoogleCodeExporter]

Original comment by sberlin on 22 Feb 2011 at 1:43

• Added labels: Extension-Servlet

[GoogleCodeExporter]

Fixed in 
http://code.google.com/p/google-guice/source/detail?r=abfe40d6bf6e3b1a3703869c85
dae9a0315cb782 by adding Eclipse-ExtensibleAPI:true to the manifest of the core 
guice.jar (in both Maven and Ant builds). I'd previously added this header to 
sisu-guice (https://github.com/sonatype/sisu-guice) for the m2e folks, but I 
had forgotten to push the change back upstream.

Original comment by mccu...@gmail.com on 23 Dec 2011 at 10:09

• Changed state: Fixed
• Removed labels: Extension-Servlet

[GoogleCodeExporter]

Does tycho need Eclipse-ExtensibleAPI: too to recognize the fragments?  I'm 
having tycho resolution problems that seem to fit this bill.  I would prefer 
not to roll a Guice 3.0.1 just to get this in, but I might need to if it's the 
ticket. 

Original comment by cgruber@google.com on 4 Jun 2012 at 9:40

[GoogleCodeExporter]

In what version was this released ?
I'm having issues getting guice-servlet-3.0.jar deployed and used in a wab 
bundle.
If I use com.google.inject.*;version="3.0" then I always get an error that he 
could not find the com.google.inject.servlet imported.

Original comment by david.nouls on 6 Mar 2014 at 12:47

[GoogleCodeExporter]

You should import Guice packages with version="[1,2)" as the exported API 
version is 1.3 (and the next release will use 1.4). This follows semantic 
versioning rules because the 3.0 API is still compatible with earlier releases 
from a client perspective.

Original comment by mccu...@gmail.com on 6 Mar 2014 at 12:53