Am 2020-04-16 um 11:46 schrieb Alan Bateman:
On 16/04/2020 09:46, Osipov, Michael wrote:
Folks,
can some one, or Rob, explain why this class is explicitly tied to the
application class loader [1] when using the ServiceLoader? Is there
any specific implication when the thread context class loader is used?
This makes it rather problematic using in a stacked class loader
environment as Apache Tomcat [2]. I can neither put it in the webapp
class path nor the common.loader class path although the caller is in
common.loader. I have patched the class locally, recomplied OpenJDK 14
and it worked from both, application class loader and Tomcat's
common.loader.
Can someone explain this?
I think you are asking for the spec of InitialDirContext to be changed
to specify the TCCL rather than the system class loader when locating
the provider for DNS lookups when using LDAP. There are significant
security issues that would require a lot of detailed analysis before
going there.
That is what I am asking for. If that is not possible, I can live with a
proper explanation why this won't be supported. Can you please elaborate
on the security issues here? My class loader knowledge is very limited.
Not clear to me that it's worth it as I can't imagine there
are many web applications that would want to bundle one of these
providers. Does it work if you put the provider on the class path that
Tomcat uses?
That's exactly the point. I don't want to bundle it with the webapp, but
with Tomcat only for all webapps. It will be added to CATALINA_HOME/lib
along with a custom realm. Both are loaded with Tomcat's common.loader
[1]. No, it does not load from common.loader because of the system class
loader restriction. It only works when it is loaded along side with
catalina.jar from the system class loader (as intended). See also my
answer to my question:
https://www.mail-archive.com/users@tomcat.apache.org/msg134882.html
[1] https://tomcat.apache.org/tomcat-8.5-doc/class-loader-howto.html
Michael
