~% sdk update

No new candidates found at this time.

~% sdk ls springboot 
================================================================================
Available Springboot Versions
================================================================================
 > * 2.3.3.RELEASE       2.1.3.RELEASE       1.5.9.RELEASE       1.2.7.RELEASE  
     2.3.2.RELEASE       2.1.2.RELEASE       1.5.8.RELEASE       1.2.6.RELEASE  
     2.3.1.RELEASE       2.1.1.RELEASE       1.5.7.RELEASE       1.2.5.RELEASE  
     2.3.0.RELEASE       2.1.0.RELEASE       1.5.6.RELEASE       1.2.4.RELEASE  
     2.2.9.RELEASE       2.0.9.RELEASE       1.5.5.RELEASE       1.2.3.RELEASE  
     2.2.8.RELEASE       2.0.8.RELEASE       1.5.4.RELEASE       1.2.2.RELEASE  
     2.2.7.RELEASE       2.0.7.RELEASE       1.5.3.RELEASE       1.2.1.RELEASE  
     2.2.6.RELEASE       2.0.6.RELEASE       1.5.2.RELEASE       1.2.0.RELEASE  
     2.2.5.RELEASE       2.0.5.RELEASE       1.5.1.RELEASE       1.1.12.RELEASE 
     2.2.4.RELEASE       2.0.4.RELEASE       1.4.7.RELEASE       1.1.11.RELEASE 
     2.2.3.RELEASE       2.0.3.RELEASE       1.4.6.RELEASE       1.1.10.RELEASE 
     2.2.2.RELEASE       2.0.2.RELEASE       1.4.5.RELEASE       1.1.9.RELEASE  
     2.2.1.RELEASE       2.0.1.RELEASE       1.4.4.RELEASE       1.1.8.RELEASE  
     2.2.0.RELEASE       2.0.0.RELEASE       1.4.3.RELEASE       1.1.7.RELEASE  
     2.1.16.RELEASE      1.5.22.RELEASE      1.4.2.RELEASE       1.1.6.RELEASE  
     2.1.15.RELEASE      1.5.21.RELEASE      1.4.1.RELEASE       1.1.5.RELEASE  
     2.1.14.RELEASE      1.5.20.RELEASE      1.4.0.RELEASE       1.1.4.RELEASE  
     2.1.13.RELEASE      1.5.19.RELEASE      1.3.8.RELEASE       1.1.3.RELEASE  
     2.1.12.RELEASE      1.5.18.RELEASE      1.3.7.RELEASE       1.1.2.RELEASE  
     2.1.11.RELEASE      1.5.17.RELEASE      1.3.6.RELEASE       1.1.1.RELEASE  
     2.1.10.RELEASE      1.5.16.RELEASE      1.3.5.RELEASE       1.1.0.RELEASE  
     2.1.9.RELEASE       1.5.15.RELEASE      1.3.4.RELEASE       1.0.2.RELEASE  
     2.1.8.RELEASE       1.5.14.RELEASE      1.3.3.RELEASE       1.0.1.RELEASE  
     2.1.7.RELEASE       1.5.13.RELEASE      1.3.2.RELEASE       1.0.0.RELEASE  
     2.1.6.RELEASE       1.5.12.RELEASE      1.3.1.RELEASE                      
     2.1.5.RELEASE       1.5.11.RELEASE      1.3.0.RELEASE                      
     2.1.4.RELEASE       1.5.10.RELEASE      1.2.8.RELEASE                      

================================================================================
+ - local version
* - installed
> - currently in use
================================================================================

@alesbukovsky thank you for letting us know. We should be good now.

Now that https://github.com/spring-io/github-changelog-generator/issues/34 is implemented, It would be great if dependency upgrades were sorted in the changelog as I feel it would be easier for folks to identify dependency upgrades they're interested in.

To reproduce quickly the issue, you need to patch DataSourceBuilder as follows and the run CommonsDbcp2DataSourcePoolMetadataTests. Both setDriverClassName and setConnectionFactoryClassName will be invoked because those two properties are present in the environment.

