-
Notifications
You must be signed in to change notification settings - Fork 77
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
Check configuredProvider that it holds valid CDI container. #445
Conversation
Check for both IllegalStateException and null value when filtering discovered providers. Signed-off-by: Doychin Bondzhev <[email protected]>
While executing JSON-B TCK, we hit this new code path. The extra check on CDIProvider.getCDI() returns null during the lazy initialization, which wipes out CDIProvider. I would like to find out the issue for this fix. @doychin can you point me to the original problem you are trying to fix? Thanks |
This was the original problem that I found when I was trying to run unit tests in CDI container. Because all tests run in the same JVM and each one of them was bringing up separate container I hit the problem where original code in CDI and in weld was generating NPE. https://issues.redhat.com/browse/WELD-2567 The problem comes from the fact that once container is initialized and then closed you can't get new one from original cdi provider. It will always return null and original code will not try to initialize new provider. It will just throw NPE. |
@Emily-Jiang Original issue was https://issues.redhat.com/browse/CDI-743 so take a look there for some more context. If memory serves, the issue was that the CDI implementation doesn't behave the way it was described in the javadoc. As in, javadoc claims ISE could be thrown, but the code didn't expect that and would not search for other providers if an exception popped up. EDIT: Weld 4.0.0.CR1 (and 4.0.0.Final) already contain the adjusted behavior for this, so you might want to upgrade to that if you aren't using it already. |
Throwing an ISE here makes sense, however there is still something that I feel is wrong with this new code. Line 82: This seems wrong to me. Just because a cdiProvider returns null once does not mean it will never return a valid result in the future. In Liberty we have one provider where I think we should add a flag that is set to true if configuredProvider was set in |
Well, you cannot really know. It might just shut down that provider (its container) and would always return
Hmm, I see what you mean. The current approach tries to re-initiate the the search for any other provider that works - an approach needed if you were to swap multiple providers on the fly (does anyone actually do that?).
Sounds good, we should add a boolean and also change the javadoc of |
I would be happy to create a PR. |
Check for both IllegalStateException and null value when filtering discovered providers.
Signed-off-by: Doychin Bondzhev [email protected]