Costin Manolache wrote:
Well, there's stuff to do to be able to do that, since Slide is quite complex (and fairly unoptimized). However, it's modular, so modules could be written to embed it (and then we could replace the WebDAV servlet). We'll see how it goes.Remy Maucherat wrote:Costin Manolache wrote:Great !If you could come up with a better name for the "substract" method ;-) It's supposed to be the opposite of append. The optimization works good. It should help WebDAV as well as web services, as long as they use the Tomcat reader.
WebDAV: is there any reason to keep our webdav servlet instead of just
bundling jakarta-slide ? Can jakarta-slide use the tomcat-specific optimizations ( for example using some factory or hook ) ?
I think we could end up packaging it as a module, like other J2EE related components.
Yes, I reckon this isn't too efficient. I'll see what I can do.Hopefully, I'll be able to write the new mapper soon,
My wish list ( if possible ):
- I think the new mapper should be a "global" mapper - i.e. it should
handle all aspects of the mapping, from vhost and aliases, all contexts
and up to the servlet wrapper.
This would allow more optimizations ( a tree or some other tricks ) than
the current chain of 3-4 hashtable mappers ( one for host, one for ctx, one for servlet ).
As for the implementation, a tree would scale better, but a more usual char based "dumb" solution is far simpler, and may perform well enough. I think I'll start with that, and see what OptimizeIt says.
More importantly, I'll try to use the mapper for request dispatcher mapping also, so it can't be too unified (request dispatcher performance isn't too good right now, and mapping is a big part of the problem).
BTW, I'd like to have other developers understand that all String operations are really *bad*, not just concatenation, even trim(), toLowerCase() and other "simpler" operations.
- Add/remove mapping should be propagated via coyote actions - someday jk may intercept the events and inform the native side when a new webapp is added.
Yes, I understand.
The overhead of the Jasper servlet itself is quite low right now. The biggest operation is a hashtable lookup, I think.- there is an interesting optimization in 3.3 - once a jsp is compiled, a prefix mapping is added and the behavior is identical with precompiled jsps ( i.e. no jsp servlet or extra overhead - it is a regular servlet ). ( the reloading checks are a different story - they can be handled by the generated servlet or some other module )
It's a nice trick, though.
Remy
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
