2014-03-13 16:28 GMT+04:00 Violeta Georgieva <miles...@gmail.com>:
> Hi,
>
> In OSGi world the functionality is separated in different bundles and
> schemes for servlet API is in one bundle and schemes for JSP API in
> another.
> With that change we pack all schemes in servlet-api.jar. Till this changed
> one was able to use whatever servlet api bundle compatible with Tomcat but
> with that change we enforce people to use only the jar provided by Tomcat
> which is not a bundle also.
>
> Is it possible to return back the check with JSPContext? Something like
> this?
>
> Till this changed
> one was able to use whatever servlet api bundle compatible with Tomcat
It is container's responsibility to provide the servlet API jar, and
I think the said jar can have whatever hard ties with container's
internals.
An application can use whatever 3rd party servlet.jar implementation
at compile time, but at run time it has to use the container-provided
one.
For example, Cookie.java relies on certain configuration properties
defined by Tomcat documentation to provide secure and
specification-compliant behaviour. You cannot swap that
implementation with random other.
Apparently there are a ways to bypass Tomcat's enforcement of
specification compliance wrt. where servlet-api.jar comes from. E.g.
if one places a rogue jar into $CLASSPATH or into ${catalina.base}/lib
or into endorsed directory, or into JRE. I think it is good that we
can uncover such broken configurations.
E.g.
https://issues.apache.org/bugzilla/show_bug.cgi?id=56236
If you want to break dependency of DigesterFactory on this specific
implementation of ServletContext, it is possible to copy schemas into
the same jar where DigesterFactory.class is. But I see no need for
that, and I think that such a change would make the things worse.
Best regards,
Konstantin Kolinko
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
