Marcel

...just wondering, are you actually using GWT in an OSGi context (to build a UI out of components)? I have a customer that wants to look into that so I was wondering if you have any experiences you might want to share here.
Yes we are - using Felix, and the normal Felix Http bundle. We're still on the old jetty4 based one from a couple of revs back. It works very well too.

Pretty standard model:

   * we create a single "ui" bundle - which contains:
         o the gwt-user.jar as an embedded jar
         o the gwext.jar (we were using mygwt and gxt, but there's been
           a license brew-ha-ha which has steered us away from this).
         o the java compiled outputs
         o the compiled output of the GWT compiler i.e. the "www" root
         o our GwtServlet which serves up the JS, HTML etc. resources
         o our Rpc server classes - which are lightweight layers that
           wire themselves into our core service classes elsewhere  in
           the OSGi instance
   * we still use my old mangen approach for manifests (have attached
     an example below)
   * we use service binder for our service wiring (also attached our

I think when we first started we had the usual "trace and analyse" what HTTP resource requests we were getting, and how to resolve them in our GwtServlet class. But it didn't prove too hard:

   We mount our app at:

       http:://localhost:8084/VtWebUi

   Our "app entry point"

       protected String baseUri = "/com.ascert.webui.vt.VtWebUi";

   This matches what's in your GWT XML and HTML

           <entry-point class="com.ascert.webui.vt.client.VtWebUi" />

       <script type="text/javascript"
       src="com.ascert.webui.vt.VtWebUi.nocache.js"></script>


   In our servlet, we use the following properties:

       public GwtServlet(ServiceBinderContext context)
           {
               this.context = context;
alias = getProperty("webui.uri", "/VtWebUi");
               resourceFsBase =
       context.getBundleContext().getProperty("webui.fs.resource.base");
           ...

   I'll cover what resourceFsBase does in a moment

   We mount the following aliases for RPC services and too resolve
   resources

           public void activate()
           {
               try
               {
                   srvHttp.registerServlet(alias +
       "/EnvironmentService", this.envSvc, new Hashtable(),
myContext); srvHttp.registerServlet(alias + "/ClientService", this.cliSvc, new Hashtable(), myContext); srvHttp.registerResources(alias, "", myContext);
           ...

   And then to resolve resources in our myContext instance

           private class WebUiContext implements HttpContext
           {
               public URL getResource(String name)
               {
                   if (name.equals("/"))
                   {
                       name = "/VtWebUi.html";
                   }
diag.debug("getResource: " + name); URL retVal = null;
                   try
                   {
                       //allowing FS overriding useful for testing.
                       if (resourceFsBase != null && new
       File(resourceFsBase + name).exists())
                       {
                           retVal = new URL("file:" + resourceFsBase +
       name);
                       }
if (retVal == null)
                       {
                           retVal =
       GwtServlet.class.getClassLoader().getResource("resources/www" +
       baseUri + name);
                       }

       In a normal running case resources are server from the
       GwtServlet class loader by the last case. But resourceFsBase
       let's us do a pre-emptive check and serve direct from the
       filesystem. This is very handy for tweaking CSS layouts, since
       it lets you change CSS resources and try how the look without a
       recompile.

Think that's the essence of the wiring - the rest is pretty much vanilla OSGi and GWT

Here's those other attachments

_bundle manifest:
_

   Manifest-Version: 1.0
   Ant-Version: Apache Ant 1.6.5
   Bundle-ClassPath: .,gwt-user.jar,gwtext.jar
   Metadata-Location: metadata.xml
   Bundle-Name: VtWebUI
   Bundle-ManifestVersion: 2
   Created-By: 1.6.0_03-b05 (Sun Microsystems Inc.)
   Bundle-Activator: com.ascert.webui.vt.ServiceActivator
   Bundle-Description: WebUI for VersaTest
   Import-Package: com.ascert.tas.api, com.ascert.vt.testcase, javax.imag
    eio, javax.servlet, javax.servlet.http, javax.xml.parsers, org.apache
    .felix.servicebinder, org.apache.log4j, org.osgi.framework, org.osgi.
    service.http, org.w3c.dom
   Bundle-SymbolicName: com.ascert.webui.vt

   Name: com/ascert/openosgi/mangen
   Import-Package: org.osgi.service.http
   mangen-rule-0: Ignore imports(org.springframework.*,junit.*,com.google
    .gwt.core.ext.*,com.google.gwt.dev.*,com.google.gwt.util.tools,org.ap
    ache.tapestry.util.text,org.eclipse.jdt.*)
   mangen-rule-1: Ignore exports(javax.servlet,javax.servlet.http)

_sb metadata:_

   <?xml version="1.0" encoding="UTF-8"?>
   <bundle>
       <instance class="com.ascert.webui.vt.GwtServlet">
           <requires
             service="org.osgi.service.http.HttpService"
             filter=""
             cardinality="1..1"
             policy="dynamic"
             bind-method="bindHttp"
             unbind-method="unbindHttp"
           />
           <requires
             service="com.ascert.tas.api.TestRunnerService"
             filter=""
             cardinality="1..1"
             policy="dynamic"
             bind-method="bindTestRunner"
             unbind-method="unbindTestRunner"
           />
        </instance>
   </bundle>

Good luck

-- Rob


Ascert - Taking systems to the Edge
[EMAIL PROTECTED]
+44 (0)20 7488 3470
www.ascert.com

Reply via email to