OSGi/Vaadin with no web container

[robinh]

What I am trying to do.

An industrial control kind of system where servlets are representing
state and allowing control of various hardwares.

For now, I have decided that actual hardwares should each have their
own RESTful servers allowing them to be anywhere on a network.
However, these servers only provide state (GET) and allow changes to
it (POST) with no gui, just JSON. Resources are available by GET (url)
and respond with JSON state. Similarly POST. Hardware looks somewhat
like a database.

User interface is provided by an OSGi framework server. It can
present static home or other pages that someone with a very modest
knowledge of html might use to customise his particular presentation.
In addition, it allows for canned (Vaadin) drop-in pages showing
controls which ultimately connect through REST to hardware. I read
that Vaadin can support "canned" widgets which can be interleaved with
ordinary html (I did not try that yet) and allow a degree of
custumisation without getting into Java. I would include something
like the Vaadin 3 tab panels example, see
http://vaadin.com/wiki/-/wiki/Main/Creating%20a%20Modular%20Vaadin%20Application%20with%20OSGi

Specifically, I do not wish to use a Web service container as that is
just another level of complexity that ordinary users do not need.
There will be no IT infrastructure to manage servers, and this is not
building Amazon.com. So no Apache, Tomcat or Glassfish.

The sole startup requirement should be to boot the OSGi framework,
perhaps with a few modifications to config.ini, but for the most part,
just ( dragging and ) dropping bundles into say Felix's bundle
directory.

So what do I need?

What I think I need:

1. Vaadin seems a good start. I tried GWT, but then I am left handling
RPC. And GWT is not really OSGi-friendly. Vaadin (I think) uses JSON
instead of RPC to handle remote access and does not OSGi-stress the
finer points of GWT. It seems clever to develop widgets for display
on the browser which have very reusable code because Vaadin people
have to worry about the implementation, and the servlet end just
transparently uses the Vaadin AJAX display capability.

2. A static html server with no state (sessions) which can handle home
pages and icons. This was an easy extension to HttpService with a
method add( alias,location) which could easily be connected to
properties. In addition it needs to handle URL forwarding to deal
with browser one-source policies, but this is perhaps no problem when
using Vaadin as the communication is from the servlet not the
browser. It is useful if Javascript code needs third party data.

3. A server to handle static Vaadin resources, javascript, css, etc.
Chris Brind's class StatisResources does that well. That does need
not need session awareness as it is just serving static Vaadin
resources from the Vaadin distribution jar. See
http://www.perplentropy.com/2010/02/in-bed-with-vaadin-and-osgi.html
The design allows use of the vaadin jar without alteration, an
important consideration.

4. Chris Brind's Vaadin resource supplement fragment jar also seems a
useful idea and addition allowing Vaadin Themes to be extended.

5. On the other hand, I found his VaadinOSGiApplicationManager hid the
servlet too much and made it difficult to connect the servlet to the
world outside. See for example the discussion
http://vaadin.com/forum/-/message_boards/message/85141

Instead, Neil Bartlett's ExampleApplication and ExampleAppFactory,
http://njbartlett.github.com/#VaadinOSGi%C2%A0
seems to have the capability to expose the components to connection to
the wide world while at the same time incorporating session
management. This code needs to extended to include connection to
HttpService.


So now I am going to try to stitch these pieces together.

Do you think this is the way to go?

[Neil Bartlett]

Robin,

My code already connects to HttpService. Just publish a service under
the ApplicationFactory interface, and the vaadinbridge bundle will
wrap it with a Servlet and register with the HttpService. Chris's code
also does this.

Really, my code and Chris's code are *extremely* similar. The only
difference is that I defined a new factory interface
(ApplicationFactory) whereas Chris reused an existing one
(ComponentFactory) from the OSGi Declarative Services (DS)
specification. I felt that reusing the DS interface was sub-optimal
because some people might not want to use DS; e.g. they might prefer
Blueprint or iPOJO or whatever.

Kind regards,
Neil

[robinh]

Thanks Neil for your interest.

Oops! I read your page http://njbartlett.github.com/#VaadinOSGi%C2%A0
and I did not see any mention of VaadinBridge and did not think to
look further than the examples on the github VaadinOSGi page when
looking into your project. I missed it completely!

Thanks for putting me right! Now I have downloaded the project zip
will take now take a closer look.

Later ... When I was building the jars, I was getting errors about
missing some aqute repo plugin so I switched to bnd instead of bnd.bnd
and built the jars.

Now I get clock messages in the log on click!. That only took me about
half an hour. Great! I also see both the similarities and differences
between your approach an Chris's.

I downloaded BndTools quite recently. Is there some extra plug-in
that BndTools needs for this? I changed the classpaths to use my own
bundle user library which I made for general OSGi use and then quickly
made the two jars. I also logged some other problem I had with
BndTools as a bug. Did you see that? Maybe it was my finger trouble.

Returning to the real problem.

With Chris's code it seems that it is hard to use his bundle as I did
not see how to pass object references to the servlet/application.
The only way to communicate from the application factory to the
instance created by the servlet is through properties.

I see the same issue in your code.

I am a novice at this stuff (as you may have gathered), but when I
look at the three tabs example (
http://vaadin.com/wiki/-/wiki/Main/Creating%20a%20Modular%20Vaadin%20Application%20with%20OSGi
), they rely on DS (Glassfish?) injecting a ModuleService reference
into the servlet. My thoughts are that DS can not handle the case of
injecting into a factory instance. Perhaps it can?

So my problem is having the application servlet inside the
VaadinBridge or com.vaadin.osgi jar. I need to be able to modify the
servlet to either give it a constructor with object references or
inject it somehow with one or more object references. This also has
to consider there may be N instances and in any case it is the
ComponentFactory instance actually makes the instance.


Now I am trying to get the 3-tabs example going using a factory. In
Vaadin site's original example by Petter Holmström, he uses Glassfish
to inject the ModuleService into the servlet. He is not worrying
about factories. Does this mean his example won't really work as soon
as there are two sessions?

There is another post around that discusses object references on the
Vaadin forum...
http://vaadin.com/forum/-/message_boards/message/85141
so I am not quite alone here.

I can solve this by exploding either jar, VaadinBridge or
com.vaadin.osgi and just making a custom version. But having the
bridge inside a jar seems a neat way to encapsulate most of the
functionality.

So what I am wondering is just how to do this. It seems good to retain
the concept of a jar bridge but also to expose the option of extending
the servlet something like Petter Holmström's example. The second
point is how to initialise factory instances with references?

Neil's page on VaadinOSGi says "The simplest modular approach is to
put each application on a tab."
That is what I am trying to do, but I don't quite see the best way to
connect the dots.

Any suggestions?

[robinh]

Later ... I think I am seeing the way.

Chris's method cannot handle what I need to do because there is a need
for an ApplicationFactory which can be customised.

Neil's method provides for this by defining the ApplicationFactory as
an interface which can be customised. The implementation of
ApplicationFactory will be a component of cardinality one so can be
injected with references as needed.

The references can then be passed and shared and used by each instance
of the sub-class of Application which renders the Gui.

The servlet can be generic and does not need sub-classing. It just
serves Applications.

The factory methods of DS cannot support the required functionality,
so VaadinBridge has to be done with ServiceTrackers.

All the required functionality can be encapsulated in VaadinBridge.jar
as its name implies.

Brilliant!

Sorry for being slow.

Now to work with VaadinBridge!