It would be nice to support Oracle UCP pooling. The reason for it is that Oracle is in very widespread use in enterprise environments. UCP is the preferred way to pooling with Oracle (the built-in pooling in the driver is deprecated). UCP adds additional enterprise-grade capabilities, such as support for ONS (Oracle Notification Service), FCF (Fast Connection Failover), enhanced JMX-introspection, RAC support etc.

https://docs.oracle.com/en/database/oracle/oracle-database/12.2/jjucp/intro.html#GUID-8CF6555B-E7EA-462C-88C8-78678E43BD17

But given the comments in: https://github.com/spring-projects/spring-boot/issues/8700 this might not be acceptable, as I guess access to the Oracle Maven repo would be required (if not dealing with it all through reflection, which is not ideal).

WDYT?

If not directly in spring boot due to the above challenge with repos, would https://projects.spring.io/spring-data-jdbc-ext/ be a better place? But I do not see any specific boot support in spring-data - and also the project does not seem very active with releases etc.

Boot is used a lot in enterprise envs, and supporting enterprise requirements and best-practice patterns in the framework seems sane to me.

Closing in favour of PR #23403

Taking a step back, it's rather ConfigurationPropertyNameAliases that attempts to bind to any alias that is configured irrespective to the fact that the "main property" has been bound.

DataSourceBuilder has a number of aliases to accommodate for small changes in API. For instance, Hikari has a jdbc-url rather than the more common url property so we have a mapping for that. This mapping is useless if the DataSource we configure isn't using Hikari.

So far we got away with it, but adding support for Oracle UCP means we need to add yet another alias that's actually a valid property for DBCP2 (yet referring to something completely different).

I've started to review and polish this. Unfortunately the use of alises has some limit. UCP requires us to map the driver class name to connection-factory-class-name. DBCP2's BasicDataSource happens to have exactly the same property for something entirely different.

With Hazelcast 4.0, Spring Boot 2.2.6 is not properly adhering to the spring.hazelcast.config application property which allows pointing to a specific Hazelcast configuration and then instantiating the proper bean.

Spring Boot is attempting to create a HazelcastInstance of HazelcastClientConfiguration (which expects <hazelcast-client> XML root tag) instead of HazelcastServerConfiguration (which expects <hazelcast> XML root tag).

The error that occurs:

Invalid root element in xml configuration! Expected: <hazelcast-client>, Actual: <hazelcast>.

The following Github repository depicts two example Spring Boot 2.2.6 projects, one with this error, and one with a workaround:

https://github.com/justinnichols/spring-boot-2.2.6-hazelcast-4.0

Dependencies:

<dependency>
	<groupId>com.hazelcast</groupId>
	<artifactId>hazelcast</artifactId>
	<version>4.0</version>
</dependency>

Configuration in application.properties:

spring.hazelcast.config=classpath:config/hazelcast.xml

The stacktrace that occurs is:

