On 05/12/2013 11:50, Johan Compagner wrote: >> >>> 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 > websockets) > 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
There is also the programmatic interface to WebSockets so once there is a way to disable the SCI, you can use the programmatic interface to set everything up. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
