> > > 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 johan