org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'hazelcastInstance' defined in class path resource [org/springframework/boot/autoconfigure/hazelcast/HazelcastClientConfiguration$HazelcastClientConfigFileConfiguration.class]: Bean instantiation via factory method failed; nested exception is org.springframework.beans.BeanInstantiationException: Failed to instantiate [com.hazelcast.core.HazelcastInstance]: Factory method 'hazelcastInstance' threw exception; nested exception is com.hazelcast.config.InvalidConfigurationException: Invalid root element in xml configuration! Expected: <hazelcast-client>, Actual: <hazelcast>.
	at org.springframework.beans.factory.support.ConstructorResolver.instantiate(ConstructorResolver.java:656) ~[spring-beans-5.2.5.RELEASE.jar:5.2.5.RELEASE]
	at org.springframework.beans.factory.support.ConstructorResolver.instantiateUsingFactoryMethod(ConstructorResolver.java:636) ~[spring-beans-5.2.5.RELEASE.jar:5.2.5.RELEASE]
	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.instantiateUsingFactoryMethod(AbstractAutowireCapableBeanFactory.java:1338) ~[spring-beans-5.2.5.RELEASE.jar:5.2.5.RELEASE]
	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBeanInstance(AbstractAutowireCapableBeanFactory.java:1177) ~[spring-beans-5.2.5.RELEASE.jar:5.2.5.RELEASE]
	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:557) ~[spring-beans-5.2.5.RELEASE.jar:5.2.5.RELEASE]
	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:517) ~[spring-beans-5.2.5.RELEASE.jar:5.2.5.RELEASE]
	at org.springframework.beans.factory.support.AbstractBeanFactory.lambda$doGetBean$0(AbstractBeanFactory.java:323) ~[spring-beans-5.2.5.RELEASE.jar:5.2.5.RELEASE]
	at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:222) ~[spring-beans-5.2.5.RELEASE.jar:5.2.5.RELEASE]
	at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:321) ~[spring-beans-5.2.5.RELEASE.jar:5.2.5.RELEASE]
	at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:202) ~[spring-beans-5.2.5.RELEASE.jar:5.2.5.RELEASE]
	at org.springframework.beans.factory.config.DependencyDescriptor.resolveCandidate(DependencyDescriptor.java:276) ~[spring-beans-5.2.5.RELEASE.jar:5.2.5.RELEASE]
	at org.springframework.beans.factory.support.DefaultListableBeanFactory.doResolveDependency(DefaultListableBeanFactory.java:1290) ~[spring-beans-5.2.5.RELEASE.jar:5.2.5.RELEASE]
	at org.springframework.beans.factory.support.DefaultListableBeanFactory.resolveDependency(DefaultListableBeanFactory.java:1210) ~[spring-beans-5.2.5.RELEASE.jar:5.2.5.RELEASE]
	at org.springframework.beans.factory.support.ConstructorResolver.resolveAutowiredArgument(ConstructorResolver.java:885) ~[spring-beans-5.2.5.RELEASE.jar:5.2.5.RELEASE]
	at org.springframework.beans.factory.support.ConstructorResolver.createArgumentArray(ConstructorResolver.java:789) ~[spring-beans-5.2.5.RELEASE.jar:5.2.5.RELEASE]
	... 18 common frames omitted

Caused by: org.springframework.beans.BeanInstantiationException: Failed to instantiate [com.hazelcast.core.HazelcastInstance]: Factory method 'hazelcastInstance' threw exception; nested exception is com.hazelcast.config.InvalidConfigurationException: Invalid root element in xml configuration! Expected: <hazelcast-client>, Actual: <hazelcast>.
	at org.springframework.beans.factory.support.SimpleInstantiationStrategy.instantiate(SimpleInstantiationStrategy.java:185) ~[spring-beans-5.2.5.RELEASE.jar:5.2.5.RELEASE]
	at org.springframework.beans.factory.support.ConstructorResolver.instantiate(ConstructorResolver.java:651) ~[spring-beans-5.2.5.RELEASE.jar:5.2.5.RELEASE]
	... 32 common frames omitted

Caused by: com.hazelcast.config.InvalidConfigurationException: Invalid root element in xml configuration! Expected: <hazelcast-client>, Actual: <hazelcast>.
	at com.hazelcast.client.config.XmlClientConfigBuilder.checkRootElement(XmlClientConfigBuilder.java:183) ~[hazelcast-4.0.jar:4.0]
	at com.hazelcast.client.config.XmlClientConfigBuilder.parseAndBuildConfig(XmlClientConfigBuilder.java:168) ~[hazelcast-4.0.jar:4.0]
	at com.hazelcast.client.config.XmlClientConfigBuilder.build(XmlClientConfigBuilder.java:157) ~[hazelcast-4.0.jar:4.0]
	at com.hazelcast.client.config.XmlClientConfigBuilder.build(XmlClientConfigBuilder.java:150) ~[hazelcast-4.0.jar:4.0]
	at com.hazelcast.client.config.XmlClientConfigBuilder.build(XmlClientConfigBuilder.java:145) ~[hazelcast-4.0.jar:4.0]
	at org.springframework.boot.autoconfigure.hazelcast.HazelcastClientFactory.getClientConfig(HazelcastClientFactory.java:66) ~[spring-boot-autoconfigure-2.2.6.RELEASE.jar:2.2.6.RELEASE]
	at org.springframework.boot.autoconfigure.hazelcast.HazelcastClientFactory.<init>(HazelcastClientFactory.java:48) ~[spring-boot-autoconfigure-2.2.6.RELEASE.jar:2.2.6.RELEASE]
	at org.springframework.boot.autoconfigure.hazelcast.HazelcastClientConfiguration$HazelcastClientConfigFileConfiguration.hazelcastInstance(HazelcastClientConfiguration.java:55) ~[spring-boot-autoconfigure-2.2.6.RELEASE.jar:2.2.6.RELEASE]
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[na:1.8.0_192]
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[na:1.8.0_192]
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[na:1.8.0_192]
	at java.lang.reflect.Method.invoke(Method.java:498) ~[na:1.8.0_192]
	at org.springframework.beans.factory.support.SimpleInstantiationStrategy.instantiate(SimpleInstantiationStrategy.java:154) ~[spring-beans-5.2.5.RELEASE.jar:5.2.5.RELEASE]

