Closed benjamin-confino closed 3 weeks ago
3 follow ups from discussion:
1) The customer indicated the TCCL was preserved on the Thread used in WAS8/9. Need to create a test app in twas to test functionality of CDI.current() access to TCCL....
2) Contact customer and ask more detailed questions around how the "background thread" is obtained from T-WAS (If not just using new Thread())
3) Need clarification from the CDI community on setting application context, and propagating additional context metadata
Regarding 1, the test app the customer provided is attached. I am not surprised to say it I saw the error on twas. From what the customer has said their real app is different and I will ask them for details.
Precompiled app: wlp2-1.0-SNAPSHOT.zip
I'm still waiting for a reply about wheather the spec should be updated. But I got a reply from a weld dev saying they think what we're doing is fine.
CDI.current().getBeanManager()
should provide the bean manager for the current context - in other words the application running when application code callsgetBeanManager()
Because liberty is a multi application server we need a way of knowing which application the current thread is associated with, this requires an app to use ManagedExecutorService if they wish to spawn new threads. I have a customer who wishes us to use the TCCL(ThreadContextClassLoader) as a fallback.
Coding a solution will be straight forward, CDI already holds a reference to the TCCL for every application and I've verified this works in a quick test app. The question is weather supporting this will make any implicit promises we do not want to make?
It was eventually decided to implement a fix.