Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Document how to prevent a JNDI DataSource retrieved using JavaConfig to be removed on shutdown of the context [SPR-12551] #17153

Closed
spring-issuemaster opened this issue Dec 17, 2014 · 17 comments

Comments

@spring-issuemaster
Copy link
Collaborator

commented Dec 17, 2014

Eugene Stepanenkov opened SPR-12551 and commented

My application context is configured via Java-based context. The data source is configured in WebLogic side. I lookup DataSource from WebLogic side, all work fine except one thing:
After application redeploy the springs removes the JNDI name of DataSource from weblogic JNDI tree.


Affects: 4.0.6

Reference URL: http://stackoverflow.com/questions/19158837/weblogic-datasource-disappears-from-jndi-tree/19323524#19323524

Issue Links:

  • #17139 Add note to reference material about difference between XML destroy-method and @Bean destroyMethod behavior
  • #13393 Support 'destroy method inference' for @Bean methods
  • #17613 Destroy callback cannot be disabled for AutoCloseable beans

Referenced from: commits facd240

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Dec 17, 2014

Eugene Stepanenkov commented

I have investigated and understand that it is expected behavior, but could you please say how to use Java-based configuration by the right way when I use looked up DataSource?

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Dec 17, 2014

Stéphane Nicoll commented

Looks like it is related to #17139

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Dec 18, 2014

Stéphane Nicoll commented

Eugene, as explained in the documentation, you should add the following to your bean declaration to disable the destroy method inference:

@Bean(destroyMethod="")
public DataSource dataSource() { ... }
@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Dec 18, 2014

Eugene Stepanenkov commented

Stéphane Nicoll sure you are right. Thank you so much. Sorry for disturb. :)

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Dec 19, 2014

Stéphane Nicoll commented

don't be, you bring a very interesting use case! I am still considering what we could do on instances retrieved from JNDI.

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Dec 24, 2014

Stéphane Nicoll commented

Alright, let's schedule this one for 4.2. After discussing with Juergen Hoeller we believe that we could improve the developer experience of JNDI-based Java configuration. Doing so could help us disabling the inferred mode that detects the destroy method on such bean.

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Feb 20, 2015

Stéphane Nicoll commented

Alright. We had yet another look at this issue and there is no way to know that a @Bean method is actually retrieve via JNDI as you can basically write whatever code you wants in the method.

I have updated the documentation though and realized that Spring Boot is already taking care of this problem when it's in charge of auto-detecting a JNDI-based DataSource.

Sorry but that's the best we can do at this point. Thanks for the feedback!

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented May 4, 2015

Matt Rapczynski commented

Not sure this is fully resolved as described. Disabling the destroy method as indicated the docs is a good solution, but I cannot to get it to work with the latest 4.1.6. Here is my bean definition:

@Bean(destroyMethod = "")
@Profile("tomcat")
public DataSource dataSource() throws NamingException {
    return (DataSource) new JndiTemplate().lookup("java:comp/env/jdbc/banner");
}

Yet... when the context shuts down, my connection pool is still getting trashed as indicated in the log activity below.

.DefaultListableBeanFactory@6f2acdc9
16:04:10 DEBUG Invoking destroy() on bean with name 'springSecurityFilterChain'
16:04:10 DEBUG Invoking destroy() on bean with name 'casAuthenticationFilter'
16:04:10 DEBUG Invoking destroy() on bean with name 'objectPostProcessor'
16:04:10 DEBUG Invoking destroy method 'close' on bean with name 'dataSource'
16:04:10 INFO  HikariCP pool HikariPool-0 is shutting down.
16:04:10 DEBUG Before shutdown pool stats HikariPool-0 (total=1, inUse=0, avail=1, waiting=0)
16:04:10 DEBUG Closing connection oracle.jdbc.driver.T4CConnection@533377b
16:04:10 DEBUG After shutdown pool stats HikariPool-0 (total=0, inUse=0, avail=0, waiting=0)
16:04:10 INFO  Closing Root WebApplicationContext: startup date [Mon May 04 16:03:12 PDT 2015]; root of context hierarchy
16:04:10 DEBUG Returning cached instance of singleton bean 'lifecycleProcessor'

Am I missing something?

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented May 4, 2015

Stéphane Nicoll commented

We both are as I tested that in various environments. If you reopen, please provide a sample project that reproduces the problem. Thanks!

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented May 4, 2015

Matt Rapczynski commented

OK, will put one together in a day or two and throw it up on GitHub

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented May 4, 2015

Matt Rapczynski commented

OK, here you go:

