Closed TheRealAgentK closed 4 months ago
Ping @mduncan26 ...?
Does this only affect the collection of environment information or does it impact other functionality too? @TheRealAgentK
@mduncan26 The code in Raygun4Java is wrapped in try/catch, so it might not manifest to the implementor during collection.
When you look at https://github.com/MindscapeHQ/raygun4java/blob/master/core/src/main/java/com/mindscapehq/raygun4java/core/messages/RaygunEnvironmentMessage.java lines 52 and below, you can see the code that would cause the issue if it wasn't wrapped in try/catch.
So, in a best-case scenario the collected information via the mbean would just not be availvable and missing.
It would probably be better to check for availability of the missing/locked classes at runtime, as outlined (very roughly) IN https://github.com/MindscapeHQ/raygun4cfml/issues/34#issuecomment-752268657). I haven't tried that in the cfml provider yet, but it'd be good to maybe implement this in the same way consistently across any JVM-based provider.
Ok cool, so will we need to consider this for Raygun4Android? It's environment info collection looks rather different than both our cold fusion and java SDKs. https://github.com/MindscapeHQ/raygun4android/blob/master/provider/src/main/java/com/raygun/raygun4android/messages/crashreporting/RaygunEnvironmentMessage.java
Yeah, I don't think it'll become an issue there. The root of the problem is in Java 11+ and the changes towards smaller modules instead of a big lump of classes in the JVM. I don't see this happening on Android at the moment.
But it might be an issue for some of the JVM framework providers. I vaguely remember there was something for the Play framework and I'm not sure if there's specific providers for Spring or other platforms that would do their own thing and not fallback to the generic Java provider.
The Raygun4CFML fix is here:
https://github.com/MindscapeHQ/raygun4cfml/commit/b96986145fe2ef44abc77cfc2f9c31c6c4b17167
The difference is - my new method in the CFML provider tracks heap memory and not physical memory anymore. That might or might not be what you'd want to do, but I think that's more useful in a JVM sense anyway.
Quick note: @sfeldkamp just logged a Java 11 issue in my CFML provider (https://github.com/MindscapeHQ/raygun4cfml/issues/34)
It stems from the way how modules work in Java 11+ and it's quite likely that the RG4Java provider would currently experience a similar issue because it's using very similar code to achieve pulling the memory stats.
I'll update this ticket when I've fixed it in RG4CFML.