tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Johan Compagner <>
Subject Re: Severe 7.0.47 startup performance regression
Date Thu, 05 Dec 2013 11:50:28 GMT
> > Does anyone know why this wasn't done by using services? (SPI)
> >  So that we can directly point to a class that is the websocket or point
> to
> > a class that registers the websockets?
> The Java WebSocket 1.0 specification requires this behaviour.
> As has been pointed out previously, there really should be a way for a
> web application to disable a container provided SCI if it knows it
> doesn't need it. The specification doesn't currently allow this. A
> Tomcat specific feature to do this is on my TODO list. I'm thinking
> something like a regular expression of SCI implementation classes to
> exclude configured on the Context. As always, patches welcome.
I was just wondering what the reasons where for depending on a full
jar/class scan.
I didn't follow the spec discussion at all (i am just about to start using
I know the spec is build like that that they are not depending at all of a
web container or something like that
 (i think you explained this before)

but doing full jar/class scans instead is for me just a weird choice, thats
bad for performance for huge apps.

Also having some kind of setting so that tomcat doesn't scan if you as a
developer know that it doesn't need it at all.
That only fixes stuff that really don't use it. But now i have a big
project and i do use 1 or 2 websocket here and there.
Then it must be scanned. What i rather would have that it works like a SPI
or some other kind of (osgi) services
so that websocket scanner just ask for a SPI instances and then gets the
websocket classes from that.
then only 1 file is looked for in a jar (manifest/services/xxxx) instead of
all the classes


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message