DWR

Hassle using DWR in modular web applications

Details

  • Type: Improvement Improvement
  • Status: Open Open
  • Priority: Minor Minor
  • Resolution: Unresolved
  • Affects Version/s: 2.0.2
  • Fix Version/s: 3.0.1
  • Component/s: Core
  • Description:
    Hide
    This issue is continuation of thread in user mailing list. Just to recapitulate:

    I submited an issue DWR-174 (
    http://getahead.org/bugs/browse/DWR-174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
    ) that is resolved by now - but only in its easiest way. I would like
    to propose more general solution, but that means some discussion in
    advance.

    I will describe the situation we have in our projects. We build
    modular web systems in which we use DWR for AJAX. Most of our modules
    are based on Spring nowadays and are assembled together at runtime
    leveraging hierarchical tree of Spring application contexts.

    We want to provide AJAX support for each module and the problem is as follows:

    * each module has to have its own namespace (in Spring it is ensured
    by having application context for each module) - in DWR it means it
    has to have its own SpringContainer for each module configured in
    comformity with its Spring app context
    * DWR requests has to furthermore analyzed to select appropriate
    target module - this could be easily done by parsing requestPath - but
    the problem is DWR could make its own redirects that will break url
    logic
    * to support older modules we have to provide DWR support using
    standard DefaultContainer

    We have implemented a solution to this, but it could be hardly called
    clean. It involves using custom servlet that internally holds pool of
    DwrServlets and DwrSpringServlets and that performs the selection
    logic and delegates servlet processing onto chosen dwr servlet.

    Additionally there has been problems with redirects executed inside
    Dwr UrlProcessors - to address this issue we had to wrap HttpRequest
    to imitate correct request url (namely overriding getPathInfo() and
    getServletPath() method) in order to ensure all fired redirects will
    contain url with module selectors in path we use in delegation servlet
    to select appropriate DWR delegate.

    I hope I described the matter compherensible and I wonder whether we
    are alone or whether there is anybody fighting the same.

    Do you thing there is a chance to have this issue addresed by the DWR
    library itself? Waht it would involve?
    Show
    This issue is continuation of thread in user mailing list. Just to recapitulate: I submited an issue DWR-174 ( http://getahead.org/bugs/browse/DWR-174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ) that is resolved by now - but only in its easiest way. I would like to propose more general solution, but that means some discussion in advance. I will describe the situation we have in our projects. We build modular web systems in which we use DWR for AJAX. Most of our modules are based on Spring nowadays and are assembled together at runtime leveraging hierarchical tree of Spring application contexts. We want to provide AJAX support for each module and the problem is as follows: * each module has to have its own namespace (in Spring it is ensured by having application context for each module) - in DWR it means it has to have its own SpringContainer for each module configured in comformity with its Spring app context * DWR requests has to furthermore analyzed to select appropriate target module - this could be easily done by parsing requestPath - but the problem is DWR could make its own redirects that will break url logic * to support older modules we have to provide DWR support using standard DefaultContainer We have implemented a solution to this, but it could be hardly called clean. It involves using custom servlet that internally holds pool of DwrServlets and DwrSpringServlets and that performs the selection logic and delegates servlet processing onto chosen dwr servlet. Additionally there has been problems with redirects executed inside Dwr UrlProcessors - to address this issue we had to wrap HttpRequest to imitate correct request url (namely overriding getPathInfo() and getServletPath() method) in order to ensure all fired redirects will contain url with module selectors in path we use in delegation servlet to select appropriate DWR delegate. I hope I described the matter compherensible and I wonder whether we are alone or whether there is anybody fighting the same. Do you thing there is a chance to have this issue addresed by the DWR library itself? Waht it would involve?
  1. AbstractDwrServlet.java
    (2 kB)
    Jan Novotný
    20/Feb/08 12:20 PM
  2. DefaultContainerManager.java
    (5 kB)
    Jan Novotný
    20/Feb/08 12:20 PM
  3. DwrServlet.java
    (2 kB)
    Jan Novotný
    20/Feb/08 12:20 PM
  4. DwrSpringServlet.java
    (3 kB)
    Jan Novotný
    20/Feb/08 12:20 PM
  5. SpringContainerManager.java
    (3 kB)
    Jan Novotný
    20/Feb/08 12:20 PM

Activity

People

Dates

  • Created:
    20/Feb/08 12:16 PM
    Updated:
    13/Apr/11 12:09 PM