Hi Andreas,
I agree, having a specified solution for these enhanced WAB resource
"dynamics" is highly appreciated. And yes, my ideas are a bit of a
"workaround".
I think one of the reasons not going this far yet is performance. As
everything that is highly dynamic puts additional constraints onto
things like e.g. caching and management. And in a stateless -
non-managed - scenario: if the DefaultServlet or anyone else would have
to ask 30 bundles only to find out that a specific resource is not
available it would just cost CPU time. So you'd better have a registry
(at least for availability) and hence, management overhead.
For your approach with exporting the META-INF/resources as a package
doesn't work nicely, I think, because how would you import
META-INF/resources multiple times (from different bundles)?
Yet another idea: usually, the DeaultServlet should use the
ThreadContextClassloader of the WAB to locate resources (at least this
is the case for GlassFish, which is originally based on Catalina). So
what if you provide an OSGi-aware Classloader e.g. using a generic
ServletFilter?
I just had a look inside the implementation of the WebappClassLoader
that GlassFish makes up and they already have the ability to add
multiple "repositories" for resource loading. So as an alternative, if
this approach works too, you just have to add or remove "repositories"
for the WebappClassLoader, instead of hacking around.
This could be more like a candidate for a spec, I think, as
implementations already support multiple source roots using the
"Bundle-ClassPath" header. Providing a special header inside bundles
that want to publish resources for a specific WAB, e.g.:
Web-Host: <symbolic-name-of-wab>
Cheers,
Ancoron
On 01/18/2012 09:52 AM, Andreas Klotz wrote:
Hello Ancoron,
thanks for your suggestion. We did something similar before switching
to a specified solution to be more flexible concerning different deployment
scenarios and future requirements. The problem with your approach is
that you also need to modify the resource loading mechanism of the
servlet context.
If a static resource, e.g. an image, is requested, the servlet
container usually dispatches this request to a default servlet which
calls the getResource()-method of the ServletContext and then serves
the resource to the client. So the resource
has to be made available to the ServletContext. To get the resource
from a "plugin"-WAB one has to modify the default behavior of
the servlet container. That of course can be done. For example
Jettys ContextHandler provides a method setBaseResource() to
inject a customized implementation of Resource that has access
to other bundles resources via bundle.getEntry().
I still like the idea of loading resources from other bundles META-INF/resources
path and make them available in the WAB by importing them as a package.
This approach is close to the servlet 3.0 spec mechanism which allows
loading resources from jars in WEB-INF/lib. Since imported packages
of other bundles are treated by the WAB like packages of jars in WEB-INF/lib
by a standard WAR this idea seems to be obvious.
I wonder
- if I missed some point that makes the idea not going to work
- or if this approach should be covered by the WAB-Spec.
Best regards,
Andreas
Hello Andreas,
sorry if I just jump in, but what about this:
* a lightweight "core" WAB containing the basics for a web portal
* "plugin" WABs with a defined structure that provide additional resources as
well as functionality
Now you have several options to implement this (there is nothing
comparable inside official specs up to now AFAIK):
1.) Extender pattern:
With your "core" WAB you also register an Extender that picks up those
"plugin" bundles and does all the magic for registering stuff by partly using
official mechanisms/APIs but also allows to do any custom stuff.
2.) Custom Services:
Let's say you want to provide the following with your new "plugin" bundles:
* static resources (CSS, JavaScript, HTML, images, ...)
* functionality (JSF, JSP, Servlets, CDI beans, EJBs, ...)
Now I could imagine to have a custom "PluginService" interface which
identifies "plugins" which contains methods to get everything you need to
access.
In the "core" WAB you just listen to those services becoming available or
going away and register/unregister appropriately.
E.g. if you then need to build up a web navigation menu or the sitemap, you
would simply iterate over all registered services and retrieve the information
you need - purely on-demand - or cache at registration time.
The same would apply to anything else.
The "PluginService" interface, of course, depends on what you actually need
but can be adopted to almost anything.
Although it would be nice to have something like this at hands with
official APIs you could also have a look if there are frameworks
available that enable you to describe such things, so that you don't
have to write everything on your own.
...just an idea...
Cheers,
Ancoron
On 01/17/2012 10:48 AM, Andreas Klotz wrote:
Hello Peter,
that is what we have. The WAB serves the static content and provides
access to the web framework. Static resources belonging to modularized
business
units (as separate bundles) are attached as fragments to the WAB and so
cannot be activated/
deactivated independently.
We would prefer to deliver the resources with the bundles implementing
the controllers of the web GUI. So that we have a full featured
presentation
layer bundle with controller logic and views with its needed static
resources.
Best regards,
Andreas Klotz
A WAB with only static content does not suffice?
Kind regards,
Peter Kriens
On 12 jan. 2012, at 09:27, Andreas Klotz wrote:
Hi everybody,
we have built a modular application platform using OSGi.
To us it is important not only to build modules in the
service layer but also in the GUI layer.
Our GUI is a web application and we decided to deploy
it as a WAB. We are using ZK Ria as web application framework.
Everything works fine with regard to reference other
bundles from our WAB up to the controller layer. But
when it comes to serve static resources from the WAB
we are not very happy with our solution.
We would like to separate the static resources also
in bundles analogue to the modularization of the business
and controller layer. But WAB does only support loading
resources from the WAB itself and its fragment bundles.
So for every business module we build a fragment bundle
with its appendant resources such as HTML, CSS, JPGs ...
But using fragments leads to loosing dynamic since we
cannot activate/deactivate the fragments. But we would
like to activate/deactivate, install/uninstall modules
at run time.
Servlet specification 3.0 allows loading of resources
from jar files in WEB-INF/lib if they are located
in META-INF/resources inside the jar. Since imported
packages of the WAB are (nearly) treated like jars in WEB-INF/lib
in a servlet container I was wondering if I can import
META-INF/resources from another bundle and load resources
from it. Of course one has to use a servlet 3.0 conform
container.
I have not found anything about this topic in the WAB
spec. Some experiments with Gemini 2.0 were not successful.
I have read that GlassFish supports this approach.
Should the WAB spec cover this topic? Or is it up to
the implementers such as Gemini or PAX web to deal
with it? Or is there another solution for loading
static resources from modules?
Best regards,
Andreas Klotz
--
phone: +49 (221) 222 896 24
fax: +49 (221) 222 896 11
email: [email protected]<mailto:[email protected]>
------------------------------------------------------------------------
*n - d e s i g n G m b H*
www.n-design.de<http://www.n-design.de/>
Alpenerstr. 16
D-50825 Köln
Amtsgericht Köln HRB 33766 B
Geschäftsführer Andy Kohl
_______________________________________________
OSGi Developer Mail List
[email protected]<mailto:[email protected]>
https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
