The picking up the components is one of the bugs they are dealing with – and there are daily patches they are producing to correct it. You should expect that it will be working again with a newer release.
As far as passing in an identifier – why couldn’t that happen with an inline message? That component should be able to hold that variable and use it as an identifier going forward. This mirrors how a lot of the larger websocket application servers work as well.
There are a few ways to get access to your Application scope. One would be to inject the scope from the app side into the running component. Another way that certainly works (but I wouldn’t recommend) is to setup an Application.cfc that has the same name as the app you want to tie it with – causing a naming collision, but that would give you access to it. I don’t think you’ll get direct access to the session, unless, again, you inject it from the app side. This is no different than the REST components.
Perhaps accessing an identifier is the least of the issues and could be handled by pushing an ID to the websocket via a message. However, access to your application (and ideally your session scopes) are important. How would you inject these scopes into the websocket?
Assuming you can, you then have the problem that any existing code that you call that uses the standard scope notation, ie application.something will not work since these are not scopes that can be accessed anywhere in your code, but instead they are variables that need to be passed around. This was the case with the old websocket extension and required refactoring in order to pass these scopes as variables instead of accessing them directly.
Can a websocket handler access settings that are defined in application.cfc like email, caches, or mappings? What if you need to create a CFC inside your websocket handler using a mapping that’s defined in application.cfc? For example, could you call: CreateObject("common.cfc.thread").init(application.config); where common in a mapping that is defined in application.cfc?
One of the suggested approaches for processing incoming messages is to use a queue like redis to store incoming messages then have a task event gateway to process thru that queue and send a response
@markdrew did a presentation at CFCAMP about Lucee’s task event gateways
Login required to view the video, annnddd, BTW CFCAMP is an awesome conference, coming up in May, I’ll be doing a 90 minute workshop of high performance Lucee