Upayavira wrote:
Sylvain Wallez wrote:
Upayavira wrote:
Jean-Baptiste Quenot wrote:
* Carsten Ziegeler:
Sylvain Wallez schrieb:
Jean-Baptiste can elaborate on this, but AFAIU this is because
an interesting XSP patch requires a servlet listener, which is
something that was added in servlets 2.3.
So, he could just add a mock class for the listener to the xsp
block, add the listener and we are done with this.
Yes, I want to integrate a patch that allows to run an *optional*
component on webapp startup to compile XSP. It's only for
*compilation* that servlet 2.3 is needed, not for runtime, unless
the user explicitly activates in web.xml the optional component
(it's a SessionListener).
Servlet 2.3 will *not* be required to run Cocoon.
A mock sounds like a _much_ better way!
Mocking a 4-year old specification. This is soooo dinosaurish in this
web 2.0 world...
Hmm. If the whole spec is required, I can see where Jean-Baptiste is
coming from. We could extend the build process to use servlet 2.3 for
compilation, but keep the app running with servlet 2.2. Would that
actually cause any backwards compatability issues?
Applications aren't running with the servlet.jar that _we_ provide, as
the servlet API is something that is implemented, and therefore
provided, by the servlet engine.
So our servlet.jar is useful *only* for compilation, and the only
backwards compatibility issue that can happen is when the optional
2.3-specific features are used when Cocoon runs on a servlet engine that
implements servlet 2.2.
If we look at Tomcat, that means using Tomcat 3.3. Are there some people
around using Cocoon 2.1.x on Tomcat 3.3?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://bluxte.net http://www.anyware-tech.com
Apache Software Foundation Member Research & Technology Director
