-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Mark,
On 3/21/18 6:24 AM, Mark Thomas wrote:
> On 21/03/18 05:32, Christopher Schultz wrote:
>> All,
>>
>> I'm exploring running my application under a SecurityManager
>
> That's brave.
>
>> (on Tomcat 8.5.29), and I'm getting an unexpected complaint
>> during Tomcat shutdown:
>>
>> Mar 21, 2018 1:26:23 AM
>> org.apache.catalina.core.ApplicationContext log SEVERE:
>> my.JNDIDataSourceShutdownListener: Cannot close DataSource
>> java.lang.reflect.InvocationTargetException at
>> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at
>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
jav
>>
>>
a:62)
>> at
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sor
>>
>>
Impl.java:43)
>> at java.lang.reflect.Method.invoke(Method.java:498) at
>> my.JNDIDataSourceShutdownListener.close(JNDIDataSourceShutdownListene
r.j
>>
>>
ava:84)
>> at
>> my.JNDIDataSourceShutdownListener.contextDestroyed(JNDIDataSourceShut
dow
>>
>>
nListener.java:63)
>> at
>> org.apache.catalina.core.StandardContext.listenerStop(StandardContext
.ja
>>
>>
va:4800)
>> at
>> org.apache.catalina.core.StandardContext.stopInternal(StandardContext
.ja
>>
>>
va:5437)
>> at
>> org.apache.catalina.util.LifecycleBase.stop(LifecycleBase.java:226)
>>
>>
at
>> org.apache.catalina.core.ContainerBase$StopChild.call(ContainerBase.j
ava
>>
>>
:1437)
>> at
>> org.apache.catalina.core.ContainerBase$StopChild.call(ContainerBase.j
ava
>>
>>
:1426)
>> at java.util.concurrent.FutureTask.run(FutureTask.java:266) at
>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.
jav
>>
>>
a:1142)
>> at
>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor
.ja
>>
>>
va:617)
>> at java.lang.Thread.run(Thread.java:748) Caused by:
>> java.security.AccessControlException: access denied
>> ("javax.management.MBeanServerPermission" "createMBeanServer")
>> at
>> java.security.AccessControlContext.checkPermission(AccessControlConte
xt.
>>
>>
java:472)
>> at
>> java.security.AccessController.checkPermission(AccessController.java:
884
>>
>>
)
>> at
>> java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
>>
>>
at
>> java.lang.management.ManagementFactory.getPlatformMBeanServer(Managem
ent
>>
>>
Factory.java:465)
>> at
>> org.apache.tomcat.dbcp.dbcp2.BasicDataSource.close(BasicDataSource.ja
va:
>>
>>
1950)
>> ... 15 more
>>
>>
>> My JNDIDataSourceShutdownListener fetches the JNDI DataSource
>> from the JNDI tree and reflectively calls "close" on it to free
>> it up.
>>
>> This seems unexpected because:
>>
>> 1. I would expect that the MBeanServer would still be available
>> even during application shut-down (before Tomcat itself shuts
>> down).
>>
>> 2. I would expect that BasicDataSource would use a
>> PrivilegedAction if it needed to create an MBeanServer in this
>> way.
>>
>> I can obviously just give this permission to the application, but
>> I think it probably makes more sense to solve this in a different
>> way -- through Tomcat itself.
>
> Looks like the fix would need to be in DBCP2 since that is the
> source of that code.
>
>> Any ideas? I'm certainly no expert in SecurityManagers and what
>> Tomcat is doing under the covers with its DataSources.
>
> Doesn't Tomcat shutdown the JNDI datasource without
> JNDIDataSourceShutdownListener doing it explicitly? See closeMethod
> in the docs/code. With the shut down initiated from Tomcat code,
> the right permissions should be in place.
Hmm, I'll take a look at that.
This Listener predates a lot of Tomcat's more recent capabilities. I
know that there is a tension between the officially-documented
behavior of JNDI DataSources (you always get a new DataSource) and
what webapps usually do (always go to JNDI to get the DataSource) and
so Tomcat has options by default that re-issue the same DataSource to
code.
It used to be that failing to dispose of the DataSource left it
hanging around. That seemed unclean to me, so I wrote the
ServletContextListener to shut it down cleanly.
My JDBC library is in Tomcat's lib/ directory for a handful of reasons
(not the least of which is that Connector/J team can't seem to figure
out how to let client code shut down the Threads it creates --
stupidly I might add). Does that impact whether or not Tomcat will
auto-close the DataSource?
The <Resource> itself is defined in the application's
META-INF/context.xml file and nowhere else. How does that impact things?
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlqyYxMACgkQHPApP6U8
pFh/yhAAp5gKGvM6WoznC7SK9lhD0OMhe4BY9/MkehYfh6ZvEBWKobCa6C1kjE+2
n9ePARG7YSLQT+viIn+bFhmYY301mko7ry//eIOxvTDlt+ptzN4jskcOwKP2t0S8
P69J6JISw3j8maVHKoYpwhtVIPJQFv/80o5brfmpfESiXK/eZgU9EVdsVa1JZnvh
SttXOw0XsfjNF5CnVZh7cTock5QjW1bBh4lyP7Dksxd2mohXtZVmrk/CMmiJ09QC
l7LEdVELV6BjFncwwkmizCLkzo5teLJivdDXmHie2ixxLwmjVQl2Jv8azLfRRZUI
8TzVf1L0gqEh4jNip69jJ2+fZlBkGZ67tML3Ex8VpgCKmgrYRPRpy6BBe+25MCU/
SAZXKH2wA/PuGcPjry/odBi2oqIJOECRLbYfT+1gQ5jlYnfILjLtvtkIj5DEU4DU
N+KEfwNWZVO8napI+wfue/dy/xPxMmJISGJ0kOSrEYey0XhQ42l3NhYOeR9wQ0uS
wJOhlEbS/WrbyiAaNP64BgPnzkpMRIACBrKx+/q9kVE6nC+wFr03fblOloi9288v
wr2BmydktWPuuuKwpiZzvYOallwzCKQYXGOLjQcqdMq/cpVTyvgCXb3+z3HrHG0e
HSJdgHIffzh2JzNaXY9BdDKzw6HMKu2IhYiH9B6v0Lgau+CAZ2c=
=PUEQ
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
