Karl,
this sounds a bit strange indeed :-)
your write: "this thread is also disconnected from my Bean and it fails
to look it up"
Anything in the session/view scopes will have to be serializable, and a
thread isnt.
A solution I could imagine is an @ApplicationScoped bean as
ThreadReferenceHolder HashMap<String,Runnable> to hold and manage the
spawned threads.
Your ViewScoped beans then only need to hold the thread reference keys -
now they are Serializable.
The ThreadReferenceHolder will be injected on each invocation of your
ViewScoped beans.
So you have a reference from ViewScoped beans to the threads, the other
way round I cannot imagine it will work correctly..
w.d.y.t?
Am 21.06.2016 um 14:10 schrieb Karl Kildén:
So it is impossible then :-)
The problem is that several slow things needs to be done from a JSF Bean. I
can't async it because the service the bean calls is @ViewAccessScoped and
stateful.
I have a Bean that I want to start the thread from the Bean it is not a
problem but when I create a new thread this thread is also disconnected
from my Bean and it fails to look it up...
Will take me ages to fix this project properly so desperate times calls for
strange hacks :-)
On 21 June 2016 at 12:39, Thomas Andraschko <[email protected]>
wrote:
BeanProvider should work fine with any scope.
Of course you can't receive a viewscoped bean from another thread/request.
2016-06-21 11:52 GMT+02:00 Karl Kildén <[email protected]>:
I have a RequestScoped Bean that needs to split the workload basically
and
the thread needs to lookup using the Bean that starts the thread so to
speak...
On 21 June 2016 at 11:24, Karl Kildén <[email protected]> wrote:
Hello!
If a project made a mistake in the architecture and needs to lookup JSF
scoped instances from the BeanProvider, is this possible in any way
(however hacky?).
The problem is that since the request thread is needed to lookup the
instance it does not work from a thread.
cheers
