Thanks so much! I'll send the PNG directly to your email in a bit. I'm going to be OOTO for the next few hours.
I was able to work around some of the issues by further reducing the calls to CRS.forCode; my gut tells me the exception is related to Derby internals. I did notice another interesting behavior that I'll share in a follow up email. In short, I'm checking the Coordinate reference system name() in my test, sometimes it comes back WGS 84, sometimes it comes back EPSG:WGS 84. I'm guessing more Derby internal weirdness that's probably due to query performance and caching or something. For now I'm able to move forward and work around these behaviors but I'll send more details when I'm back in office. Thanks again for all the help! On Thu, Dec 5, 2024, 10:35 AM Martin Desruisseaux < [email protected]> wrote: > Hello Nicholas > > After a second check, I saw that SIS still have some `catch > (SecurityException)` statements. We removed the calls to > AccessController.doPrivileged(…) in SIS 1.2 [1], but not yet the > SecurityException. Therefore, I added some missing `catch > (SecurityException)` statements around the use of `StackWalker` when a > fallback exists, but it would be good to keep the > "getStackWalkerWithClassReference" permission anyway for better results. > > I added `catch (SecurityException)` statements around the registration > and unregistration of the shutdown hook. Therefore, it should be okay to > not give that permission to SIS. The result will only be a log record at > Level.FINE. In replacement, I added a `Configuration.shutdown()` method > (it is a bit strange to have that method in a configuration class, but I > do not really see a better location at this time). > > The `catch (SecurityException)` statements will probably be removed in > some future SIS version (when SIS will depend on Java 24 or when > SecurityException will be deprecated), but probably not before a few years. > > > Le 2024-12-04 à 20 h 00, Nicholas Knize a écrit : > > > It looks like the ConcurrentAuthorityFactory#ShutdownHook is not > > actually shutting down the TimerThread which is created by Derby from > > the LocalDataSource#getConnection method. Here's the stack trace where > > the thread is being created all the way down to Derby: > > The PNG image seems to have been lost on the mailing list. Would it be > possible to send it directly to my email address? > > Martin > > [1]https://issues.apache.org/jira/browse/SIS-525 >
