Summary: | ServletContainerInitializer.onStartup() should receive only classes, not interfaces | ||
---|---|---|---|
Product: | Tomcat 9 | Reporter: | Grzegorz Grzybek <gr.grzybek> |
Component: | Servlet | Assignee: | Tomcat Developers Mailing List <dev> |
Status: | RESOLVED INVALID | ||
Severity: | normal | CC: | gr.grzybek |
Priority: | P2 | ||
Version: | 9.0.45 | ||
Target Milestone: | ----- | ||
Hardware: | PC | ||
OS: | Linux |
Description
Grzegorz Grzybek
2021-04-20 12:52:19 UTC
The fix will be in 10.0.6, 9.0.46 and 8.5.66, since the specification language is explicit enough (and there's likely no use case for interfaces). I'll remember to create Jetty issue tomorrow. Hi,
I think it is a bug to not list interfaces.
Spec quote considers interfaces as "class" in its wording:
> extends / implements one those classes
Not returning interfaces breaks some serious number of use cases, typically all cases where annotations are used for scanning and are put on interfaces (often it is then implemented thanks a proxy, even for Servlet case ;)) and cases where annotations host the "spec" of the API and are read from the scanned set to deduce it (meta annotation API alike).
So overall I see that interface scanning is:
1. used
2. compaitble with current spec wording (even allowed IMHO)
3. supported by tomcat (before the last commit), jetty and undertow
So it looks legitimate to rather ask the spec to phrase it explicitly rather than breaking user with next release and then get the feature back later (I assume spec will explicit interfaces are enabled).
(In reply to romain.manni-bucau from comment #3) > Hi, > > I think it is a bug to not list interfaces. > Spec quote considers interfaces as "class" in its wording: > > > extends / implements one those classes > I think you're right. It wasn't my intention to claim that current behavior should be changed. Following the research started in https://bz.apache.org/bugzilla/show_bug.cgi?id=65244 I found that specification may be confusing. But while 65244 was good catch, this one rather isn't. Thinking more about it, even `package-info` should be valid among the classes passed to `SCI.onStartup()` (when there's annotation used on a package in `@HandlesTypes`). So please excuse me for the confusion. Ok, I will reread and revert it. This is confusing ... So likely invalid due to the specification being rather unclear and the behavior being there for a long time. |