Workarounds (kindly provided by @mesutcelik via Gitter)

• Place the hazelcast.xml in the root of the classpath. (This is depicted in the repo linked above)
• Specify a hazelcast.config system property.
• Define a configuration bean programmatically.

Note that while Spring Boot 2.4.x upgrades to Hazelcast 4, 3.2.x is still supported and users can use hazelcast.version to downgrade if necessary.

Thanks for letting us know about the duplicate @mp911de. We'll use this issue to document the support a bit more explicitly.

I should also mentioned that I've started to polish the proposal already so there is no need to push additional commits. I'd like some feedback on what API I should be using so that users can override those settings if they want to.

I've tried to write some more test where someone would want to override those settings. Unfortunately that didn't work as calling withString with the same key in another customizer leads to:

Caused by: java.lang.IllegalArgumentException: Duplicate key datastax-java-driver.advanced.metrics.session.enabled
	at com.datastax.oss.protocol.internal.util.collection.NullAllowingImmutableMap$Builder.failIfDuplicateKeys(NullAllowingImmutableMap.java:226)
	at com.datastax.oss.protocol.internal.util.collection.NullAllowingImmutableMap$Builder.build(NullAllowingImmutableMap.java:198)
	at com.datastax.oss.driver.internal.core.config.typesafe.DefaultProgrammaticDriverConfigLoaderBuilder.buildConfig(DefaultProgrammaticDriverConfigLoaderBuilder.java:263)
	at com.datastax.oss.driver.internal.core.config.typesafe.DefaultProgrammaticDriverConfigLoaderBuilder.lambda$build$2(DefaultProgrammaticDriverConfigLoaderBuilder.java:248)
	at com.datastax.oss.driver.internal.core.config.typesafe.DefaultDriverConfigLoader.<init>(DefaultDriverConfigLoader.java:131)
	at com.datastax.oss.driver.internal.core.config.typesafe.DefaultDriverConfigLoader.<init>(DefaultDriverConfigLoader.java:117)
	at com.datastax.oss.driver.internal.core.config.typesafe.DefaultProgrammaticDriverConfigLoaderBuilder.build(DefaultProgrammaticDriverConfigLoaderBuilder.java:245)
	at org.springframework.boot.autoconfigure.cassandra.CassandraAutoConfiguration.cassandraDriverConfigLoader(CassandraAutoConfiguration.java:114)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:498)
	at org.springframework.beans.factory.support.SimpleInstantiationStrategy.instantiate(SimpleInstantiationStrategy.java:154)

I think we need a way to support this use case, we can't blindly set those values without a way for users to customise them. Is there a way to know that a key has been registered already (and therefore not apply anything) or a way for users to override whatever value has been set?

I'd prefer the former as it makes the auto-configuration backs off in a consistent way. If only the latter is possible, that would mean that the customizer should be ordered to run after the auto-configured one which is more work than it should IMO.

Why do you need to loop 10 times here?

I was a bit confused by that. The waitStrategy runs some CQL requests as well, doesn't it? That makes this test a bit fragile IMO.

You can import and use the class here, @ConditionalOnClass is evaluated without loading the class itself.

Thanks again @thorasine.

Small PR to fix a couple typos in the documentation.

I have some sympathy for that argument Andy. The fact that the binder can do things the annotation processor doesn't detect is annoying but, on the other hand, I think we need to draw a line somewhere.

Updating the AP to be more lenient if there is a getter/setter and the type does not match could be an option but I am not keen at all to expose properties that only have a setter. This is most probably going to break users that are relying on the current conventions to only expose what they want.

