-
Notifications
You must be signed in to change notification settings - Fork 48
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
values set on HttpAppSession init are later null #66
Comments
You can work around this by not using an init method but making explicit calls to set the app variable (and any others you need) on your session Actor that are not set yet. Kinda like lazy loading |
Where is Ruediger? |
quite busy at the moment :) srry |
you are probably accessing the actor proxy. Each actor ref is actually a proxy with class == actor class but empty state. the actor proxy (== actor ref) is generated such that all calls are actually enqueued instead of being executed synchronously. However the state on actor proxy is always null. you can use session.getActorProxy().app, however you vialate the threading contract this way |
Been thinking about this issue. I frequently need an object to refer to in the front end when I log in. Due to the use of the Actor proxy I cannot have fields on the session object. So I always need a separate roundtrip async call to the ..AppSession Actor to deliver the extra information I need. Is it possible to alter the Session Actor to have some sort of general purpose instantiated Map<String,Object> where we can deliver the required data to the front end without this extra roundtrip? |
Archive.zip
Hi,
I am still using the old pattern for HttpApp and HttpAppSession, but found no material differences with the new example. The assertions fail in KontraktorTestHttpApp
Where the app and testValue are set during the KontraktorTestHttpApp call to init the KontraktorTestHttpAppSession class. I also tried a direct non message for the init as it is actually void return in my cases. Got the feeling maybe I missing something obvious. Version 4.22
The text was updated successfully, but these errors were encountered: