You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A recent example of the problem can be found in f1da92e - Where AntiDecompilationSummarizer defines a Instance<MappingGeneratorPane>
The AntiDecompilationSummarizer class is ApplicationScoped
Generated values from the Instance<MappingGeneratorPane> were not being "destroyed" in the container, thus leading to leakage issues
Calling generatorPaneProvider.destroy(value) addresses the issue, but this needs to be handled in all similar cases. Something more automatic would be ideal. In our usage of dependent. If we can automatically call destroy so that the CDI won't prevent garbage collection, while still ensuring the generated beans have access to injected services that would be great. Otherwise we can probably re-create the Dependent scope.
The text was updated successfully, but these errors were encountered:
Background: https://rmannibucau.wordpress.com/2015/03/02/cdi-and-instance-3-pitfalls-you-need-to-know/
A recent example of the problem can be found in f1da92e - Where
AntiDecompilationSummarizer
defines aInstance<MappingGeneratorPane>
AntiDecompilationSummarizer
class isApplicationScoped
Instance<MappingGeneratorPane>
were not being "destroyed" in the container, thus leading to leakage issuesgeneratorPaneProvider.destroy(value)
addresses the issue, but this needs to be handled in all similar cases. Something more automatic would be ideal. In our usage of dependent. If we can automatically call destroy so that the CDI won't prevent garbage collection, while still ensuring the generated beans have access to injected services that would be great. Otherwise we can probably re-create theDependent
scope.The text was updated successfully, but these errors were encountered: