Hi Tom,
Thank you for your reply.
I really was not trying hard to find problems, the only reason I hit these is because I need to debug remaining issues which prevent upgraded version of said application from running. The only tools (that I know of) at my disposal are breakpoints and osgi.debug;
my reasoning was (and still is) that the underlying cause of these can be caught by looking at these, since by the time logging layer is initialized, only symptoms are visible. I did start with setting breakpoints in 'org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader'
(in catch blocks of #loadClass and #getResource methods), but then started hitting those existing exceptions by the thousands, then when osgi.debug was enabled all these stack traces were dumped to text file and are being analyzed.
I see many of the stack traces (visible only in osgi.debug, or when hitting bps in DefaultClassLoader) then manifest as actual failures visible once logging layer kicks in (same classes, etc.)
Since file generated from osgi.debug is over 60 MB and there are over 3300 exceptions, sharing these is not really possible at this point.
Are there any other settings in osgi.debug or config.ini that could be turned on (many of these are not documented/hard to come across) that could help in properly diagnosing these issues?
Regards,
Michal