[geotk] Can I prevent Geotoolkit from spawning new threads?

Martin Desruisseaux martin.desruisseaux at geomatys.fr
Tue Oct 13 18:24:48 EDT 2009

Hello Jon

There is currently no way to prevent Geotk to create new threads. The shutdown 
hooks are not the only ones created; there is also various cleaner threads which 
are running as daemon threads, for example for removing entries from WeakHashMap 
as they are garbage collected.

It would be doable - while a bit unsafe - to disable the creation of shutdown 
hooks. But it would be more difficult to avoid the creation of other threads. 
However the issue may not be there. I'm not familiar with GAE, but I would be 
surprised if they disallow completly the creation of any Threads (if they really 
do so, then they probably explain their raisons somewhere and I would be curious 
to read them). Maybe they just set stricter constraints. The Thread constructor 
javadoc said:

     If group is null and there is a security manager, the group is
     determined by the security manager's getThreadGroup method.
     (...snip...) If there is a security manager, its checkAccess
     method is called with the ThreadGroup as its argument.

So I think that the issue is that Geotk uses ThreadGroup. I could remove every 
usage of ThreadGroup - this change would be much easier and hurtless to apply 
than removing Threads. But before doing so I would be curious to see if GAE 
publishes any policy about ThreadGroup which would explain what we are supposed 
to do.


Jon Blower a écrit :
> Hi,
> I've been experimenting with running Geotoolkit as part of a Google
> App Engine application.  I have just discovered that GAE does not
> allow applications to spawn new threads.  Unfortunately Geotoolkit
> does this when calling CRS.getSupportedCodes() or CRS.decode().  The
> creation of a ShutdownHook causes a security exception in GAE:
> java.lang.ExceptionInInitializerError
> 	at org.geotoolkit.factory.ShutdownHook.(ShutdownHook.java:55)
> 	at org.geotoolkit.factory.ShutdownHook.(ShutdownHook.java:41)
> 	at org.geotoolkit.factory.FactoryFinder.getServiceRegistry(FactoryFinder.java:198)
> 	at org.geotoolkit.factory.FactoryFinder.getFactories(FactoryFinder.java:216)
> 	at org.geotoolkit.factory.AuthorityFactoryFinder.getCRSAuthorityFactories(AuthorityFactoryFinder.java:264)
> 	at org.geotoolkit.referencing.DefaultAuthorityFactory.create(DefaultAuthorityFactory.java:92)
> 	at org.geotoolkit.referencing.CRS.getAuthorityFactory(CRS.java:219)
> 	at org.geotoolkit.referencing.CRS.decode(CRS.java:410)
> ...
> Caused by: java.security.AccessControlException: access denied
> (java.lang.RuntimePermission modifyThreadGroup)
> 	at java.security.AccessControlContext.checkPermission(AccessControlContext.java:323)
> 	at java.security.AccessController.checkPermission(AccessController.java:546)
> I imagine that this might be hard, but is there any way of using Gtk
> in such a way as that it does not spawn new threads?  By the way, it
> seems to spawn threads even when using a "databaseless" CRS database,
> i.e. with a static epsg.properties file.
> Thanks,
> Jon

More information about the Geotoolkit mailing list