GWT-Servlet should have OSGi headers in manifest

[dankurka]

Originally reported on Google Code with ID 8424

The GWT-Servlet artifact, gwt-servlet.jar, should have OSGi headers in META-INF/MANIFEST.MF
so that it is possible to use GWT easily in an OSGi environment and deploy GWT web
applications on OSGi containers like Apache Karaf.

Found in GWT Release (e.g. 2.4.0, 2.5.1, trunk):
2.6.0-rc1

Encountered on OS / Browser (e.g. WinXP, IE9, FF10):
not applicable

Detailed description (please be as specific as possible):
OGSi containers provide lightweight environments for implementing modular java applications
but require special headers on the .jar to be deployed into.  

Containers like Apache Karaf provide the capability to deploy also web applications
in a .war, 
however to achieve modularity, the jar libs should be moved out from WEB-INF/lib and
be deployed as OSGi "bundles". A jar require special headers in the manifest to be
deployed as a bundle and GWT-Servlet, that is the jar intended to be deployed on the
server side for a Web Application should have these OSGi headers too.

Many common java libraries are already OSGi as headers are transparent to non OSGi
developers. To quote some OSGi lib, in GWT Tools you can find OSGi headers in Commons
Codec, Commons Collections, Commons IO, Commons Lang, Commons Lang, Commons Logging,
Apache JAMES Mime4j, Apache Log4j, ICU4J, EasyMock, Eclipse JTD, Hibernate Validator,
ICU4J, Jetty, Glassfish javax.servlet, Objenesis, Protocol Buffer Java API, slf4j-api,
slf4j-log4j12.

Most notably, Google Guava 15 for GWT is not OSGi compliant but only because Guava
has been rebased for GWT and manifest is stripped out during this rebase. Guava is
OSGi since Guava 12 (see https://code.google.com/p/guava-osgi/)

Combining GWT and OSGi would provide an ideal platform for developing SOFEA applications
(http://stackoverflow.com/questions/817617/what-is-sofea).

More other info are available on the links to relevant forum discussions.

Shortest code snippet which demonstrates issue (please indicate where
actual result differs from expected result):
not applicable

Workaround if you have one:
It is possibile to use GWT-Servlet in Apache Karaf with the "wrap" deployer. For example,
install on Karaf Shell with command:
install -s wrap:mvn:com.google.gwt/gwt-servlet/${gwt.version}$Bundle-SymbolicName=gwt-servlet
but this approach has other limitations.

Links to relevant GWT Developer Forum posts:
http://servicemix.396122.n5.nabble.com/OSGIfy-server-jar-of-GWT-td5718247.html
https://groups.google.com/forum/#!topic/google-web-toolkit-contributors/Dae3za7u3A0

Link to patch posted at http://gwt-review.googlesource.com

Reported by cristiano.costantini on 2013-11-07 12:05:56

[dankurka]

I'm working on a patch and also some code Example of GWT Web Application for Apache
Karaf that maybe can be ready for the final release of of GWT 2.6.0.

Reported by cristiano.costantini on 2013-11-07 12:07:59

[dankurka]

Published a patch at https://gwt-review.googlesource.com/5351

If something is wrong, please don't blame me! I've tried to follow all rules but it
is the first time I use gerrit and something may be wrong.

Reported by cristiano.costantini on 2013-11-08 07:45:03

[dankurka]

To echo my comments on the Gerrit review, for wider circulation:

I think that the set of exported packages should be really conservative, otherwise
it's very easy for consumers to tie themselves to APIs which we don't want to support.

Perhaps we should start with the question of what we want to achieve? Is there something
else other than making RPC and RF work in an OSGi environment?

Reported by robert.munteanu on 2013-11-08 09:45:33

[dankurka]

Hi All,

FYI, gwt-servlet with osgi is being currently published to maven by ServiceMix project
(it has just been announced, give some time to sync the repos).

The maven coordinates will be:
<dependency>
    <groupId>org.apache.servicemix.bundles</groupId>
    <artifactId>org.apache.servicemix.bundles.gwt-servlet</artifactId>
    <version>2.6.0_1</version>
</dependency>

Note: you don't need to depend on this artifact in a maven application, this is required
for deployment on OSGi containers only.

...btw I still care this issue will be addressed and that next GWT release will embed
OSGi headers on his own.

Regards,
Cristiano

Reported by cristiano.costantini on 2014-02-18 07:26:23

[dankurka]

In reply to cristian on:
...
<dependency>
    <groupId>org.apache.servicemix.bundles</groupId>
    <artifactId>org.apache.servicemix.bundles.gwt-servlet</artifactId>
    <version>2.6.0_1</version>
</dependency>
...

I just try your bundle, and found that it misses to export:
 com.google.gwt.core.client;version="2.6.0",
 com.google.gwt.event.dom.client;version="2.6.0",
 com.google.gwt.i18n.client;version="2.6.0",
 com.google.gwt.user.client;version="2.6.0",
 com.google.gwt.user.client.ui;version="2.6.0"

May be some other misses? 

Reported by lis0x90 on 2014-03-15 19:55:46

[dankurka]

Hi, 
all those packages are "client" side packages, that are compiled to javascript, so
they are not needed on the server. 

GWT use the convention to use packages containing *.client.*, *.server.* and *.shared.*
for recognizing which type of code you are dealing with, and  the idea is to be conservative
on the exported packages, so client-only code should not be exported by OSGi (only
server and shared code should).

However GWT is not consistent and I've found severe exception to that rule, notably
the package com.google.gwt.user.client.rpc which is used on server side for serialization
and I had to export that (that package should be refactored to "com.google.gwt.user.shared.rpc"
!!!)

In the end, consider that the BND tool and maven bundle plugin will still find references
to these packages while parsing your classes, so they add imports that require the
packages you have listed.

You should configure the plugin to ignore them, for example, in maven bundle plugin

<Import-Package>
!com.google.gwt.core.client,
!com.google.gwt.event.dom.client,
!com.google.gwt.i18n.client,
!com.google.gwt.user.client,
!com.google.gwt.user.client.ui,
*
</Import-Package>

but I use the following code, which also address the problem that GWT RPC serialization
make heavily use of Class.forName(...) to find serializers, and so they will not be
found by your application:

<Import-Package>
com.google.gwt.user.client.rpc.*,
com.google.gwt.user.client.rpc.core.com.google.gwt.core.shared,
com.google.gwt.user.client.rpc.core.java.lang,
com.google.gwt.user.client.rpc.core.java.math,
com.google.gwt.user.client.rpc.core.java.sql,
com.google.gwt.user.client.rpc.core.java.util,
com.google.gwt.user.client.rpc.core.java.util.logging,
com.google.gwt.user.server.rpc.core.java.lang,
com.google.gwt.user.server.rpc.core.java.util,
!com.google.gwt.*.client.*,
*
</Import-Package>

Try to play a little bit with the above indications and let me no if you still have
problems.

P.S. this is a symptom that GWT source code need to some hard refactoring that will
break retro-compatibility.

Reported by cristiano.costantini on 2014-03-15 21:10:12

[dankurka]

You absolutely right. It's my mistake. Sorry.

I add proposed by you Import-Package settings to plugin configuration and all deployed
and works as expected.

Thank you

Reported by lis0x90 on 2014-03-18 14:20:10

[dankurka]

no problem thanks to you for the feedback!

Reported by cristiano.costantini on 2014-03-18 14:40:19