Hi,
2014-03-13 23:12 GMT+02:00 Konstantin Kolinko <knst.koli...@gmail.com>:
>
> 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.
>
That's good to know.
Thanks
Violeta
> 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
>
