Hi Peter, I am very glad to read, that more work is done releating to web apps. I'd like to remind you of a discussion in this forum concerning the topic "resource loading" in web apps (I pasted the contributions in this mail).
In our company we use pure OSGi to develop web apps and deploy them as WABs in the framework. Everything works fine with our modularized business layer using µservice. But we are still not happy with our approach for the modularization of the presentation layer where we need resource loading. Our problem is that resources can only be loaded from the WAB-bundle. So we deploy our resource modules als fragments of the WAB-bundle. But this has the known disadvantages concerning dynamics. So we are looking forward to standardized solution for this. Best regards, Andreas Klotz > > 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]> > >>> <mailto:[email protected] <mailto:%[email protected]> > > >>> -----Ursprüngliche Nachricht----- Von:Peter Kriens <[email protected]> Gesendet:Fr 19.07.2013 09:05 Betreff:Re: [osgi-dev] OSGI is hard Anlage:inline.txt An:OSGi Developer Mail List <[email protected]>; I do agree with the judgement that OSGi is hard to get started with. The problem with OSGi is that it not only blatantly shows how unmodular your and much open source code is, it even refuses to run your code. In many ways it is like your compiler refusing to compile until you fixed the last of many warnings. Though this is all for good reasons, in reality a lot of code is actually running ok even though it is a mess on the inside. So using standard classic Java patterns do not work very well, mostly due to extensive dynamic loading to configure the app, which is fundamentally not modular. This makes it really hard to get started with OSGi because a lot of open source libraries do not work well with OSGi for this reason. And even if they run, too few actually leverage OSGi Last year I found out how hard it is to live outside an App server or not use Spring. For a web app there is a lot of stuff that you have to think about that is completely orthogonal to your domain: persistence, security, caching, queuing, batching, etc. Unfortunately, those OSGi components that provide that functionality are not there. Lots of open source libraries, but none work really well in OSGi, they all have their own configuration models, life cycle, etc., sticking out like sore thumbs. I also frequently have to cry when I look how open source libraries try to use OSGi :-( This is the exact reason the OSGi Alliance has hired me again. My task for the foreseeable future is to develop a framework for web apps that leverages OSGi to the hilt, i.e. it does it all in the OSGi way. The idea is to create a skeleton around the OSGi µservice model and provide a concrete example how this skeleton can be used to create web apps. All this extensively documented for end users and not specification implementers. It also intent to have a full modular development chain: IDE, build, ci, release, deployment. My goal is to make web app development as easy and simple like PHP but as robust as OSGi (I know, its ambitious). I am currently writing an RFP to define the scope of this work, which is hard since this is a very broad field. I'd love to get your ideas as input. The RFP will become publicly available under our new process. Looking forward to your input, kind regards, Peter Kriens On 18 jul. 2013, at 19:50, Krishnan Ganapathy wrote: Hi Scott, Am glad at this initiative. Very much needed I think. There is a lot of grey areas still.. I dont see how web application developers can become comformtable with OSGI concepts. At times it looks very fuzzy even to me. I would be glad to contribute my two cents to this. I dont know if this forum is appropriate for this discussion. Maybe someone can throw light here... Regards Krishnan On Thu, Jul 18, 2013 at 9:30 PM, <[email protected]> wrote: Send osgi-dev mailing list submissions to [email protected] To subscribe or unsubscribe via the World Wide Web, visit https://mail.osgi.org/mailman/listinfo/osgi-dev or, via email, send a message with subject or body 'help' to [email protected] You can reach the person managing the list at [email protected] When replying, please edit your Subject line so it is more specific than "Re: Contents of osgi-dev digest..." Today's Topics: 1. 'OSGi is hard' (Scott Lewis) ---------------------------------------------------------------------- Message: 1 Date: Wed, 17 Jul 2013 12:47:26 -0700 From: Scott Lewis <[email protected]> To: OSGi Developer Mail List <[email protected]> Subject: [osgi-dev] 'OSGi is hard' Message-ID: <[email protected]> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Hi Folks, I would like to start a public discussion around the comment/mis-perception that I've received several times from new OSGi adopters: 'OSGi is hard'. I know that there's a lot bound up in this comment (e.g. complexity of dependencies, modularity, tooling, unfamiliarity with key concepts, etc). I would eventually like to counter this comment with examples, tutorials, tooling, reading, presentations, sequencing of all these etc., etc...whatever is most effective...but before going further...is this the right forum for such a discussion? Or is there a better/more appropriate public OSGi forum? Thanks, Scott ------------------------------ _______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev End of osgi-dev Digest, Vol 81, Issue 6 *************************************** _______________________________________________ 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
