Hello Ancoron,

thanks for your reply. I get your point and I share your concerns over the
"import/export"-approach. And your suggestion
> Web-Host: <symbolic-name-of-wab>
looks very interesting.

Best regards,
        Andreas



> 
> 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


_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev

Reply via email to