Thinking about this one so more, I think the problem is to do with third party class binding. Sure that's convenient and we make sure that the version we test against has "all the properties" exposed without us having to change any code but:

• Not having documentation for those is annoying and users have been reported that in the past several times
• We're at the mercy of whatever our 3rd party binding does. Although I find the API for connection properties a bit weird, we can't expect the DBCP2 project to align with our conventions
• We've moved away from third party binding for other features. Flyway comes to mind.

My opinion is that we should stop changing things for the third party binding use case and we should keep the current JavaBean standard expectations. Although it is a lot of work, I suggest we create a separate issue to remove third party binding for all connection pools and do the mapping ourselves. We could document the properties and add a test that checks that for every javabean property found via reflection we have a mapping.

Thanks @jbotuck for bearing with me!

Can we add the property to the documentation here? https://docs.spring.io/spring-boot/docs/current/reference/html/appendix-application-properties.html#data-properties.

I am afraid we can't. Because it isn't really a valid property, it isn't detected and therefore not documented.

I'd feel better about using this if it wasn't some undocumented feature that can be removed at any time.

Documenting it wouldn't change anything to the fact that the DBCP2 project may decide to remove or change it at any time. We don't have any control on that.

Most of the setters in BasicDataSource can be configured from application.yml. https://commons.apache.org/proper/commons-dbcp/apidocs/org/apache/commons/dbcp2/BasicDataSource.html#setConnectionProperties-java.lang.String- cannot be configured.

Both Hikari and Tomcat have ways of configuring the properties that get sent to the driver but dbcp2 does not as this setter seems not to get registered by the @ConfigurationProperties annotation.

This limits the configurability of a dbcp2 datasource via spring boot

Spring boot allows this kind of configuration for both hikari and tomcat using spring.datasource.hikari.data-source-properties and spring.datasource.tomcat.connection-properties.

Again, as I've mentioned previously, there is nothing that Spring Boot does specifically for those two properties. Both Hikari and Tomcat exposes an accessor named "connection-properties" and that's about it.

If its not possible to bring dbcp2 up to parity with the other datasources because dbcp2 violates the javabean spec then how should I configure these properties in a spring boot application?

I've copy/pasted spring.datasource.dbcp2.connection-properties=enableRowsetSupport=1; in application.properties of a fresh app configured from start.spring.io and I can see via the debugger that BasicDataSource#setConnectionProperties is invoked with enableRowsetSupport=1;. It should be noted though that, because this property is unusual, there is no code assistance in the IDE.

I am going to close this now as there is no indication of a problem in Spring Boot.

@tomekl007 do you have time to process feedback on this PR?

@pavelgordon thank you for making your first contribution to Spring Boot.

Forward port of issue #23459 to 2.3.x.

I noticed that the link to Log4j JDK Logging Adapter is not working anymore - maybe they changed it in a process. Anyway, here is my minor PR to keep the documentation up-to-date and provide correct link.

<!-- Thanks for contributing to Spring Boot. Please review the following notes before submitting you pull request.

Please submit only genuine pull-requests. Do not use this repository as a GitHub playground.

Security Vulnerabilities

STOP! If your contribution fixes a security vulnerability, please do not submit it. Instead, please head over to https://pivotal.io/security to learn how to disclose a vulnerability responsibly.

Dependency Upgrades

Please do not open a pull request for a straightforward dependency upgrade (one that only updates the version property). We have a semi-automated process for such upgrades that we prefer to use. However, if the upgrade is more involved (such as requiring changes for removed or deprecated API) your pull request is most welcome.

Describing Your Changes

If, having reviewed the notes above, you're ready to submit your pull request, please provide a brief description of the proposed changes. If they fix a bug, please describe the broken behaviour and how the changes fix it. If they make an enhancement, please describe the new functionality and why you believe it's useful. If your pull request relates to any existing issues, please reference them by using the issue number prefixed with #. -->

Forward port of issue #23461 to 2.4.x.

Forward port of issue #23459 to 2.3.x.

@thorasine thank you for making your first contribution to Spring Boot.

This tiny PR fixes a typo

spring-javaformat does not optimize import

Thanks for the report but the README already indicates that this isn't in the scope of this project.