https://github.com/mrapczynski/spr-12551-example

Just a little background. We maintain an internal starter template for Spring apps with all of our relevant customizations. I replaced the Oracle driver with H2, removed any of our Spring security stuff, and a few sensitive pieces of information. Using H2 set up in Tomcat as a JNDI data source, and an empty String for the destroyMethod on the @Bean annotation I get the same problem. When Spring shuts down, the logs show that it takes out the DataSource.

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented May 7, 2015

Stéphane Nicoll commented

-Looking at your build you don't seem to be using 4.2.0.BUILD-SNAPSHOT. Are you aware that this issue has been fixed in 4.2.0.RC1 (per the fix version) and it hasn't been released yet?-

Arg, I remember now that it was only a documentation update. Could you please update your project so that I can actually use it? Thanks.

I've also tried with a project on my own (with a @Bean definition with a @Profile) and it works as expected.

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented May 12, 2015

Stéphane Nicoll commented

Matt Rapczynski please reopen this issue if you have a sample project that reproduces this issue without your customizations. If you're still having this issue with the sample, please fix it so that we can run it and open a separate issue as I believe it is unrelated with this very issue.

Thanks!

FAILURE: Build failed with an exception.

* What went wrong:
A problem occurred configuring root project 'spr-12551-example'.
> Could not resolve all dependencies for configuration ':runtimeCopy'.
   > Could not resolve edu.fhda:splunk-appender-logback:1.3.
     Required by:
         edu.fhda:spr-12551-example:1.0
      > Could not GET 'http://sonatype.ad.fhda.edu/nexus/content/repositories/fhda/edu/fhda/splunk-appender-logback/1.3/splunk-appender-logback-1.3.pom'.
         > sonatype.ad.fhda.edu: unknown error
      > Could not GET 'http://sonatype.ad.fhda.edu/nexus/content/repositories/thirdparty/edu/fhda/splunk-appender-logback/1.3/splunk-appender-logback-1.3.pom'.
         > sonatype.ad.fhda.edu

* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output.
@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented May 12, 2015

Matt Rapczynski commented

Oops! Left that one behind. I am out of the office this week so I will fix it when I am back in, and will update the status then.

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented May 19, 2015

Matt Rapczynski commented

OK spent time some time on this. You were right, I left too many of the customizations behind so I knocked all that junk out. I re-tested by cloning the repo myself from GitHub into a new temp folder and ran Gradle. This time it works.

So here's the deal - after changing to 4.2.0 snapshot - it does not appear fixed. Here are the steps I am following to reproduce:

  1. Clone the sample project - https://github.com/mrapczynski/spr-12551-example
  2. Run gradle AppRun
  3. Watch Tomcat 8.0.22 boot, wait until you see "Press any key to stop the server.", and then press a key
  4. Tomcat will shut down, and you should see similar log messages as follows
09:36:47 DEBUG Invoking destroy method 'close' on bean with name 'dataSource'
09:36:47 INFO  HikariCP pool HikariPool-0 is shutting down.
09:36:47 DEBUG Before shutdown pool stats HikariPool-0 (total=1, inUse=0, avail=1, waiting=0)
09:36:47 DEBUG Closing connection conn0: url=jdbc:h2:/tmp/h2test user=SA
09:36:47 DEBUG After shutdown pool stats HikariPool-0 (total=0, inUse=0, avail=0, waiting=0)
09:36:47 INFO  Closing Root WebApplicationContext: startup date [Tue May 19 09:36:35 PDT 2015]; root of context hierarchy
09:36:47 DEBUG Returning cached instance of singleton bean 'lifecycleProcessor'

Based on how I have the class edu.fhda.spring.SpringAppRootConfig with the annotation @Bean(destroyMethod = ""), Spring should not be invoking anything on the dataSource bean. Only Tomcat should destroy it because the container is shutting down.

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented May 19, 2015

Matt Rapczynski commented

One thing I was not clear on from your prior comment - has the 4.2.0 build snapshot been brought up to the same level as 4.2.0.RC1?

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented May 20, 2015

Stéphane Nicoll commented

Matt, sorry about all the confusion (but we're going somewhere). This issue was solely about documentation since we decided not to implement anything at the framework level (I've updated the issue to make that more clear).

It turns out that you are experiencing something related but different. Your Datasource implements Closeable (and therefore AutoCloseable) and the context will always invoke the shutdown method regardless of your Bean definition. I actually experienced this myself while working on this very issue and I've created #17613 to track that. We will fix that in the upcoming 4.2 so please track that issue. Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.