On Thu, Nov 8, 2012 at 3:49 PM, Vincent Massol <[email protected]> wrote:
> > On Nov 8, 2012, at 3:28 PM, Caleb James DeLisle <[email protected]> > wrote: > > > > > > > On 11/08/2012 02:45 AM, Vincent Massol wrote:> Hi Caleb, > >> > >> On Nov 7, 2012, at 2:41 PM, Caleb James DeLisle < > [email protected]> 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 > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs > -- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