JobLauncherApplicationRunnerTests is quite involved and could use the new ApplicationContextRunner infrastructure rather than doing the setup manually.

We recently added a @SuppressWarnings as MapJobRepositoryFactoryBean is deprecated. We should switch to using an in-memory DB for this instead.

Hi, I am trying to generate a project through https://start.spring.io/ and trying to add aop dependency. If I type AOP or Aspect while adding the dependency, nothing shows up. I can see a lot of duplicate issues on the same topic. But, everything is closed. Not sure, whether it is a bug in latest versions. I tried with spring boot version 2.2.10 and 2.3.4 Thanks.

I can see a lot of duplicate issues on the same topic. But, everything is closed.

One of those duplicate issue is #180 where we explain why we intentionally removed the entry.

Well, it's not so much about abstracting the underlying cache, but transforming the value that's set into the cache.

Yes but that contract already exists in the Cache interface and creating yet another contract as a maintenance cost that isn't worth it.

maybe https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/cache/Cache.ValueWrapper.html with a set() in addition to the get() could be a way to go?

Certainly not, ValueWrapper must be immutable.

Looks good indeed, I think this can be closed. Thanks a lot for the quick turnaround!

Right now, we rely on the order of the available versions to present versions to users. If Sagan changes that order, this has a direct impact on us as we'd offer the exact same order. We should rather have a deterministic order, probably from the newest to the oldest (as it used to be the case).

This can be undesired if for example HSQLDB is on the class path for other purposes but the primary data source should always be configured explicitly and yield an error if missing.

Thanks for the report but I am not sure I understood that. What primary data source? Can we take a step back and can you please describe the use case that led you to report this?

Forward port of issue #23452 to 2.4.x.

Forward port of issue #23068 to 2.3.x.

See https://github.com/spring-projects/spring-boot/issues/23051#issuecomment-679191023

Forward port of issue #23452 to 2.4.x.

Forward port of issue #23068 to 2.3.x.

Some projects have switched from an alphabetical release train scheme to a CalVer format. As we don't know that format, it considers that 2020 is "older" than, say, Aluminium-RELEASE.

It would be nice if bomr understands this new format and only offer (actual) newest releases that match the current policy.

We've decided to remove the notes in 2.2.x forward and remove the code only in 2.4.x in case there is a side effect we haven't foreseen.

See https://github.com/spring-projects/spring-boot/issues/23197#issuecomment-693401904

I've created https://github.com/spring-projects/spring-framework/issues/25799

In Spring Boot we have some custom DataSource initialisation that needs to know about the state of the EMF. When JPA is bootstrapped in deferred mode, we need to make sure that our core runs as part of that lock.

For this we use JpaVendorAdapter#postProcessEntityManagerFactory. Our implementation sends a event and another component uses that as a trigger to do more things.

Unfortunately this setup leads to a deadlock in the main thread:

