[xwiki-devs] [PROPOSAL] Allow servlets to be registered with the ComponentManager.
Hi, I'd like to register servlets in the component manager and have them called by their hint. The oldcore struts servlet would be @Named("bin") and the rest servlet would be @Named("rest") Reasons to want to do this: * There are things which are currently impossible without a servlet, things like REST, GWT and WebDav. * If somebody has servlet code and they want to make it run in XWiki, this is a real answer for them whereas "rewrite your app using XWiki actions" isn't. * Even if we had an Actions system which made it *possible* to implement REST, GWT, and WebDav entry points, we would have to rewrite the universe since all external libraries use Servlet. * Web.xml is an eyesore, it's full of content which is the concern only of a particular module, this could (mostly) be fixed by using injected servlets. The big reason not to like it is because it could undermine the proposal for Actions. The JIRA issue for actions http://jira.xwiki.org/browse/XWIKI-4713 was opened on January 1 of 2010. It is stalled because nobody really knows how to make an abstraction which represents Servlets or Portlets without any lost features. If we make it easier for servlets to be used, we might begin down a slippery slope toward everything being done using servlets and then we lose portlet compatibility. But the alternative as I see it is to block progress in this direction and hope that somebody steps up to implement Actions which are fully compatible with portlets and servlets. WDYT? Are there reasons not to do this which I missed? Caleb
Isn't the possibility to inject servlet without having to modiify web.xml part of Servlet 3 ? On Wed, Nov 7, 2012 at 2:41 PM, Caleb James DeLisle < calebdelisle@lavabit.com> wrote:
Hi,
I'd like to register servlets in the component manager and have them called by their hint. The oldcore struts servlet would be @Named("bin") and the rest servlet would be @Named("rest")
Reasons to want to do this: * There are things which are currently impossible without a servlet, things like REST, GWT and WebDav. * If somebody has servlet code and they want to make it run in XWiki, this is a real answer for them whereas "rewrite your app using XWiki actions" isn't. * Even if we had an Actions system which made it *possible* to implement REST, GWT, and WebDav entry points, we would have to rewrite the universe since all external libraries use Servlet. * Web.xml is an eyesore, it's full of content which is the concern only of a particular module, this could (mostly) be fixed by using injected servlets.
The big reason not to like it is because it could undermine the proposal for Actions. The JIRA issue for actions http://jira.xwiki.org/browse/XWIKI-4713 was opened on January 1 of 2010. It is stalled because nobody really knows how to make an abstraction which represents Servlets or Portlets without any lost features. If we make it easier for servlets to be used, we might begin down a slippery slope toward everything being done using servlets and then we lose portlet compatibility. But the alternative as I see it is to block progress in this direction and hope that somebody steps up to implement Actions which are fully compatible with portlets and servlets.
WDYT? Are there reasons not to do this which I missed?
Caleb
_______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
I just looked at some documentation and indeed there is injection based servlet registration. I'm all for using existing standards but there seem to be some issues with this implementation. Until we stop supporting servlets 2.x (tomcat < 7.0) we would need an adapter to support this functionality. Servlets3 supports dynamically loading servlets (ServletContext#add[Servlet|Filter]) but doesn't seem to have a standard way to remove them which would break servlets in extensions. Servlets are loaded at start time by scanning over all class files in the application, I'm not sure how this will be for performance. Unless we used special code in the ECM, servlets would not be able to use dependency injection without explicitly getting the CM itself. Given these limitations I think that for now it makes the most sense to break from the standard and roll our own servlet which redirects to a servlet which is registered as a @Component. Thanks, Caleb On 11/07/2012 08:46 AM, Thomas Mortagne wrote:
Isn't the possibility to inject servlet without having to modiify web.xml part of Servlet 3 ?
On Wed, Nov 7, 2012 at 2:41 PM, Caleb James DeLisle < calebdelisle@lavabit.com> wrote:
Hi,
I'd like to register servlets in the component manager and have them called by their hint. The oldcore struts servlet would be @Named("bin") and the rest servlet would be @Named("rest")
Reasons to want to do this: * There are things which are currently impossible without a servlet, things like REST, GWT and WebDav. * If somebody has servlet code and they want to make it run in XWiki, this is a real answer for them whereas "rewrite your app using XWiki actions" isn't. * Even if we had an Actions system which made it *possible* to implement REST, GWT, and WebDav entry points, we would have to rewrite the universe since all external libraries use Servlet. * Web.xml is an eyesore, it's full of content which is the concern only of a particular module, this could (mostly) be fixed by using injected servlets.
The big reason not to like it is because it could undermine the proposal for Actions. The JIRA issue for actions http://jira.xwiki.org/browse/XWIKI-4713 was opened on January 1 of 2010. It is stalled because nobody really knows how to make an abstraction which represents Servlets or Portlets without any lost features. If we make it easier for servlets to be used, we might begin down a slippery slope toward everything being done using servlets and then we lose portlet compatibility. But the alternative as I see it is to block progress in this direction and hope that somebody steps up to implement Actions which are fully compatible with portlets and servlets.
WDYT? Are there reasons not to do this which I missed?
Caleb
_______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
Hi Caleb, On Nov 7, 2012, at 2:41 PM, Caleb James DeLisle <calebdelisle@lavabit.com> wrote:
Hi,
I'd like to register servlets in the component manager and have them called by their hint. The oldcore struts servlet would be @Named("bin") and the rest servlet would be @Named("rest")
Reasons to want to do this: * There are things which are currently impossible without a servlet, things like REST, GWT and WebDav.
REST and WebDAV for example can be done without needing a new Servlet by using a tighter integration. I don't know enough about GWT to know if it's possible or not but I guess it is too (at the expense or writing a bit more code since you'll need to call some GWT APIs to do serialization/deserialization).
* If somebody has servlet code and they want to make it run in XWiki, this is a real answer for them whereas "rewrite your app using XWiki actions" isn't.
Indeed, and we've been waiting for Servlet 3.0 so far. Last time we checked it was still to early to use Servlet 3.0 (see threads on markmail).
* Even if we had an Actions system which made it *possible* to implement REST, GWT, and WebDav entry points, we would have to rewrite the universe since all external libraries use Servlet. * Web.xml is an eyesore, it's full of content which is the concern only of a particular module, this could (mostly) be fixed by using injected servlets.
Indeed and Servlet 3.0 seems a good answer. Now you're right that Servlet 3.0 doesn't support dynamic unregistration of Servlets (only addition) so if we want to bring in servlets in an extension that's not possible. This is also why I prefer the tight integration approach which doesn't have this problem (i.e. do away with Servlets).
The big reason not to like it is because it could undermine the proposal for Actions. The JIRA issue for actions http://jira.xwiki.org/browse/XWIKI-4713 was opened on January 1 of 2010. It is stalled because nobody really knows how to make an abstraction which represents Servlets or Portlets without any lost features.
I started the Action module and I didn't finish simply for lack of time. There's no blocker. I wanted to finish the URL module before working on it again but I didn't get the time to finish it either.
If we make it easier for servlets to be used, we might begin down a slippery slope toward everything being done using servlets and then we lose portlet compatibility. But the alternative as I see it is to block progress in this direction and hope that somebody steps up to implement Actions which are fully compatible with portlets and servlets.
My take on Servlets within XWiki in general: * We should not use Servlets when there are other ways of integrating external tools. When possible a tighter integration should be chosen since it allows to use our development practices with component injection and makes it simpler for deployment (removes the burden to have to modify web.xml). * Another reason for having only 1 entry point (or a minimal number of entry points) is that defining more entry points is a pain for maintenance as we've been experiencing over and over for the past years. The problem is that a new entry point means that you need to duplicate all initialization of XWiki Context/Execution context for each incoming request and this is tricky and all our entry points were doing it wrongly at some point (case in point, Andreas just fixed 2 bugs yesterday where some threads were not cloning the xwiki context). Yes we should be able to factor all this init in a common place (which we almost have but in practice it doesn't seem to really happen for some reason). Regarding your proposal: * It seems a bit of hack to call a Servlet by doing a new on it. It goes against the concept of Servlets actually which is supposed to be handled by the Container. More generally what you propose is what OSGi is doing too: - http://www.peterfriese.de/osgi-servlets-a-happy-marriage/ - http://felix.apache.org/site/apache-felix-http-service.html The real questions for me are: 1/ Could you explain what's your actual use case so that we could discuss alternatives, if any? 2/ Do we really want to support adding/removing servlets at runtime? If the answer to 2/ is yes then your proposal is the only one I could see working indeed. Regarding @Named("bin"), I think it would be good to review all our existing URLs and verify it'll work. For example ATM we also have "skin" and "skins" AFAIR which are currently handled by the same Servlet as "bin" and thus we'd need to find a solution for this too + we need to review the GWT, WebDAV URLs too. It would also be nice for the xwiki URL module to be able to handle different URL formats based on the "servlet/service" instead of the scheme being fixed for all which is currently the case. Thanks -Vincent
WDYT? Are there reasons not to do this which I missed?
Caleb
On 11/08/2012 02:45 AM, Vincent Massol wrote:> Hi Caleb,
On Nov 7, 2012, at 2:41 PM, Caleb James DeLisle <calebdelisle@lavabit.com> wrote:
Hi,
I'd like to register servlets in the component manager and have them called by their hint. The oldcore struts servlet would be @Named("bin") and the rest servlet would be @Named("rest")
Reasons to want to do this: * There are things which are currently impossible without a servlet, things like REST, GWT and WebDav.
REST and WebDAV for example can be done without needing a new Servlet by using a tighter integration. I don't know enough about GWT to know if it's possible or not but I guess it is too (at the expense or writing a bit more code since you'll need to call some GWT APIs to do serialization/deserialization).
There is the expense of porting REST, GWT and WebDav servlets and maintaining those ports, also if we want to use WebSocket, JsonP or other comet solutions (which I think could give us a big performance boost) we need to port those libraries too and since they have to do some clever things with the servlet, we might find that they use features which are simply unavailable in our abstraction layer. Why make all of the work?
* If somebody has servlet code and they want to make it run in XWiki, this is a real answer for them whereas "rewrite your app using XWiki actions" isn't.
Indeed, and we've been waiting for Servlet 3.0 so far. Last time we checked it was still to early to use Servlet 3.0 (see threads on markmail).
* Even if we had an Actions system which made it *possible* to implement REST, GWT, and WebDav entry points, we would have to rewrite the universe since all external libraries use Servlet. * Web.xml is an eyesore, it's full of content which is the concern only of a particular module, this could (mostly) be fixed by using injected servlets.
Indeed and Servlet 3.0 seems a good answer.
Now you're right that Servlet 3.0 doesn't support dynamic unregistration of Servlets (only addition) so if we want to bring in servlets in an extension that's not possible. This is also why I prefer the tight integration approach which doesn't have this problem (i.e. do away with Servlets).
The big reason not to like it is because it could undermine the proposal for Actions. The JIRA issue for actions http://jira.xwiki.org/browse/XWIKI-4713 was opened on January 1 of 2010. It is stalled because nobody really knows how to make an abstraction which represents Servlets or Portlets without any lost features.
I started the Action module and I didn't finish simply for lack of time. There's no blocker. I wanted to finish the URL module before working on it again but I didn't get the time to finish it either.
If we make it easier for servlets to be used, we might begin down a slippery slope toward everything being done using servlets and then we lose portlet compatibility. But the alternative as I see it is to block progress in this direction and hope that somebody steps up to implement Actions which are fully compatible with portlets and servlets.
My take on Servlets within XWiki in general: * We should not use Servlets when there are other ways of integrating external tools. When possible a tighter integration should be chosen since it allows to use our development practices with component injection and makes it simpler for deployment (removes the burden to have to modify web.xml). * Another reason for having only 1 entry point (or a minimal number of entry points) is that defining more entry points is a pain for maintenance as we've been experiencing over and over for the past years. The problem is that a new entry point means that you need to duplicate all initialization of XWiki Context/Execution context for each incoming request and this is tricky and all our entry points were doing it wrongly at some point (case in point, Andreas just fixed 2 bugs yesterday where
some threads were not cloning the xwiki context). Yes we should be able to factor all this init in a common place (which we almost have but in practice it doesn't seem to really happen for some reason). This sounds like a major problem for "just use servlet3" answer unless we were to offer a generic initXWiki() function which everybody's servlets could call. My proposal is to write our own servlet which redirects to the user's servlet and it can do the necessary initialization (although I hope we can minimize that initialization to improve performance).
Regarding your proposal: * It seems a bit of hack to call a Servlet by doing a new on it. It goes against the concept of Servlets actually which is supposed to be handled by the Container. More generally what you propose is what OSGi is doing too: - http://www.peterfriese.de/osgi-servlets-a-happy-marriage/ - http://felix.apache.org/site/apache-felix-http-service.html
The real questions for me are: 1/ Could you explain what's your actual use case so that we could discuss alternatives, if any?
Take the realtime editor, right now it uses the GWT RPC by loading a module which implements the GWT service and it picked up by the GWT servlet. I want it to use websocket if available or fall back on flashsocket, jsonp, or long polling. There is a library to do this called Atmosphere, it uses a servlet and detects what the container and browser supports and uses what it can. I want to include this but I want it to be an extension because everything should be an extension for the sake of modularity.
2/ Do we really want to support adding/removing servlets at runtime?
"Everything should be an extension" and "extensions can be loaded at runtime" make it a yes.
If the answer to 2/ is yes then your proposal is the only one I could see working indeed.
Regarding @Named("bin"), I think it would be good to review all our existing URLs and verify it'll work. For example ATM we also have "skin" and "skins" AFAIR which are currently handled by the same Servlet as "bin" and thus we'd need to find a solution for this too + we need to review the GWT, WebDAV URLs too.
There are a number of URL parts which redirect to the "bin" servlet and there are also some other funny URL matchers, I think the best thing to do in this case is to use either web.xml hackery or a request filter which is explicitly pulled in from web.xml but comment it and say it is deprecated and nobody should be doing this.
It would also be nice for the xwiki URL module to be able to handle different URL formats based on the "servlet/service" instead of the scheme being fixed for all which is currently the case.
I suppose there's nothing really stopping us from using a pluggable URL handler once the request enters the "ServletRedirectorServlet" as I propose, I don't think it's a very good idea because I suspect that changing the URL scheme would cause weird issues all throughout the code and which would take time to resolve and while it's kind of nice to be able to arbitrarily change the URL scheme, it doesn't bring the user any major features. Thanks Caleb
Thanks -Vincent
WDYT? Are there reasons not to do this which I missed?
Caleb
_______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
On Nov 8, 2012, at 3:28 PM, Caleb James DeLisle <calebdelisle@lavabit.com> wrote:
On 11/08/2012 02:45 AM, Vincent Massol wrote:> Hi Caleb,
On Nov 7, 2012, at 2:41 PM, Caleb James DeLisle <calebdelisle@lavabit.com> wrote:
Hi,
I'd like to register servlets in the component manager and have them called by their hint. The oldcore struts servlet would be @Named("bin") and the rest servlet would be @Named("rest")
Reasons to want to do this: * There are things which are currently impossible without a servlet, things like REST, GWT and WebDav.
REST and WebDAV for example can be done without needing a new Servlet by using a tighter integration. I don't know enough about GWT to know if it's possible or not but I guess it is too (at the expense or writing a bit more code since you'll need to call some GWT APIs to do serialization/deserialization).
There is the expense of porting REST, GWT and WebDav servlets and maintaining those ports, also if we want to use WebSocket, JsonP or other comet solutions (which I think could give us a big performance boost) we need to port those libraries too and since they have to do some clever things with the servlet, we might find that they use features which are simply unavailable in our abstraction layer. Why make all of the work?
Yes, obviously, this solution works best when the underlying frameworks are meant to be embeddable as otherwise there's too much code to write/maintain. Note that using Servlets means we cannot use component injection and we have to use the, currently deprecated and static Utils.getComponent() APIs. If we go this way we should definitely provide a generic AbstractXWikiServlet which does initialization and allow getting the component manager.
* If somebody has servlet code and they want to make it run in XWiki, this is a real answer for them whereas "rewrite your app using XWiki actions" isn't.
Indeed, and we've been waiting for Servlet 3.0 so far. Last time we checked it was still to early to use Servlet 3.0 (see threads on markmail).
* Even if we had an Actions system which made it *possible* to implement REST, GWT, and WebDav entry points, we would have to rewrite the universe since all external libraries use Servlet. * Web.xml is an eyesore, it's full of content which is the concern only of a particular module, this could (mostly) be fixed by using injected servlets.
Indeed and Servlet 3.0 seems a good answer.
Now you're right that Servlet 3.0 doesn't support dynamic unregistration of Servlets (only addition) so if we want to bring in servlets in an extension that's not possible. This is also why I prefer the tight integration approach which doesn't have this problem (i.e. do away with Servlets).
The big reason not to like it is because it could undermine the proposal for Actions. The JIRA issue for actions http://jira.xwiki.org/browse/XWIKI-4713 was opened on January 1 of 2010. It is stalled because nobody really knows how to make an abstraction which represents Servlets or Portlets without any lost features.
I started the Action module and I didn't finish simply for lack of time. There's no blocker. I wanted to finish the URL module before working on it again but I didn't get the time to finish it either.
If we make it easier for servlets to be used, we might begin down a slippery slope toward everything being done using servlets and then we lose portlet compatibility. But the alternative as I see it is to block progress in this direction and hope that somebody steps up to implement Actions which are fully compatible with portlets and servlets.
My take on Servlets within XWiki in general: * We should not use Servlets when there are other ways of integrating external tools. When possible a tighter integration should be chosen since it allows to use our development practices with component injection and makes it simpler for deployment (removes the burden to have to modify web.xml). * Another reason for having only 1 entry point (or a minimal number of entry points) is that defining more entry points is a pain for maintenance as we've been experiencing over and over for the past years. The problem is that a new entry point means that you need to duplicate all initialization of XWiki Context/Execution context for each incoming request and this is tricky and all our entry points were doing it wrongly at some point (case in point, Andreas just fixed 2 bugs yesterday where some threads were not cloning the xwiki context). Yes we should be able to factor all this init in a common place (which we almost have but in practice it doesn't seem to really happen for some reason).
This sounds like a major problem for "just use servlet3" answer unless we were to offer a generic initXWiki() function which everybody's servlets could call. My proposal is to write our own servlet which redirects to the user's servlet and it can do the necessary initialization (although I hope we can minimize that initialization to improve performance).
I assume that by "redirect" you don't mean a servlet redirect but you mean doing a new MyServlet() and simulating a call to service()?
Regarding your proposal: * It seems a bit of hack to call a Servlet by doing a new on it. It goes against the concept of Servlets actually which is supposed to be handled by the Container. More generally what you propose is what OSGi is doing too: - http://www.peterfriese.de/osgi-servlets-a-happy-marriage/ - http://felix.apache.org/site/apache-felix-http-service.html
The real questions for me are: 1/ Could you explain what's your actual use case so that we could discuss alternatives, if any?
Take the realtime editor, right now it uses the GWT RPC by loading a module which implements the GWT service and it picked up by the GWT servlet. I want it to use websocket if available or fall back on flashsocket, jsonp, or long polling. There is a library to do this called Atmosphere, it uses a servlet and detects what the container and browser supports and uses what it can. I want to include this but I want it to be an extension because everything should be an extension for the sake of modularity.
Indeed if possible it would be nice.
2/ Do we really want to support adding/removing servlets at runtime?
"Everything should be an extension" and "extensions can be loaded at runtime" make it a yes.
As much as possible indeed.
If the answer to 2/ is yes then your proposal is the only one I could see working indeed.
Regarding @Named("bin"), I think it would be good to review all our existing URLs and verify it'll work. For example ATM we also have "skin" and "skins" AFAIR which are currently handled by the same Servlet as "bin" and thus we'd need to find a solution for this too + we need to review the GWT, WebDAV URLs too.
There are a number of URL parts which redirect to the "bin" servlet and there are also some other funny URL matchers, I think the best thing to do in this case is to use either web.xml hackery or a request filter which is explicitly pulled in from web.xml but comment it and say it is deprecated and nobody should be doing this.
It would also be nice for the xwiki URL module to be able to handle different URL formats based on the "servlet/service" instead of the scheme being fixed for all which is currently the case.
I suppose there's nothing really stopping us from using a pluggable URL handler once the request enters the "ServletRedirectorServlet" as I propose, I don't think it's a very good idea because I suspect that changing the URL scheme would cause weird issues all throughout the code and which would take time to resolve and while it's kind of nice to be able to arbitrarily change the URL scheme, it doesn't bring the user any major features.
There are 2 aspects: - letting the user control his URLs. this is a much requested feature. This is what is currently implemented in the url module. - handling cases when we don't control the URL because it's controlled by some 3rd party framework for example or simply because webdav doesn't have the same url scheme as xwiki's REST API for ex. So we need to have one url scheme per "servlet". This is not currently supported by the URL module AFAIR. Now there might be some gotchas. For example a lot of servlets require to be configured through parameters in web.xml so this means we would still need to be able to edit web.xml and thus not support proper extensions. We could of course define those on the main servlet with some specific key syntax but it doesn't remove the need to declare them. Actually, we can probably simulate this too by taking the configuration by using our own Configuration module and bridging with the Servlet api… We would need to be able to simulate ServletContext.getInitParameter() for example. I guess we can do this with a WrappingServletContext :) In any case since OSGi is doing this I guess it's doable. I hope there are no real gotchas… I'm warming up more and more on this proposal Caleb :) Thanks -Vincent
Thanks Caleb
Thanks -Vincent
WDYT? Are there reasons not to do this which I missed?
Caleb
On Thu, Nov 8, 2012 at 3:49 PM, Vincent Massol <vincent@massol.net> wrote:
On Nov 8, 2012, at 3:28 PM, Caleb James DeLisle <calebdelisle@lavabit.com> wrote:
On 11/08/2012 02:45 AM, Vincent Massol wrote:> Hi Caleb,
On Nov 7, 2012, at 2:41 PM, Caleb James DeLisle <
calebdelisle@lavabit.com> wrote:
Hi,
I'd like to register servlets in the component manager and have them
called by their hint.
The oldcore struts servlet would be @Named("bin") and the rest servlet would be @Named("rest")
Reasons to want to do this: * There are things which are currently impossible without a servlet, things like REST, GWT and WebDav.
REST and WebDAV for example can be done without needing a new Servlet by using a tighter integration. I don't know enough about GWT to know if it's possible or not but I guess it is too (at the expense or writing a bit more code since you'll need to call some GWT APIs to do serialization/deserialization).
There is the expense of porting REST, GWT and WebDav servlets and maintaining those ports, also if we want to use WebSocket, JsonP or other comet solutions (which I think could give us a big performance boost) we need to port those libraries too and since they have to do some clever things with the servlet, we might find that they use features which are simply unavailable in our abstraction layer. Why make all of the work?
Yes, obviously, this solution works best when the underlying frameworks are meant to be embeddable as otherwise there's too much code to write/maintain.
Note that using Servlets means we cannot use component injection and we have to use the, currently deprecated and static Utils.getComponent() APIs.
Well not exactly, the ComponentManager is supposed to be stored in the application context so any Servlet can use that as entry point, no need for Utils.getComponent().
If we go this way we should definitely provide a generic AbstractXWikiServlet which does initialization and allow getting the component manager.
* If somebody has servlet code and they want to make it run in XWiki, this is a real answer for them whereas "rewrite your app using XWiki actions" isn't.
Indeed, and we've been waiting for Servlet 3.0 so far. Last time we checked it was still to early to use Servlet 3.0 (see threads on markmail).
* Even if we had an Actions system which made it *possible* to implement REST, GWT, and WebDav entry points, we would have to rewrite the universe since all external libraries use Servlet. * Web.xml is an eyesore, it's full of content which is the concern only of a particular module, this could (mostly) be fixed by using injected servlets.
Indeed and Servlet 3.0 seems a good answer.
Now you're right that Servlet 3.0 doesn't support dynamic unregistration of Servlets (only addition) so if we want to bring in servlets in an extension that's not possible. This is also why I prefer the tight integration approach which doesn't have this problem (i.e. do away with Servlets).
The big reason not to like it is because it could undermine the proposal for Actions. The JIRA issue for actions http://jira.xwiki.org/browse/XWIKI-4713was opened on January 1 of 2010. It is stalled because nobody really knows how to make an abstraction which represents Servlets or Portlets without any lost features.
I started the Action module and I didn't finish simply for lack of time. There's no blocker. I wanted to finish the URL module before working on it again but I didn't get the time to finish it either.
If we make it easier for servlets to be used, we might begin down a slippery slope toward everything being done using servlets and then we lose portlet compatibility. But the alternative as I see it is to block progress in this direction and hope that somebody steps up to implement Actions which are fully compatible with portlets and servlets.
My take on Servlets within XWiki in general: * We should not use Servlets when there are other ways of integrating external tools. When possible a tighter integration should be chosen since it allows to use our development practices with component injection and makes it simpler for deployment (removes the burden to have to modify web.xml). * Another reason for having only 1 entry point (or a minimal number of entry points) is that defining more entry points is a pain for maintenance as we've been experiencing over and over for the past years. The problem is that a new entry point means that you need to duplicate all initialization of XWiki Context/Execution context for each incoming request and this is tricky and all our entry points were doing it wrongly at some point (case in point, Andreas just fixed 2 bugs yesterday where some threads were not cloning the xwiki context). Yes we should be able to factor all this init in a common place (which we almost have but in practice it doesn't seem to really happen for some reason).
This sounds like a major problem for "just use servlet3" answer unless we were to offer a generic initXWiki() function which everybody's servlets could call. My proposal is to write our own servlet which redirects to the user's servlet and it can do the necessary initialization (although I hope we can minimize that initialization to improve performance).
I assume that by "redirect" you don't mean a servlet redirect but you mean doing a new MyServlet() and simulating a call to service()?
Regarding your proposal: * It seems a bit of hack to call a Servlet by doing a new on it. It goes against the concept of Servlets actually which is supposed to be handled by the Container. More generally what you propose is what OSGi is doing too: - http://www.peterfriese.de/osgi-servlets-a-happy-marriage/ - http://felix.apache.org/site/apache-felix-http-service.html
The real questions for me are: 1/ Could you explain what's your actual use case so that we could discuss alternatives, if any?
Take the realtime editor, right now it uses the GWT RPC by loading a module which implements the GWT service and it picked up by the GWT servlet. I want it to use websocket if available or fall back on flashsocket, jsonp, or long polling. There is a library to do this called Atmosphere, it uses a servlet and detects what the container and browser supports and uses what it can. I want to include this but I want it to be an extension because everything should be an extension for the sake of modularity.
Indeed if possible it would be nice.
2/ Do we really want to support adding/removing servlets at runtime?
"Everything should be an extension" and "extensions can be loaded at runtime" make it a yes.
As much as possible indeed.
If the answer to 2/ is yes then your proposal is the only one I could see working indeed.
Regarding @Named("bin"), I think it would be good to review all our existing URLs and verify it'll work. For example ATM we also have "skin" and "skins" AFAIR which are currently handled by the same Servlet as "bin" and thus we'd need to find a solution for this too + we need to review the GWT, WebDAV URLs too.
There are a number of URL parts which redirect to the "bin" servlet and there are also some other funny URL matchers, I think the best thing to do in this case is to use either web.xml hackery or a request filter which is explicitly pulled in from web.xml but comment it and say it is deprecated and nobody should be doing this.
It would also be nice for the xwiki URL module to be able to handle
different URL formats based on the "servlet/service" instead of the scheme being fixed for all which is currently the case.
I suppose there's nothing really stopping us from using a pluggable URL handler once the request enters the "ServletRedirectorServlet" as I propose, I don't think it's a very good idea because I suspect that changing the URL scheme would cause weird issues all throughout the code and which would take time to resolve and while it's kind of nice to be able to arbitrarily change the URL scheme, it doesn't bring the user any major features.
There are 2 aspects: - letting the user control his URLs. this is a much requested feature. This is what is currently implemented in the url module. - handling cases when we don't control the URL because it's controlled by some 3rd party framework for example or simply because webdav doesn't have the same url scheme as xwiki's REST API for ex. So we need to have one url scheme per "servlet". This is not currently supported by the URL module AFAIR.
Now there might be some gotchas. For example a lot of servlets require to be configured through parameters in web.xml so this means we would still need to be able to edit web.xml and thus not support proper extensions. We could of course define those on the main servlet with some specific key syntax but it doesn't remove the need to declare them. Actually, we can probably simulate this too by taking the configuration by using our own Configuration module and bridging with the Servlet api… We would need to be able to simulate ServletContext.getInitParameter() for example. I guess we can do this with a WrappingServletContext :)
In any case since OSGi is doing this I guess it's doable. I hope there are no real gotchas…
I'm warming up more and more on this proposal Caleb :)
Thanks -Vincent
Thanks Caleb
Thanks -Vincent
WDYT? Are there reasons not to do this which I missed?
Caleb
devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
participants (3)
-
Caleb James DeLisle -
Thomas Mortagne -
Vincent Massol