[Bug 54261] New: web-fragment.xml handling in container JARs

[bu...@apache.org]

https://issues.apache.org/bugzilla/show_bug.cgi?id=54261

            Bug ID: 54261
           Summary: web-fragment.xml handling in container JARs
           Product: Tomcat 7
           Version: trunk
          Hardware: All
                OS: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Catalina
          Assignee: dev@tomcat.apache.org
          Reporter: markt@apache.org
    Classification: Unclassified

Tomcat does not follow the language of section 8.2.1 of the Servlet
specification.

In short, JARs provided at the container level:
- are scanned for SCIs
- are scanned for static resources
- are NOT scanned for web-fragment.xml
- are NOT excluded by an absolute ordering

Tomcat does not follow these last two points.

-- 
You are receiving this mail because:
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org

[Bug 54261] web-fragment.xml handling in container JARs

[bu...@apache.org]

https://issues.apache.org/bugzilla/show_bug.cgi?id=54261

--- Comment #2 from Mark Thomas <ma...@apache.org> ---
The relevant section is:
<quote>
If a framework wants its META-INF/web-fragment.xml honored in such a way that
it augments a web application's web.xml, the framework must be bundled within
the web application's WEB-INF/lib directory. In order for any other types of
resources (e.g., class files) of the framework to be made available to a web
application, it is sufficient for the framework to be present anywhere in the
classloader delegation chain of the web application. In other words, only JAR
files bundled in a web application's WEB-INF/lib directory, but not those
higher up in the class loading delegation chain, need to be scanned for
web-fragment.xml
</quote>

The wording isn't as clear as it could be but the Servlet 3.0 EG lead has
confirmed the intended behaviour is as per my description. And yes, they should
still be scanned for TLDs.

I haven't tried to understand the reasoning behind this decision. My head hurts
enough already from just trying to nail down what the intended behaviour is
meant to be. I have thought through the implications for WebSocket and there
isn't anything I am worried about at this point.

-- 
You are receiving this mail because:
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org

[Bug 54261] web-fragment.xml handling in container JARs

[bu...@apache.org]

https://issues.apache.org/bugzilla/show_bug.cgi?id=54261

Mark Thomas <ma...@apache.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |WONTFIX

--- Comment #5 from Mark Thomas <ma...@apache.org> ---
This is going to be very tricky to implement without changes to the JarScanner
interface. That makes it tempting to defer this until Tomcat 8.

Users that want exactly the specification defined behaviour can add the JARs to
the org.apache.catalina.startup.ContextConfig.jarsToSkip

Scanning for SCIs in container JARs is only implied and then in terms of an SCI
for JSP functionality. Tomcat doesn't (yet) use an SCI in this case. If it did,
we could hard-code the addition of that SCI and not rely on scanning anyway.

CATALINA_BASE/lib is the combined common/server/shared class loader. JARs in
the shared loader are *meant* to be treated as if they are part of the web app
(Tomcat specific extension).

Given all of the above, I am going to mark this as WONTFIX.

-- 
You are receiving this mail because:
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org

[Bug 54261] web-fragment.xml handling in container JARs

[bu...@apache.org]

https://issues.apache.org/bugzilla/show_bug.cgi?id=54261

--- Comment #1 from Konstantin Kolinko <kn...@gmail.com> ---
Mark, what version of specification are you referring to?

I do not see such wording in ch.8.2.1 of Servlet Spec."3.0 Rev a"
(servlet-3_0-mrel-spec.pdf).

> - are scanned for static resources
> - are NOT scanned for web-fragment.xml

I do not quite understand why web-fragment.xml and static resources are treated
differently.

One more item for the list:
- are scanned for TLDs

-- 
You are receiving this mail because:
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org

[Bug 54261] web-fragment.xml handling in container JARs

[bu...@apache.org]

https://issues.apache.org/bugzilla/show_bug.cgi?id=54261

--- Comment #4 from Remy Maucherat <re...@apache.org> ---
The specification is about webapps and their packaging, it never deals with
anything related to the container own packaging. So there is not going to be
any requirement for that feature, but it is not forbidden either.

Certainly having "shared" fragments with "known" names reduces webapp
portability, just like the "known" names of "base" servlets (which was needed
of course) did and had to be standardized later on.

-- 
You are receiving this mail because:
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org

[Bug 54261] web-fragment.xml handling in container JARs

[bu...@apache.org]

https://issues.apache.org/bugzilla/show_bug.cgi?id=54261

--- Comment #3 from Konstantin Kolinko <kn...@gmail.com> ---
(In reply to comment #2)
> The relevant section is:
> <quote>
> If a framework wants its META-INF/web-fragment.xml honored in such a way
> that it augments a web application's web.xml, (...)

OK, this explains web fragments.
It should also imply that they
- are NOT scanned for @WebServlet/@WebFilter/@WebListener

based on a) support for metadata-complete attribute in web-fragmrnt.xml, b) 8.1
mentions WEB-INF/lib and WEB-INF/classes only
<quote from=8.1>
In a web application, classes using annotations will have their annotations
processed
only if they are located in the WEB-INF/classes directory, or if they are
packaged
in a jar file located in WEB-INF/lib within the application.
</quote>


Regarding static resources see ch.4.6 that mentions WEB-INF/lib only, thus they
are "NOT scanned",

<quote from=4.6>
The getResource and getResourceAsStream methods take a String with a leading
“/” as an argument that gives the path of the resource relative to the root of
the
context or relative to the META-INF/resources directory of a JAR file inside
the
web application’s WEB-INF/lib directory
</quote>

The "resources" mentioned in the fragment of 8.2.1 that Mark quoted, I think
are referring to class and property files available through classloader, and
are not talking about "static resources".


I think we can straighten this for Tomcat 8 (with its better support for
resources),
but for Tomcat 7 I am a bit afraid to change things.


I think that a reason behind disallowing web fragments at container level could
be
a) to lessen surprise for web applications that are moved between different
environments.
b) it simplifies requirements for declaration of web fragment ordering
c) it simplifies requirements for containers implementing this new feature
d) if a web fragment is in the container, it will be injected into all webapps
indiscriminately. Some of them may not expect this. It might even lead to some
security problems. Well, a SCI can inject the same servlets/filters/listeners
as a web fragment, but usually programmers are more accurate.

If we do change things for Tomcat 7, I think at most we can disallow
web-fragments coming from the parent ("common") classloader, based on security
concerns from "d)". I think whatever is injected into specific web application
(via a DirContext (like used by Eclipse IDE - see bug 51741) or via
VirtualWebappLoader in its context.xml) is under control of a specific web
application and should be allowed.

-- 
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org