Hi everybody,
I'm not sure if this mailing list the correct one, if not please give me
a note where to place that question.
When trying to use the Weld SE with together with a SecurityManager and
I got a exception thrown out of the ForkJoinWorkerThread:
java.lang.SecurityException: setContextClassLoader
at
java.base/java.util.concurrent.ForkJoinWorkerThread$InnocuousForkJoinWorkerThread.setContextClassLoader(ForkJoinWorkerThread.java:239)
I did some digging in the ForkJoinPool and there it states the possible
reason:
"If no thread factory is supplied via a system property, then the common
pool uses a factory that uses the system class loader as the thread
context class loader. In addition, if a SecurityManager is present, then
the common pool uses a factory supplying threads that have no
Permissions enabled. Upon any error in establishing these settings,
default parameters are used. It is possible to disable or limit the use
of threads in the common pool by setting the parallelism property to
zero, and/or using a factory that may return null. However doing so may
cause unjoined tasks to never be executed."
Now the special case of using those special threads with no permission
are only created when the ForkJoinPool is initialized with a security
manager installed at this point of time. If the security manager will be
installed later, it has not impact what so ever (this is my actual
work-around the problem for now)
Even if the security manager is enabled before the initialize of the
ForkJoinPool not all work is delegated to InnocuousForkJoinWorkerThread
instances (sometimes it picks the main thread instead, that has not the
restrictions, what I think should not be the case and is a potential
security leak too)
Why is this done this way and the change of the context class loader or
uncaught exception handler not checked by the actual security manager
instead?
Can anybody enlighten me on this so I can file the correct bug at the
correct place :-)
-Patrick
