since i am getting a lot of requests according vaadin 7 and OSGi i would like to keep you informed about the status quo.
The vaadin 7 OSGi bridge is on its way. I started to implement it with Vaadin 7 alpha 2. And i have changed it many times. In the first beta i used icepush addon but decided to wait for vaadin 7 native push before i am going to release the addon at vaadin directory.
Today i could make things work. See
Ticket 11691 . As far as ticket is resolved i will make the addon available with all things required like examples and documentation. Btw. the example is already finished.
All the artifacts can be found in lunifera.org repos.
The vaadin 7 OSGi bridge is based on OSGi DS (declarative services) and OSGi CM (Configuration Admin). It allows you to update the settings like url alias and production mode (and so on) by Config Admin. Changes will stop the vaadin application properly and start it again automatically. All the settings can initially be defined in a .cfg file in bundle to use defaults.
If you have any questions, do not hesitate to contact me by email, skype,…
But today i got another not vaadin related bug. atmosphere 1.0.13 and jetty 8.1.10 are not combinable for now. Added details to the bug above. I am not sure whether its a bug of atmosphere or a bug related to jetty. Added a bug report to atmosphere ticket system to get an answer.
lunifera vaadin 7 OSGi bridge works pretty good without vaadin-push:
With vaadin-push it requires atmosphere.
The current atmosphere 1.0.14-SNAPSHOT fixed the ClassLoading bug.
But there is a problem with equinox.http and equinox.jetty. (Can be solved by using lunifera.http and lunifera.jetty):
A ServletContext-Listener is added after ServletContext was started. And jetty throws exception.
lunifera.http resolves that problem by providing the HttpService before deploying it at jetty-instance.
Conclusion:
I will prepare an OSGi-bridge vaadin-addon without push-support for now. I can be used on any HttpService. Does not require jetty.
As far as atmosphere 1.0.14 is realeased, i will add the push support to it and will also provide a proper target definition to setup lunifera.http and lunifera.jetty. The push is limited to jetty server as long as the new OSGi impl for servlet specification is available.
Any comments on it?
Think that the vaadin-addon is available by end of next week.
Good to hear that. I just started to make some tests regarding Equinox/Jetty/Vaadin, to see if it’s a good time to jump into Vaadin 7 or not.
Currently we use Vaadin 6 + GlassFish OSGi (Felix), and it works very well. But GlassFish have it’s issues and Grizzly isn’t exactly friendly when we try to use WebSockets (we are using it successfully, however).
I’m very curious about how well Vaadin 7 plays along WebSockets, Equinox and Jetty.
Tomorrow I’ll get the Lunifera Bridge to play a little.
until thursday evening i am in customer workshop. I will prepare the vaadin addon on friday. By end of this week it should be available. The one without push.
I will also add a target platform to setup the push one properly.
If OSGI httpService suites, then the only problem with our application bundle is finding resources, assuming that UI is in the same bundle . Solution : extend httpContext. In my working solution I had to : pass “Resource” parameter to servlet init - same as servlet alias , register resources in osgi “/servlet_alias/VAADIN”. In httpContext main override is “getResource()” … in this place we can do all we need.
You can use the extender pattern. Just place all your resources into a folder in a bundle and add a manifest header to the bundle pointing to the relative path containing the resources.
For instance if your resources are located in the folder: /resources
Vaadin-Resources: resources
Then org.lunifera.runtime.web.vaadin.osgi.servlet.WebResourcesHttpContext will hook up your bundle and adds it to the resource access path.
Sure, you also may use the HttpService to do. But using extender pattern is much simpler.
Resources in standard vaadin libraries are placed where there are, in vaadin 7 there are bundles: server, themes and client-compiled. There are 3 bundles. My application is 4th, that imports that 3 ( strictly 1 - server ), but that 3 have no knowledge of mine bundle. Do you suggest that’s possible to assembly this resources with simply Vaadin-Resources ?
Therefore we have implemented the extender pattern. org.lunifera.runtime.web.vaadin.osgi.servlet.WebResourcesHttpContext observes all starting bundles and add them to an internal resource path. If a request for resources (/VAADIN…) comes along, the WebResourcesHttpContext will receive the request and delivers the resources. Also resources from vaadin.server, vaadin.theme,… are delivered by this class.
The best would be to setup the lunifera osgi bridge example from vaadin addons and do some debugging in WebResourcesHttpContext.
Status “resolved” is enough to have exposed bundle, at least passive like static resources ( could they be unresolved at all ? ). I go other way than you, you make “generic”, I try to find the way to write “template application”, which allow to define which resources and VERSION of these to include. In my solution resolving resource request is private to application, in yours global - right ? It’s only a play with osgi classloaders in my opinion. More exciting is to assembly application from modules by end user - choose what you want and play. I will appreciate your ideas.
Yes, we are tracking status “resolved” too. It is enough.
Since we are using the extender pattern every application may provide its resource access path relative to bundle.
The resolving step is global right. But each application contributes its resources.
I did not get your idea and what you are trying to do with. Can you give me an example?