"main" #1 prio=5 os_prio=31 tid=0x00007f80d500c000 nid=0x2903 waiting on condition [0x000070000fd6a000]
   java.lang.Thread.State: WAITING (parking)
	at sun.misc.Unsafe.park(Native Method)
	- parking to wait for  <0x00000007236fb408> (a java.util.concurrent.FutureTask)
	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
	at java.util.concurrent.FutureTask.awaitDone(FutureTask.java:429)
	at java.util.concurrent.FutureTask.get(FutureTask.java:191)
	at org.springframework.orm.jpa.AbstractEntityManagerFactoryBean.getNativeEntityManagerFactory(AbstractEntityManagerFactoryBean.java:540)
	at org.springframework.orm.jpa.AbstractEntityManagerFactoryBean.invokeProxyMethod(AbstractEntityManagerFactoryBean.java:497)
	at org.springframework.orm.jpa.AbstractEntityManagerFactoryBean$ManagedEntityManagerFactoryInvocationHandler.invoke(AbstractEntityManagerFactoryBean.java:680)
	at com.sun.proxy.$Proxy57.getMetamodel(Unknown Source)
	at org.springframework.data.jpa.repository.config.JpaMetamodelMappingContextFactoryBean$$Lambda$576/2014729464.apply(Unknown Source)
	at java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
	at java.util.Iterator.forEachRemaining(Iterator.java:116)
	at java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801)
	at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:482)
	at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:472)
	at java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:708)
	at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
	at java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:566)
	at org.springframework.data.jpa.repository.config.JpaMetamodelMappingContextFactoryBean.getMetamodels(JpaMetamodelMappingContextFactoryBean.java:106)
	at org.springframework.data.jpa.repository.config.JpaMetamodelMappingContextFactoryBean.createInstance(JpaMetamodelMappingContextFactoryBean.java:80)
	at org.springframework.data.jpa.repository.config.JpaMetamodelMappingContextFactoryBean.createInstance(JpaMetamodelMappingContextFactoryBean.java:44)
	at org.springframework.beans.factory.config.AbstractFactoryBean.afterPropertiesSet(AbstractFactoryBean.java:142)
	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1853)
	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1790)
	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:594)
	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:516)
	at org.springframework.beans.factory.support.AbstractBeanFactory.lambda$doGetBean$0(AbstractBeanFactory.java:324)
	at org.springframework.beans.factory.support.AbstractBeanFactory$$Lambda$337/1777443462.getObject(Unknown Source)
	at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:234)
	- locked <0x000000072146f420> (a java.util.concurrent.ConcurrentHashMap)
	at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:322)
	at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:202)
	at org.springframework.beans.factory.support.BeanDefinitionValueResolver.resolveReference(BeanDefinitionValueResolver.java:330)
	at org.springframework.beans.factory.support.BeanDefinitionValueResolver.resolveValueIfNecessary(BeanDefinitionValueResolver.java:113)
	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.applyPropertyValues(AbstractAutowireCapableBeanFactory.java:1697)
	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.populateBean(AbstractAutowireCapableBeanFactory.java:1442)
	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:593)
	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:516)
	at org.springframework.beans.factory.support.AbstractBeanFactory.lambda$doGetBean$0(AbstractBeanFactory.java:324)
	at org.springframework.beans.factory.support.AbstractBeanFactory$$Lambda$337/1777443462.getObject(Unknown Source)
	at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:234)
	- locked <0x000000072146f420> (a java.util.concurrent.ConcurrentHashMap)
	at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:322)
	at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:202)

With the following state for task1 (the thread that was created to initialise the DB):

"task-1" #23 prio=5 os_prio=31 tid=0x00007f80944ca000 nid=0x480b waiting for monitor entry [0x00007000121de000]
   java.lang.Thread.State: BLOCKED (on object monitor)
	at org.springframework.context.event.AbstractApplicationEventMulticaster.getApplicationListeners(AbstractApplicationEventMulticaster.java:191)
	- waiting to lock <0x000000072146f420> (a java.util.concurrent.ConcurrentHashMap)
	at org.springframework.context.event.SimpleApplicationEventMulticaster.multicastEvent(SimpleApplicationEventMulticaster.java:134)
	at org.springframework.context.support.AbstractApplicationContext.publishEvent(AbstractApplicationContext.java:404)
	at org.springframework.context.support.AbstractApplicationContext.publishEvent(AbstractApplicationContext.java:361)
	at org.springframework.boot.autoconfigure.orm.jpa.DataSourceInitializedPublisher.publishEventIfRequired(DataSourceInitializedPublisher.java:99)
	at org.springframework.boot.autoconfigure.orm.jpa.DataSourceInitializedPublisher.access$100(DataSourceInitializedPublisher.java:50)
	at org.springframework.boot.autoconfigure.orm.jpa.DataSourceInitializedPublisher$DataSourceSchemaCreatedPublisher.postProcessEntityManagerFactory(DataSourceInitializedPublisher.java:197)
	at org.springframework.orm.jpa.AbstractEntityManagerFactoryBean.buildNativeEntityManagerFactory(AbstractEntityManagerFactoryBean.java:412)
	at org.springframework.orm.jpa.AbstractEntityManagerFactoryBean$$Lambda$803/1946962024.call(Unknown Source)
	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
	at java.lang.Thread.run(Thread.java:748)

Forward port of issue #23447 to 2.3.x.

The 2.2 and 2.3 reference docs state that Boot "requires Java 8 and is compatible up to Java 14 (included)". We should update this to reflect that we now support Java 15.

