You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Violeta Georgieva <mi...@gmail.com> on 2014/03/13 13:28:28 UTC
Re: svn commit: r1560931 - in /tomcat/tc7.0.x/trunk: build.xml java/org/apache/tomcat/util/descriptor/DigesterFactory.java
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?
Index:
C:/tc7.0.x/java/org/apache/tomcat/util/descriptor/DigesterFactory.java
===================================================================
--- C:/tc7.0.x/java/org/apache/tomcat/util/descriptor/DigesterFactory.java
(revision
1577108)
+++ C:/tc7.0.x/java/org/apache/tomcat/util/descriptor/DigesterFactory.java
(working
copy)
@@ -22,6 +22,7 @@
import java.util.Map;
import javax.servlet.ServletContext;
+import javax.servlet.jsp.JspContext;
import org.apache.tomcat.util.digester.Digester;
import org.apache.tomcat.util.digester.RuleSet;
@@ -103,6 +104,9 @@
URL id = ServletContext.class.getResource("resources/" + url);
if (id == null) {
id = ServletContext.class.getResource("jsp/resources/" + url);
+ if (id == null) {
+ id = JspContext.class.getResource("resources/" + url);
+ }
}
return id.toExternalForm();
}
Thanks
Violeta
Re: svn commit: r1560931 - in /tomcat/tc7.0.x/trunk: build.xml java/org/apache/tomcat/util/descriptor/DigesterFactory.java
Posted by Violeta Georgieva <mi...@gmail.com>.
Hi,
2014-03-13 23:33 GMT+02:00 Mark Thomas <ma...@apache.org>:
>
> On 13/03/2014 13:41, Violeta Georgieva wrote:
> > 2014-03-13 15:28 GMT+02:00 Mark Thomas <ma...@apache.org>:
>
> <snip/>
>
> >> What exactly is it that we want to cover? I can think of a number of
> >> requirements.
> >>
> >> 1. Ensure that Tomcat still works (excluding validation) if using a
> >> servlet API implementation that does not include the JSP schemas.
> >>
> >> 2. Ensure that Tomcat can still validate web.xml files if using a
> >> Servlet API implementation that does not include JSP schemas along with
> >> a JSP API implementation that does.
> >>
> >> Any more?
> >
> > No. These two cover the scenario.
>
> I think my recent changes have addressed this. It would be good if you
> could test with 7.0.x trunk and report back.
>
My basic tests show that it is working.
Thanks
Violeta
> Mark
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
Re: svn commit: r1560931 - in /tomcat/tc7.0.x/trunk: build.xml java/org/apache/tomcat/util/descriptor/DigesterFactory.java
Posted by Mark Thomas <ma...@apache.org>.
On 13/03/2014 13:41, Violeta Georgieva wrote:
> 2014-03-13 15:28 GMT+02:00 Mark Thomas <ma...@apache.org>:
<snip/>
>> What exactly is it that we want to cover? I can think of a number of
>> requirements.
>>
>> 1. Ensure that Tomcat still works (excluding validation) if using a
>> servlet API implementation that does not include the JSP schemas.
>>
>> 2. Ensure that Tomcat can still validate web.xml files if using a
>> Servlet API implementation that does not include JSP schemas along with
>> a JSP API implementation that does.
>>
>> Any more?
>
> No. These two cover the scenario.
I think my recent changes have addressed this. It would be good if you
could test with 7.0.x trunk and report back.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: svn commit: r1560931 - in /tomcat/tc7.0.x/trunk: build.xml java/org/apache/tomcat/util/descriptor/DigesterFactory.java
Posted by Violeta Georgieva <mi...@gmail.com>.
2014-03-13 15:28 GMT+02:00 Mark Thomas <ma...@apache.org>:
>
> On 13/03/2014 13:09, Violeta Georgieva wrote:
> > Hi Mark,
> >
> >
> > 2014-03-13 15:01 GMT+02:00 Mark Thomas <ma...@apache.org>:
> >>
> >> On 13/03/2014 12:28, Violeta Georgieva wrote:
> >>> 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.
> >>
> >> Then I'd argue that those bundles are broken as far as validation goes.
> >> You can't validate a web.xml document without access to the JSP schemas
> >> but it should not be necessary to have a dependency on the jsp-api just
> >> to validate a web.xml document.
> >>
> >
> > if you have two bundles one with the servlet API and another with JSP
API
> > then Servlet API bundle can import optionally the resources from JSP API
> > bundle.
> > That's the way bundles use when need some functionality. When you
import it
> > optionally you say that you need these resources/functionality but you
can
> > run also without it.
> > Using this way you cover xml validation on and off in this particular
> > scenario.
>
> My point is the the JSP API bundle should not be required at all to
> validate a schema from the Servlet API bundle. The Servlet API bundle
> should be self-contained.
>
> >>> 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?
> >>
> >> No. That creates a dependency on jsp-api.jar.
> >
> > :( You are right
> >
> >>
> >> A solution should be possible but it is going to be more complex that
> >> the patch proposed here.
> >
> > What we can do if we want to cover this scenario?
>
> What exactly is it that we want to cover? I can think of a number of
> requirements.
>
> 1. Ensure that Tomcat still works (excluding validation) if using a
> servlet API implementation that does not include the JSP schemas.
>
> 2. Ensure that Tomcat can still validate web.xml files if using a
> Servlet API implementation that does not include JSP schemas along with
> a JSP API implementation that does.
>
> Any more?
No. These two cover the scenario.
> Both of the above should be do-able.
>
> Mark
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
Re: svn commit: r1560931 - in /tomcat/tc7.0.x/trunk: build.xml java/org/apache/tomcat/util/descriptor/DigesterFactory.java
Posted by Mark Thomas <ma...@apache.org>.
On 13/03/2014 13:09, Violeta Georgieva wrote:
> Hi Mark,
>
>
> 2014-03-13 15:01 GMT+02:00 Mark Thomas <ma...@apache.org>:
>>
>> On 13/03/2014 12:28, Violeta Georgieva wrote:
>>> 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.
>>
>> Then I'd argue that those bundles are broken as far as validation goes.
>> You can't validate a web.xml document without access to the JSP schemas
>> but it should not be necessary to have a dependency on the jsp-api just
>> to validate a web.xml document.
>>
>
> if you have two bundles one with the servlet API and another with JSP API
> then Servlet API bundle can import optionally the resources from JSP API
> bundle.
> That's the way bundles use when need some functionality. When you import it
> optionally you say that you need these resources/functionality but you can
> run also without it.
> Using this way you cover xml validation on and off in this particular
> scenario.
My point is the the JSP API bundle should not be required at all to
validate a schema from the Servlet API bundle. The Servlet API bundle
should be self-contained.
>>> 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?
>>
>> No. That creates a dependency on jsp-api.jar.
>
> :( You are right
>
>>
>> A solution should be possible but it is going to be more complex that
>> the patch proposed here.
>
> What we can do if we want to cover this scenario?
What exactly is it that we want to cover? I can think of a number of
requirements.
1. Ensure that Tomcat still works (excluding validation) if using a
servlet API implementation that does not include the JSP schemas.
2. Ensure that Tomcat can still validate web.xml files if using a
Servlet API implementation that does not include JSP schemas along with
a JSP API implementation that does.
Any more?
Both of the above should be do-able.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: svn commit: r1560931 - in /tomcat/tc7.0.x/trunk: build.xml java/org/apache/tomcat/util/descriptor/DigesterFactory.java
Posted by Violeta Georgieva <mi...@gmail.com>.
Hi Mark,
2014-03-13 15:01 GMT+02:00 Mark Thomas <ma...@apache.org>:
>
> On 13/03/2014 12:28, Violeta Georgieva wrote:
> > 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.
>
> Then I'd argue that those bundles are broken as far as validation goes.
> You can't validate a web.xml document without access to the JSP schemas
> but it should not be necessary to have a dependency on the jsp-api just
> to validate a web.xml document.
>
if you have two bundles one with the servlet API and another with JSP API
then Servlet API bundle can import optionally the resources from JSP API
bundle.
That's the way bundles use when need some functionality. When you import it
optionally you say that you need these resources/functionality but you can
run also without it.
Using this way you cover xml validation on and off in this particular
scenario.
> > 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?
>
> No. That creates a dependency on jsp-api.jar.
:( You are right
>
> A solution should be possible but it is going to be more complex that
> the patch proposed here.
What we can do if we want to cover this scenario?
Thanks
Violeta
>
> Mark
>
>
> >
> > Index:
> > C:/tc7.0.x/java/org/apache/tomcat/util/descriptor/DigesterFactory.java
> > ===================================================================
> > ---
C:/tc7.0.x/java/org/apache/tomcat/util/descriptor/DigesterFactory.java
> > (revision
> > 1577108)
> > +++
C:/tc7.0.x/java/org/apache/tomcat/util/descriptor/DigesterFactory.java
> > (working
> > copy)
> > @@ -22,6 +22,7 @@
> > import java.util.Map;
> >
> > import javax.servlet.ServletContext;
> > +import javax.servlet.jsp.JspContext;
> >
> > import org.apache.tomcat.util.digester.Digester;
> > import org.apache.tomcat.util.digester.RuleSet;
> > @@ -103,6 +104,9 @@
> > URL id = ServletContext.class.getResource("resources/" + url);
> > if (id == null) {
> > id = ServletContext.class.getResource("jsp/resources/" +
url);
> > + if (id == null) {
> > + id = JspContext.class.getResource("resources/" + url);
> > + }
> > }
> > return id.toExternalForm();
> > }
> >
> >
> > Thanks
> > Violeta
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
Re: svn commit: r1560931 - in /tomcat/tc7.0.x/trunk: build.xml java/org/apache/tomcat/util/descriptor/DigesterFactory.java
Posted by Mark Thomas <ma...@apache.org>.
On 13/03/2014 12:28, Violeta Georgieva wrote:
> 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.
Then I'd argue that those bundles are broken as far as validation goes.
You can't validate a web.xml document without access to the JSP schemas
but it should not be necessary to have a dependency on the jsp-api just
to validate a web.xml document.
> 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?
No. That creates a dependency on jsp-api.jar.
A solution should be possible but it is going to be more complex that
the patch proposed here.
Mark
>
> Index:
> C:/tc7.0.x/java/org/apache/tomcat/util/descriptor/DigesterFactory.java
> ===================================================================
> --- C:/tc7.0.x/java/org/apache/tomcat/util/descriptor/DigesterFactory.java
> (revision
> 1577108)
> +++ C:/tc7.0.x/java/org/apache/tomcat/util/descriptor/DigesterFactory.java
> (working
> copy)
> @@ -22,6 +22,7 @@
> import java.util.Map;
>
> import javax.servlet.ServletContext;
> +import javax.servlet.jsp.JspContext;
>
> import org.apache.tomcat.util.digester.Digester;
> import org.apache.tomcat.util.digester.RuleSet;
> @@ -103,6 +104,9 @@
> URL id = ServletContext.class.getResource("resources/" + url);
> if (id == null) {
> id = ServletContext.class.getResource("jsp/resources/" + url);
> + if (id == null) {
> + id = JspContext.class.getResource("resources/" + url);
> + }
> }
> return id.toExternalForm();
> }
>
>
> Thanks
> Violeta
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: svn commit: r1560931 - in /tomcat/tc7.0.x/trunk: build.xml java/org/apache/tomcat/util/descriptor/DigesterFactory.java
Posted by Violeta Georgieva <mi...@gmail.com>.
Hi,
2014-03-13 23:12 GMT+02:00 Konstantin Kolinko <kn...@gmail.com>:
>
> 2014-03-13 16:28 GMT+04:00 Violeta Georgieva <mi...@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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
Re: svn commit: r1560931 - in /tomcat/tc7.0.x/trunk: build.xml java/org/apache/tomcat/util/descriptor/DigesterFactory.java
Posted by Konstantin Kolinko <kn...@gmail.com>.
2014-03-13 16:28 GMT+04:00 Violeta Georgieva <mi...@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org