existing vaadin osgi implementation comparison

[Christopher Brind]

Hi all,

I've been having a look at Neil's OSGi approach to Vaadin (
http://njbartlett.github.com/#VaadinOSGi ) as compared with my own and
Neil's OSGi experience obviously wins through. :)

I like the de-coupling from DS, where as mine requires DS because of
the Component Factory approach and of course Neil's approach has the
ability to add more property based meta-data.

Some other comments:

Resources - the problem with Neil's approach seems to be that the
Vaadin bundle would need to be changed.  My approach doesn't change
the standard Vaadin jar/bundle at all. A servlet handles the /VAADIN
request and loads the resource directly from the Vaadin bundle uses
the bundle's

Plus, I'm of the opinion that static resources should not be being
served by the OSGi container in a production environment - better to
put an Apache web server in front (for example) and serve them from
there, which is easy to do as all you do is serve static content for
/VAADIN path and let everything else proxy through to the OSGi server.

Neil, I couldn't quite get my head around your suggestion of using
HttpContext - could you provide a code sample for that, please, as I
think I'm missing something useful there.

Framework:

An earlier attempt at OSGi / Vaadin application (one of the things
that helped me find Vaadin) introduced modules and I like this idea:
http://vaadin.com/wiki/-/wiki/Main/Creating%20a%20Modular%20Vaadin%20Application%20with%20OSGi

So right now I'm liking the idea of combining the module example above
with Neil's ApplicationFactory interface.

Cheers,
Chris

[Neil Bartlett]

Thanks for your review Chris.

Regarding the resources, in fact my document was wrong. I am not
modifying the core Vaadin bundle at all. Instead I use the
HttpService's registerResources method to ensure that the resources
already existing inside the core vaadin bundle are accessible under
the /VAADIN context path. This is the purpose of the HttpContext I
mentioned: it merely maps the external HTTP URL for the resource (e.g.
http://example.com/VAADIN/themes/default/styles.css) to the internal
Java resources, which are loaded via Bundle.getResource().

The other use of HttpContext in my code is to ensure that Application-
specific resources are loaded from the Application bundles. When
registering a servlet with HttpService, we always have the option to
pass in an HttpContext, or we can pass in null. If null is passed then
a default HttpContext is used, and (at least on Equinox) this would
cause resources to be loaded from the calling bundle... i.e. the
central "vaadinbridge" bundle, rather than the application's bundle. I
think this may have been the cause of the problems Peter described.

I agree with you that static resources should be loaded from a static
resource server like Apache. Since the core Vaadin resources are all
under the /VAADIN path, I assume that Apache can be configured to
serve those resources while other URLs go to the Servlet engine. In
that scenario it certainly doesn't hurt to have the resources mapped
in the Servlet engine as well. They will always be there as a
fallback, just in case there is no fronting Apache server, or it has
not been configured properly.

Cheers
Neil

On Apr 29, 11:11 pm, Christopher Brind <bri...@brindy.org.uk> wrote:
> Hi all,
>

> I've been having a look at Neil's OSGi approach to Vaadin (http://njbartlett.github.com/#VaadinOSGi ) as compared with my own and

> Neil's OSGi experience obviously wins through. :)
>
> I like the de-coupling from DS, where as mine requires DS because of
> the Component Factory approach and of course Neil's approach has the
> ability to add more property based meta-data.
>
> Some other comments:
>
> Resources - the problem with Neil's approach seems to be that the
> Vaadin bundle would need to be changed.  My approach doesn't change
> the standard Vaadin jar/bundle at all.  A servlet handles the /VAADIN
> request and loads the resource directly from the Vaadin bundle uses
> the bundle's
>
> Plus, I'm of the opinion that static resources should not be being
> served by the OSGi container in a production environment - better to
> put an Apache web server in front (for example) and serve them from
> there, which is easy to do as all you do is serve static content for
> /VAADIN path and let everything else proxy through to the OSGi server.
>
> Neil, I couldn't quite get my head around your suggestion of using
> HttpContext - could you provide a code sample for that, please, as I
> think I'm missing something useful there.
>
> Framework:
>
> An earlier attempt at OSGi / Vaadin application (one of the things

> that helped me find Vaadin) introduced modules and I like this idea:http://vaadin.com/wiki/-/wiki/Main/Creating%20a%20Modular%20Vaadin%20...

[Scott Lewis]

FWIW...

I spent an afternoon going through what Neil went through...defining
an httpcontext that would load the /VAADIN resources from inside the
application bundle. I hacked it together...so that it would just
read the resources from inside the app bundle...and I just put the
vaadin lib on the app bundle classpath. But that was a hack...I
realized that Neil''s way of having a separate vaading lib bundle (or
perhaps bundles...not sure whether separating out the vaadin libs into
multiple bundles makes sense) is the right way.

If the vaadin code and /VAADIN resources are in a bundle(s) separate
from the app (as they should be, I think), then I would suggest that
there be some flexibility for mapping resources built in to this
bundle...i.e. with the default path being inside this bundle(s)...and/
or fragments that are attached to it (for extending via Vaadin
components?)...but with the ability to specify at runtime some other/
additional resource paths to consider/use at resource access time.

I noticed, btw, that Vaadin has a little bit of such flexibility built
in...i.e. there is the ability to specify the resources path as system
parameter or specifically for the Vaadin Application. I suppose that
should just be duplicated in some form in the OSGi/bundle/multiple
classloader world.

In any event, fwiw I think we should first figure out how to setup the
resource access (e.g. HttpService.registerResource) so that the
separate vaadin library bundle(s) can access the default
resources...inside the vaadin bundle I guess...and then introduce
flexibility to handle (e.g.) replacement resource paths, Vaadin
extensions, etc.





vaadin code

On Apr 29, 4:12 pm, Neil Bartlett <njbartl...@gmail.com> wrote:
> Thanks for your review Chris.
>
> Regarding the resources, in fact my document was wrong. I am not
> modifying the core Vaadin bundle at all. Instead I use the
> HttpService's registerResources method to ensure that the resources
> already existing inside the core vaadin bundle are accessible under
> the /VAADIN context path. This is the purpose of the HttpContext I

> mentioned: it merely maps the external HTTP URL for the resource (e.g.http://example.com/VAADIN/themes/default/styles.css) to the internal