I have the Vaadin whiteboard example working nicely in simple OSGi HttpService using various useful parts I have found to make it glue together nicely.
Now I am trying to integrate Refresher. It compiles OK and then when I run it of course it reports as expected that VRefresher is not in the widgetset.
The simple way of pushing the Build WidgetSet button did not work for me as I need to use Bnd to build jars.
So I took the Vaadin build.xml and carved out the bits I need and now I have a short Ant file to build a widgetset that includes Refresher. It seems to have built OK and now I wondering where to put it. I presume it just has to have the path VAADIN/widgetsets. I shall probably put it in an OSGi fragment that I have for my themes or add a second one with just the widgetset.
For the server side I just wrapped Refresher-1.0.0.jar into an OSGi bundle.
My question is to understand how Vaadin knows which widgetset to use? Looking at documentation on how to do it when using a web container, it seems that there is an directory called widgetsets and one would normally put the custom widgetset there. The distribution jar just has com.vaadin.terminal.gwt.DefaultWidgetSet there. Does Vaadin search through widgetsets to try to find one that fits?
The other thing I had thought of doing is putting a property in ServletConfig properties naming the widgetset to use. I thought I might have seen support for that.
I have completely built Vaadin 6.3.4. The easy way would be to add Refresher to the build, but I really want to use vaadin-6.3.4.jar as is and then add OSGi jars as needed to support the additional functionality. Later, when I understand the whole process better, perhaps I can make a single OSGi Refresher bundle with server.class files and its widgetset all in one bundle.
Summarising my questions:
How does Vaadin know which widgetset to use if there is more than one?
Which ServletConfig property would point Vaadin directly to the correct widgetset?
Is it just widgetset=org.vaadin.henrik.refresher.gwt.client.ui.Refresherwidgetset ? (or similar)
Is there any point if Q1 says don’t worry, it can handle this?.
Note also that the widgetset contains the javascript for the core and all the components/addons you use. You cannot use multiple widgetsets in an application and you cannot compile the widgets individually.
Thanks guys.
I am already using some of Chris Brind’s ideas. Those are my comments on his blog.
As I read up on GWT, I see there are a number of choices that can be made, for example, from GWT documentation:
"If you have multiple GWT modules in your application, there are two ways to approach loading them.
Compile each module separately and include each module with a separate tag in your HTML host page.
Create a top level module XML definition that includes all the modules you want to include. Compile the top level module to create a single set of JavaScript output.
The first approach may seem the easiest and most obvious. However, the second approach will lead to much better end-user performance."
Artur seems to be saying Vaadin uses option 2 here - only one widgetset gets downloaded to the browser. However, the default widgetset already lives in the Vaadin-x.x.x jar at VAADIN/widgetsets. If I make a drop-in OSGi fragment jar, then I think I will be using what is called split packaging, with my updated widgetset containing Refresher in the fragment VAADIN/widgetsets. I think the OSGi result will appear to be one directory with two widgetsets in it (but I am not sure).
I must then arrange that ServletConfig has a property widgetset=newWidgetset. Perhaps Felix console can do that.
Now I have the whiteboard pattern working nicely as a bunch of bundles running under Felix.
One of the bundles is a bundle-fragment associated with the stock Vaadin jar holding just Refresher.
To build the whole thing, I first downloaded Vaadin 6.3.4 source and put that in a Eclipse project and built it. I use the stock Vaadin-6.3.4.jar without modification as a key bundle. The source code is needed to have access to the server side sources and classes required to make the widgetset.
I then put Refresher source code into a separate Eclipse project. I then ‘borrowed’ bits of the Vaadin build to make a Refresher standalone Ant build. It reaches into the Vaadin project to pull classes needed to make the widgetset which it integrates with its copy Refresher sources.
The fragment bundle just has the two or three Refresher server classes on their usual path but also includes the Refresher widgetset on the path VAADIN/widgetsets. I made the bundle with Ant.
Other key parts of my ensemble are a theme bundle fragment holding MyTheme built following Chris Brind’s ideas.
VaadinBridge from Neil Bartlett works with Vaadin session management to ensure that instances Vaadin Applications are created correctly. Again I used the source code and just made a small change to ApplicationFactoryTracker adding properties:
properties.put(“widgetset”, “org.vaadin.henrik.refresher.widgetset.Refresherwidgetset”);
This attaches the widgetset configuration to the servlet registration:
httpService.registerServlet(“/” + alias, servlet, properties, httpContext);
My key bundles are:
org.apache.felix.scr-1.4.0.jar ( supports OSGi Declarative Services)
Vaadin-6.3.4.jar
VaadinBridge.jar ( also serves static content from the jars and fragments)
StaticContentServer.jar (serves out-of-jar content)
TopicService.jar ( An empty whiteboard)
TopicFactory.jar (fills a few whiteboard cells)
custom.theme.jar ( a descendent of Reindeer)
Refresher.jar ( pings the server at intervals)
org.apache.felix.http.jetty-2.0.4.jar
The whole can work by dropping the bundles in the Felix bundle directory. Additional topics drop in too and Felix / DS-SCR makes them go.
Robin, would you be willing to share your refresher osgi plugin source bundle (and/or the necessary bundles to produce it)? I have attempted but without success to include refresher in my vaadin osgi app. Thanks
