Jose Noheda:
Hi,
I'm not sure I've understood completely. Here's more or less what I'm imaging:
You have several DwrSpringServlets each one with a Spring application context injected.
You have several DwrServlets each with some remoted objects
Each servlet is mapped to a different URL
You have some kind of servlet that redirects (filter that forwards?) the processing to the correct servlet (I don't really understand why)
You need that DWR supports internally the handling of many servlets and/or different kind of configurations with one entry point
Can you clarify if that's correct? I would really need an example web.xml with three or so servlet definitions (and mappings) and one sample flow (of a client call).
Regards,
Jan Novotny:
Hello,
You are correct in most of points. I realized, that I omit to
mention that in web.xml there is only one registered servlet. As I
wrote application is assembled in runtime - so you can enable /
disable certain modules without restarting webapp context and
application will respond immediately.
It means, that our servlet must somehow react on live application
reassembly, free internal pool of servlets and initialize new ones for
current application assembly.
Web.xml part example:
<servlet>
<servlet-name>dwr-invoker</servlet-name>
<display-name>DWR Servlet</display-name>
<servlet-class>com.fg.webapp.cps.v1.modules.dwr.DwrDelegationServlet</servlet-class>
<init-param>
<param-name>debug</param-name>
<param-value>true</param-value>
</init-param>
</servlet>
<servlet-mapping>
<servlet-name>dwr-invoker</servlet-name>
<url-pattern>/dwr/*</url-pattern>
</servlet-mapping>
Then I could call:
http://server/context/dwr/moduleA_Id/
And I expect that DWR will display debug page containing
description of AJAX API of my module A
http://server/context/dwr/moduleB_Id/
And I expect that DWR will display debug page containing
description of AJAX API of my module B
BTW: these urls would trigger the issue with redirect, because
when accessing debug page in this way DWR calls redirect to different
internal url that really shows the debug page ...
Then imagine, that I will disable moduleA and enable moduleC at
runtime. Spring gets refreshed, my DwrDelegationServlet get notifiead
about it too, and reinitializes its own pool of DWR servlets (means
its containers). Then when I try to access:
http://server/context/dwr/moduleA_Id/
I will get HTTP 404
but when accessing
http://server/context/dwr/moduleC_Id/
I expect correct debug page of moduleC AJAX API
Did I make it more clear by this description?
Jose Noheda:
Hi,
It's a little bit complicated.
I could think of a solution for the Spring part. We could modify the DwrSpringServlet and SpringContainer so they accept a collection of application contexts instead of just one. That would reduce the number of servlets. Then we would need to add hot configuration capabilities to add or remove contexts during runtime. The first task is more or less easy. The second is not.
But even then you would have to keep your frontend servlet and all the DwrServlets plus this servlet with the Spring configuration. All in all, you haven't advanced that much. That means that the problem spans well beyond the Spring configuration so unless Joe considers it important enough...I see it difficult.
If you are interested just in the Spring side create a Jira issue attaching a sample project (I wouldn't be able to replicate your environment really) and I'll take a look at it.
Regards,
Jan Novotný:
I propose slightly different approach and that is - one more level
of abstraction. If you look at the Servlet code (DwrServlet and
DwrSpringServlet) there is a lot of code that could be united and
reused. What about introducing something like ContainerManager, that
would take care of Dwr containers initialization and other operations
connected with the container ... then there could be much simplier
servlets, that woud be furthermore better extensible / changeable with
custom servlets just because there would be no bigger logic in them.
Please see attached Java classes - please, and keep in mind, that
this is only a proposal - it might not word in this state - I wrote it
just to outline solution. While writing this abstraction I realized,
that existing servlet might not behave the same - for example shutdown
hook killing comet polls was only inside DwrServlet but not in
DwrSpringServlet. So I think, that this abstraction could moreover
facilitate keeping servlet logic in sync.
If described approach is in the DWR, I could easily write my own
servlet maintaining set of different ContainerManagers even combining
Spring ones with Default ones without any problem. Internal logic is
in ContainerManagers so that I would not have to fear that I will
break anything. So first part of my problem would have been solved by
this.
What do you say to this proposal?
The second part connected with sending http redirect form inside
UrlProcessor is harder to solve. Could there be any interceptor or
UrlPaths resolver, that would abstract this?
Improvement
Open
Minor
Jose Noheda:
Hi,
I'm not sure I've understood completely. Here's more or less what I'm imaging:
You have several DwrSpringServlets each one with a Spring application context injected.
You have several DwrServlets each with some remoted objects
Each servlet is mapped to a different URL
You have some kind of servlet that redirects (filter that forwards?) the processing to the correct servlet (I don't really understand why)
You need that DWR supports internally the handling of many servlets and/or different kind of configurations with one entry point
Can you clarify if that's correct? I would really need an example web.xml with three or so servlet definitions (and mappings) and one sample flow (of a client call).
Regards,
Jan Novotny:
Hello,
You are correct in most of points. I realized, that I omit to
mention that in web.xml there is only one registered servlet. As I
wrote application is assembled in runtime - so you can enable /
disable certain modules without restarting webapp context and
application will respond immediately.
It means, that our servlet must somehow react on live application
reassembly, free internal pool of servlets and initialize new ones for
current application assembly.
Web.xml part example:
<servlet>
<servlet-name>dwr-invoker</servlet-name>
<display-name>DWR Servlet</display-name>
<servlet-class>com.fg.webapp.cps.v1.modules.dwr.DwrDelegationServlet</servlet-class>
<init-param>
<param-name>debug</param-name>
<param-value>true</param-value>
</init-param>
</servlet>
<servlet-mapping>
<servlet-name>dwr-invoker</servlet-name>
<url-pattern>/dwr/*</url-pattern>
</servlet-mapping>
Then I could call:
http://server/context/dwr/moduleA_Id/
And I expect that DWR will display debug page containing
description of AJAX API of my module A
http://server/context/dwr/moduleB_Id/
And I expect that DWR will display debug page containing
description of AJAX API of my module B
BTW: these urls would trigger the issue with redirect, because
when accessing debug page in this way DWR calls redirect to different
internal url that really shows the debug page ...
Then imagine, that I will disable moduleA and enable moduleC at
runtime. Spring gets refreshed, my DwrDelegationServlet get notifiead
about it too, and reinitializes its own pool of DWR servlets (means
its containers). Then when I try to access:
http://server/context/dwr/moduleA_Id/
I will get HTTP 404
but when accessing
http://server/context/dwr/moduleC_Id/
I expect correct debug page of moduleC AJAX API
Did I make it more clear by this description?
Jose Noheda:
Hi,
It's a little bit complicated.
I could think of a solution for the Spring part. We could modify the DwrSpringServlet and SpringContainer so they accept a collection of application contexts instead of just one. That would reduce the number of servlets. Then we would need to add hot configuration capabilities to add or remove contexts during runtime. The first task is more or less easy. The second is not.
But even then you would have to keep your frontend servlet and all the DwrServlets plus this servlet with the Spring configuration. All in all, you haven't advanced that much. That means that the problem spans well beyond the Spring configuration so unless Joe considers it important enough...I see it difficult.
If you are interested just in the Spring side create a Jira issue attaching a sample project (I wouldn't be able to replicate your environment really) and I'll take a look at it.
Regards,
Jan Novotný:
I propose slightly different approach and that is - one more level
of abstraction. If you look at the Servlet code (DwrServlet and
DwrSpringServlet) there is a lot of code that could be united and
reused. What about introducing something like ContainerManager, that
would take care of Dwr containers initialization and other operations
connected with the container ... then there could be much simplier
servlets, that woud be furthermore better extensible / changeable with
custom servlets just because there would be no bigger logic in them.
Please see attached Java classes - please, and keep in mind, that
this is only a proposal - it might not word in this state - I wrote it
just to outline solution. While writing this abstraction I realized,
that existing servlet might not behave the same - for example shutdown
hook killing comet polls was only inside DwrServlet but not in
DwrSpringServlet. So I think, that this abstraction could moreover
facilitate keeping servlet logic in sync.
If described approach is in the DWR, I could easily write my own
servlet maintaining set of different ContainerManagers even combining
Spring ones with Default ones without any problem. Internal logic is
in ContainerManagers so that I would not have to fear that I will
break anything. So first part of my problem would have been solved by
this.
What do you say to this proposal?
The second part connected with sending http redirect form inside
UrlProcessor is harder to solve. Could there be any interceptor or
UrlPaths resolver, that would abstract this?