Bug 64021 - SCI ordering prevents a web application SCI from using a service bootstrapped by a container-provided SCI
Summary: SCI ordering prevents a web application SCI from using a service bootstrapped...
Alias: None
Product: Tomcat 9
Classification: Unclassified
Component: Catalina (show other bugs)
Version: 9.0.x
Hardware: PC All
: P2 normal (vote)
Target Milestone: -----
Assignee: Tomcat Developers Mailing List
Depends on:
Reported: 2019-12-19 14:59 UTC by Andy Wilkinson
Modified: 2020-01-16 14:37 UTC (History)
0 users


Note You need to log in before you can comment on or make changes to this bug.
Description Andy Wilkinson 2019-12-19 14:59:51 UTC
This issue relates to a Spring Framework issue [1] that describes a problem where Spring Framework's ServletContainerInitializer is unable to find Tomcat's WebSocket support as the latter is initialised by Tomcat's WsSci which runs after any application SCIs.

From a comment by Mark Thomas on the Spring Framework issue:

> I've been reading through 8.2.4 again and I think there is some room for
> manoeuvre here. The delegation order matters when both the web application
> and the container specify the same SCI. It must be the one from the web 
> application that is used. However, when we are looking at different SCIs I
> think there is scope to load the container provided SCIs first. I don't
> think  the spec language precludes that. The more I think about it, the
> more that makes sense. If the web app depends on the container services
> (like Spring does) then the container services need to be loaded first. If 
> the web app doesn't depend on them the order doesn't matter (so it is OK 
> for container services to be first).

> If you open a Tomcat bug on this I should be able to take a look -
> probably in January now.

[1] https://github.com/spring-projects/spring-framework/issues/22131
Comment 1 Mark Thomas 2020-01-16 14:28:26 UTC
Fixed in:
- master for onwards
- 9.0.x for 9.0.31 onwards
- 8.5.x for 8.5.51 onwards
- 7.0.x for 7.0.100 onwards
Comment 2 Andy Wilkinson 2020-01-16 14:37:57 UTC
Thanks very much, Mark.