Forward port of issue #23447 to 2.3.x.

@gitkunming please use your own fork for experiments.

Unfortunately, we can't switch to this as I thought as we send an event in that EMF lock and that leads to a deadlock in framework .

Thanks for the suggestion but we need to draw a line somewhere as the cache support in Spring Framework can't abstract the actual cache libraries too much. You already have that contract using a delegation pattern and a CacheResolver to return a wrapped Cache that does what you want.

It would be nice if there was a pluggable mechanism (i.e. strategy interface) in order to intercept put/get to the underlying caches that the CacheManager interacts with.

This would allow for transforming read/writes in order to decrypt/encrypt the values.

There seems to be another user requesting the same at SO: https://stackoverflow.com/questions/46478798/how-to-write-custom-interceptor-for-spring-cachecachable

See #22896 for background.

Describe the bug The source model for a constructor that is made available to other annotation processors does not contain sensible parameter names. Consider the following example

package com.example.lombok.source.example;

import lombok.Data;

@Data
public class SampleData {

	private final String name;

	private final int description;

}

If an annotation processor runs after Lombok, it can access its constructor model. However, parameter names for the constructor are arg0 and arg1 respectively. It should be name and description instead.

To Reproduce

git clone https://github.com/snicoll-scratches/lombok-source-model.git
cd lombok-source-model
./mvnw clean install
cat lombok-source-model-sample/target/classes/lombok-source-model.properties

Expected behavior The output of that properties file should be:

SampleData.constructor.1.type=int
SampleData.constructor.0.type=java.lang.String
SampleData.constructor.1.name=description
SampleData.constructor.0.name=name

Version info (please complete the following information):

• Lombok version: 1.18.10 (can be changed via -Dlombok.version`)
• Platform openjdk version "1.8.0_202"

Additional context The Spring Boot project generates metadata for @ConfigurationProperties annotated type and has dedicated lombok support. Because the constructor does not expose relevant property names, the generated metadata does not match the source model and is currently invalid.

I've tested a snapshot build of lombok and this issue has been fixed as a side effect of another fix, see https://github.com/spring-projects/spring-boot/issues/18730#issuecomment-694718102

The output of the spring-boot-configuration-processor looks like below. It can't determine the names of any arguments. Those classes are standard classes with all final fields, annotated with lombok's @Data.

The issue only happens if the constructor is created by lombok and the class is annotated with @ConstructorBinding. If I create the constructor by hand, then it all works just fine. If I make the class mutable and remove @ConstructorBinding, it also works fine, even with a lombok-generated constructor.

{
  "groups": [
    {
      "name": "config.processor",
      "type": "io.app.config.ProcessorConfig",
      "sourceType": "io.app.config.ProcessorConfig"
    },
    {
      "name": "config.sender",
      "type": "io.app.config.SenderConfig",
      "sourceType": "io.app.config.SenderConfig"
    }
  ],
  "properties": [
    {
      "name": "config.processor.arg0",
      "type": "java.util.Map<java.lang.String,io.app.config.ProcessorConfig$InnerClasss>",
      "sourceType": "io.app.config.ProcessorConfig"
    },
    {
      "name": "config.sender.arg0",
      "type": "java.lang.Boolean",
      "sourceType": "io.app.config.SenderConfig"
    },
    {
      "name": "config.sender.arg1",
      "type": "java.lang.String",
      "sourceType": "io.app.config.SenderConfig"
    },
    {
      "name": "config.sender.arg2",
      "type": "java.lang.String",
      "sourceType": "io.app.config.SenderConfig"
    },
    {
      "name": "config.sender.arg3",
      "type": "java.lang.String",
      "sourceType": "io.app.config.SenderConfig"
    },
    {
      "name": "config.sender.arg4",
      "type": "java.lang.String",
      "sourceType": "io.app.config.SenderConfig"
    }
  ],
  "hints": []
}

I've tested a snapshot of the lombok build and I confirm that the issue is fixed.

Forward port of issue #23445 to 2.3.x.

Hi,

this commit is a backport of 54f93e9 in order to fix the build pipeline on 2.2.x & 2.3.x

See gh-23433 See gh-21605

Cheers, Christoph