Announcement Announcement Module
Collapse

Spring Dynamic Modules forum decommissioned in favor of Eclipse Gemini Blueprint

With the official first release of Eclipse Gemini Blueprint shipped, the migration of the Spring Dynamic Modules code base to the Eclipse Foundation, as part of the Gemini project, has been completed.

As such, this forum has been decommissioned in favour of the Eclipse Gemini forums.
See more
See less
How to modularize a JSF/Facelets/Spring application with OSGi? Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • How to modularize a JSF/Facelets/Spring application with OSGi?

    Hi,

    I hope you forgive me for reposting my question from stackoverflow.


    I'm working with very large JSF/Facelets applications which use Spring for DI/bean management. My applications have modular structure and I'm currently looking for approaches to standardize the modularization.

    My goal is to compose a web application from a number of modules (possibly depending on each other). Each module may contain the following:

    * Classes;
    * Static resources (images, CSS, scripts);
    * Facelet templates;
    * Managed beans - Spring application contexts, with request, session and application-scoped beans (alternative is JSF managed beans);
    * Servlet API stuff - servlets, filters, listeners (this is optional).

    What I'd like to avoid (almost at all costs) is the need to copy or extract module resources (like Facelets templates) to the WAR or to extend the web.xml for module's servlets, filters, etc. It must be enough to add the module (JAR, bundle, artifact, ...) to the web application (WEB-INF/lib, bundles, plugins, ...) to extend the web application with this module.

    Currently I solve this task with a custom modularization solution which is heavily based on using classpath resources:

    * Special resources servlet serves static resources from classpath resources (JARs).
    * Special Facelets resource resolver allows loading Facelet templates from classpath resources.
    * Spring loads application contexts via the pattern classpath*:com/acme/foo/module/applicationContext.xml - this loads application contexts defined in module JARs.
    * Finally, a pair of delegating servlets and filters delegate request processing to the servlets and filters configured in Spring application contexts from modules.

    Last days I read a lot about OSGi and I was considering, how (and if) I could use OSGi as a standardized modularization approach. I was thinking about how individual tasks could be solved with OSGi:

    * Static resources - OSGi bundles which want to export static resources register a ResourceLoader instances with the bundle context. A central ResourceServlet uses these resource loaders to load resources from bundles.
    * Facelet templates - similar to above, a central ResourceResolver uses services registered by bundles.
    * Managed beans - I have no idea how to use an expression like #{myBean.property} if myBean is defined in one of the bundles.
    * Servlet API stuff - use something like WebExtender/Pax Web to register servlets, filters and so on.

    My questions are:

    * Am I inventing a bicycle here? Are there standard solutions for that? I've found a mentioning of Spring Slices but could not find much documentation about it.
    * Do you think OSGi is the right technology for the described task?
    * Is my sketch of OSGI application more or less correct?
    * How should managed beans (especially request/session scope) be handled?

    I'd be generally grateful for your comments.

  • #2
    Your post asks a lot of big questions...
    First of all, it depends on what you mean by modularization - do you want it to be dynamic or not? Does it only grow or can it shrink as well? You don't need to answer this questions rather you have to consider them as requirements.
    Adding new things to an application is significantly easier then removing them for example.

    Additionally, are you interested in just loading resources or in objects as well? If it's the former, you can usually get away by providing customized loaders or bridges - however for the latter you need to establish some discovery procedure for objects which can be tricky. And if your objects can come but also go, things become even more difficult.

    When one mentions modularity, OSGi is definitely a good candidate however it depends on the exact needs. OSGi might work very well for your case but it seems to me you have a customized scenario where OSGi might fit only partially and a custom solution might be easier to implement.
    OSGi helps a lot if you want to isolate things in your application - if that's not a primary concern for you then you might consider a custom approach or look at the support for fragments.
    If again, that doesn't work then extending the ClassLoaders of your container or doing your own thing might be better.

    1. Potentially but then again, you can't always get a solution of the shelves. Ask about Spring Slices in the dmServer/tcServer forums.
    2. see above
    3. you're in the ball park.
    4. In general, if these are shared, they are published as services so they just go away. OSGi services do not support custom scopes so you'd have to use aop:scoped-proxy-like approach - you get the same object (the proxy) on each call but the invocation is executed on the appropriate managed instance.

    To conclude, from your post I understand you are looking for more of a packaging/deployment solution and not so much of a modular (as in isolation/multiple versions) approach. OSGi can help a lot with the latter and only partially with the former.

    Comment


    • #3
      First of all, thank for the response. I was already a bit desperate to get any answers at all.

      Originally posted by Costin Leau View Post
      Your post asks a lot of big questions...
      First of all, it depends on what you mean by modularization - do you want it to be dynamic or not? Does it only grow or can it shrink as well? You don't need to answer this questions rather you have to consider them as requirements.
      Adding new things to an application is significantly easier then removing them for example.
      My primary goal is to break one big WAR into smaller entities using standardized mechanisms. For this very goal I don't need modularization to be dynamic.

      However, it is very intriguing to be able to add or replace modules in the runtime without having a need to stop the application. Like "deployed a new version of the user management module - discovered a problem few days later - replaced the module with the earlier version - fixed the problem - replaced the module with a newer version".

      Additionally, are you interested in just loading resources or in objects as well? If it's the former, you can usually get away by providing customized loaders or bridges - however for the latter you need to establish some discovery procedure for objects which can be tricky. And if your objects can come but also go, things become even more difficult.
      I am not quite sure what do you mean with "objects", but the answer is yes, probably. We need to use request and session-scoped beans across modules. So it's not only about resources.

      When one mentions modularity, OSGi is definitely a good candidate however it depends on the exact needs. OSGi might work very well for your case but it seems to me you have a customized scenario where OSGi might fit only partially and a custom solution might be easier to implement.
      We've got a custom solution working right now, what I'm looking for is standardization. If third parties are to implement extensions for our software, OSGi is politically a much better basis that our own custom deployment/packaging approach.

      OSGi helps a lot if you want to isolate things in your application - if that's not a primary concern for you then you might consider a custom approach or look at the support for fragments.
      "Support for fragments"? It's something new for me. Do you mean Servlet API 3.0 web-fragment.xml or something different?

      If again, that doesn't work then extending the ClassLoaders of your container or doing your own thing might be better.
      I really don't like the idea of writing classloaders for containers.

      1. Potentially but then again, you can't always get a solution of the shelves. Ask about Spring Slices in the dmServer/tcServer forums.
      2. see above
      3. you're in the ball park.
      I'm really sorry, I can't decipher this idiom, may I ask you to rephrase?

      4. In general, if these are shared, they are published as services so they just go away. OSGi services do not support custom scopes so you'd have to use aop:scoped-proxy-like approach - you get the same object (the proxy) on each call but the invocation is executed on the appropriate managed instance.
      Thank you, now I understand.

      To conclude, from your post I understand you are looking for more of a packaging/deployment solution and not so much of a modular (as in isolation/multiple versions) approach. OSGi can help a lot with the latter and only partially with the former.
      Thanks again for the answer.

      Comment


      • #4
        However, it is very intriguing to be able to add or replace modules in the runtime without having a need to stop the application.
        Nothing comes for free though - you need to figure out how your application can cope with this situation since the state will not just "migrate" to the next version.

        I am not quite sure what do you mean with "objects", but the answer is yes, probably. We need to use request and session-scoped beans across modules. So it's not only about resources.
        That's what I meant by objects. In this case, you need to asses how modularity will impact your objects. They need to see each other so is there a problem or not if they see everything inside a module.

        "Support for fragments"? It's something new for me. Do you mean Servlet API 3.0 web-fragment.xml or something different?
        I meant OSGi fragments. Take a look at the OSGi spec - it's quite well written and the primary resource (in my opinion) for OSGi info.

        [quote]
        you're in the ball park.
        I'm really sorry, I can't decipher this idiom, may I ask you to rephrase?
        [/quote
        I meant to say your image is "more or less accurate"

        Based on your responses, I think you could start by trying to migrate your solution to OSGi - create a basic POC and take it from there, step by step.

        Comment


        • #5
          Thanks a lot, Costin.
          I think I'll start with a "Hello, World!" application before migrating anything.

          Comment

          Working...
          X