profile
viewpoint

odrotbohm/moduliths 265

Building modular, monolithic applications using Spring Boot

spring-io/bomr 29

Command-line tool for creating and updating a Maven bom

spring-io/spring-asciidoctor-extensions 27

Asciidoctor Extensions developed by the Spring team

philwebb/spring-framework 3

The Spring Framework

wilkinsona/awaitility 1

Awaitility is a small Java DSL for synchronizing asynchronous operations

wilkinsona/flyway-hsqldb-hang 1

Sample application reproducing hang with Flyway and HSQLDB 2.3.4

spring-gradle-plugins/compatibility-test-plugin 0

Gradle plugin for testing a project's compatibility with different versions of its dependencies

pull request commentspring-io/spring-asciidoctor-extensions

Content toggle feature

Thanks for the PR, @buzzardo. Each of the files appears to be duplicated. Could you please remove those that aren't needed?

@rwinch does the functionality proposed here match what you had in mind for #37? Personally, I would prefer something that's more closely aligned with the existing block switch, ideally by extending its functionality beyond blocks.

Buzzardo

comment created time in 3 hours

IssuesEvent

issue closedspring-projects/spring-boot

Unlike all other Maven properties, spring-boot.run.arguments on the command line takes precedence over the pom

Description: the spring-boot.run.jvmArguments does not take precedence over the < systemPropertyVariables> map when there is a <jvmArguments> section defined for the spring-boot-maven-plugin.

Documented behavior: According to the https://docs.spring.io/spring-boot/docs/current/maven-plugin/examples/run-system-properties.html when the spring-boot.run.jvmArguments parameter is provided for the spring-boot:run command the parameter takes precedence and overwrites the system properties defined within the <systemPropertyVariables> XML configuration. I would expect that the presence of the jvmArguments section does not influence the documented behavior.

Steps to reproduce: There is a sample application which demonstrates non-documented (faulty?) behavior located at https://github.com/rawfg/maven-jvmargs.

  1. The sample application prints the system properties starting with the xyz and by default there are two system properties configured: one comes from the <jvmArguments> section and the other one comes from the < systemPropertyVariables> section.

  2. When the application is run from the command line via the command:

mvn spring-boot:run -Dspring-boot.run.jvmArguments="-Dxyz.MavenSystemProperty='cmd-system-property'" 

the output is (system properties configured in the pom.xml):

xyz.MavenSystemProperty=maven-system-property
xyz.MavenJvmProperty=maven-jvm-property
  1. When the <jvmArguments> section is commented out the application behaves as it was documented, so running the command:
mvn spring-boot:run -Dspring-boot.run.jvmArguments="-Dxyz.MavenSystemProperty='cmd-system-property'" 

results in the output:

xyz.MavenSystemProperty=cmd-system-property
  1. I tested it with the Spring Boot version 2.2.4 but I've downgraded to the 2.1.7 version and I observed the same outcome.

Expected behavior:

  • -Dspring-boot.run.jvmArguments always works as documented (step 3) or
  • the exception is documented in the https://docs.spring.io/spring-boot/docs/current/maven-plugin/examples/run-system-properties.html

closed time in 3 hours

rawfg

issue closedspring-io/spring-asciidoctor-extensions

Code blocks with multiple different titles do not toggle

This issue occurs in projects that have multiple code samples, and an inconsistent set of titles among the samples.

For example, consider a project that has one sample that toggles between Java and Kotlin and a different sample that toggles between Maven and Gradle.

In this case, the sample that toggles between Java/Kotlin will not allow toggling.

For a working example see https://docs.spring.io/spring-security/site/docs/5.3.x-SNAPSHOT/reference/html5/ (may change due to being a SNAPSHOT).

In the case of Spring Security, the only toggle that works is the Java/XML toggle, since it was defined last.

The remaining code samples (Java/XML/Kotlin, Maven/Gradle etc) do not allow toggling.

The root of this issue is the variable blockId. https://github.com/spring-io/spring-asciidoctor-extensions/blob/fdcd62577eaa4aa4cc22d16f362ed501193acc2b/block-switch/block-switch-core/src/main/resources/blockSwitch.js#L41 This is defined as a global variable, which means that it gets overwritten for each "switch--item" and ends up with the value of the last item.

closed time in 3 hours

eleftherias

issue commentspring-io/spring-asciidoctor-extensions

Code blocks with multiple different titles do not toggle

Oops. Thanks for the analysis, Ria. Thanks too for your PR. I'll close this in favour of it.

eleftherias

comment created time in 3 hours

issue commentspring-projects/spring-boot

Spring boot view resolver issue with thymeleaf

Circular view path [login]: would dispatch back to the current handler URL [/abcWeb/login] again. Check your ViewResolver setup!

This sounds like a problem with your Security configuration. It would happen if you login page was secured and Spring Security was then redirecting to your login page so that the user could log in.

I can't be certain that this is the case as you haven't shared enough information about your application. Please review your Spring Security configuration and check that access to your login page isn't restricted. If that doesn't help and you would like us to spend some more time investigating, please provide a complete and minimal sample that reproduces the behaviour you have described.

pankajpandey013

comment created time in 5 hours

issue commentspring-projects/spring-boot

Unlike all other Maven properties, spring-boot.run.arguments on the command line takes precedence over the pom

Re-opening so that we can investigate the test failures on Windows: https://ge.spring.io/s/m62r4fmeh6y6k/tests/failed.

scottfrederick

comment created time in 5 hours

IssuesEvent

issue commentspring-projects/spring-boot

Unlike all other Maven properties, spring-boot.run.arguments on the command line takes precedence over the pom

Re-opening so that we can investigate the test failures on Windows: https://ge.spring.io/s/m62r4fmeh6y6k/tests/failed.

rawfg

comment created time in 5 hours

pull request commentspring-projects/spring-boot

Implement possibility to set custom java home for Gradle tasks

Thanks once again, @dreis2211. The proposed changes are now on the master branch.

dreis2211

comment created time in 7 hours

push eventspring-projects/spring-boot

dreis2211

commit sha e599ed01c964761fc87f7b03885f95e9b7f93302

Allow Gradle tasks to be executed with a custom Java home See gh-20179

view details

Andy Wilkinson

commit sha 8f44bd89f47cc312ccd67979d6acfb3ab7df2766

Polish "Allow Gradle tasks to be executed with a custom Java home" See gh-20179

view details

Andy Wilkinson

commit sha b8276cb42820ae850439ed5c99c4c97c135b30c1

Merge pull request #20179 from dreis2211 * gh-20179: Polish "Allow Gradle tasks to be executed with a custom Java home" Allow Gradle tasks to be executed with a custom Java home Closes gh-20179

view details

push time in 7 hours

PR closed spring-projects/spring-boot

Implement possibility to set custom java home for Gradle tasks type: task

Hi,

as discussed in #20147 this PR should give us a first insight into what might be broken with JDK 14.

The new functionality can be used like this:

./gradlew -PcustomJavaHome=/Users/christoph.dreis/.sdkman/candidates/java/14-ea build

I specifically implemented a check for emptiness of the new property in preparation for an eventual CI. By that we could simply set it for JDK 14 builds and leave it empty for the others. That should keep the build-project.sh relatively simple.

Let me know what you think. Cheers, Christoph

+24 -2

12 comments

1 changed file

dreis2211

pr closed time in 7 hours

pull request commentspring-projects/spring-boot

Implement possibility to set custom java home for Gradle tasks

And almost immediately after writing the above, I realised that we need to call compile.getOptions().setFork(true). As expected, failures now occur when the configured Java home does not exist:

Execution failed for task ':spring-boot-project:spring-boot-tools:spring-boot-loader-tools:compileJava'.
> Supplied javaHome must be a valid directory. You supplied: /whatever
dreis2211

comment created time in 8 hours

pull request commentspring-projects/spring-boot

Implement possibility to set custom java home for Gradle tasks

Thanks for the updates, @dreis2211. I've polished this a bit (https://github.com/wilkinsona/spring-boot/commit/563083b25f50b0c18f5aeaa702e8045b52b64527) and in doing so, I think I've noticed the CompileJava tasks aren't using the custom Java home or javac executable. I can run a build with -PbuildJavaHome=/whatever and test and javadoc tasks will fail, but CompileJava tasks do not. I don't think I've introduced the problem while polishing, but I need to dig a bit more to be certain.

dreis2211

comment created time in 8 hours

create barnchwilkinsona/spring-boot

branch : gh-20179

created branch time in 8 hours

issue commentspring-projects/spring-boot

Integrate Gradle's flaky test mitigation into our build

Thanks for the offer, @mikesmithson. A pull request would be most welcome.

Rather than changing the root build.gradle, I think this should be handled in buildSrc. I'd imagined a dependency on org.gradle:test-retry-gradle-plugin:1.1.3 add then some code in our ConventionsPlugin that reacts to the Java plugin being applied by also applying and configuring the test retry plugin.

wilkinsona

comment created time in 8 hours

issue commentspring-projects/spring-boot

/actuator/env/{toMatch} returns 404

There's no property named activeProfiles so a 404 response is to be expected there. The fact that there's a body is intentional as it means that the response can still provide some information about the property sources that are available. See https://github.com/spring-projects/spring-boot/issues/10179 for details.

I'm going to flag this for team attention so that we can double-check that we agree the current behaviour is what we want. It's unconventional for the server to indicate that a resource doesn't exist (404 response) while including information in the response that is specific to the URI that was called.

hennr

comment created time in 9 hours

push eventwilkinsona/spring-boot

dreis2211

commit sha 442733600e2308d035489f4565d87987e537bea5

Test the Gradle plugin against Gradle 6.2.1 See gh-20310

view details

Stephane Nicoll

commit sha 000b6d302b72bc071ac99d6b5add92764ba2f132

Merge pull request #20310 from dreis2211 * pr/20310: Test the Gradle plugin against Gradle 6.2.1 Closes gh-20310

view details

Stephane Nicoll

commit sha f12c3c9d47f898337c82920ec004fd63eda4724b

Merge branch '2.2.x'

view details

dreis2211

commit sha 400db931fbabdf30a5e33dc38f097ca34952c902

Upgrade to Gradle 6.2.1 See gh-20309

view details

Stephane Nicoll

commit sha 25953460869757d711b2c41fb32d8ac2605fcb9b

Merge pull request #20309 from dreis2211 * pr/20309: Upgrade to Gradle 6.2.1 Closes gh-20309

view details

Andy Wilkinson

commit sha d4ff2b4197940e3c3397fdba23b047622684187b

Upgrade to Gradle 6.3 nightly build

view details

Andy Wilkinson

commit sha 81ebefbc9c9f8dffdb3ba6e1e3365dd0a5c98459

Upgrade to Kotlin 1.3.70 EAP

view details

Andy Wilkinson

commit sha 053f2eb077a7fb161e5df95f7a7a939303912a23

Ignore Gradle's instant execution state

view details

push time in 9 hours

create barnchwilkinsona/spring-boot

branch : instant-execution

created branch time in 9 hours

Pull request review commentspring-io/spring-javaformat

Fixed test with bad .java file(Wrong imports and annotations)

 		BANNED_IMPORTS = Collections.unmodifiableSet(bannedImports); 	} -	private static void addAnnotation(Set<String> annotations, String annotation) {

Sorry, I see what you mean now. I agree that just the simple names should be sufficient.

We try to keep issues and pull requests focused on a single change. To that end, would you mind splitting the corrections to JUnit5BadModifier and the simplifications above into separate pull requests?

davebarda

comment created time in 10 hours

issue commentspring-projects/spring-boot

Investigate "Failed to create volume" CI issues

The only change that I'm aware of is that @trevormarshall has been recreating the workers on a semi-regular basis. Trevor, any news from the Concourse team that might move things towards a solution?

dreis2211

comment created time in 11 hours

issue commentspring-projects/spring-restdocs

Spring rest docs with Streaming Responses

Duplicates #219. @cristianprofile please feel free to comment on that issue with any requirements you have, what you're particularly interested in, etc.

cristianprofile

comment created time in 11 hours

issue commentspring-projects/spring-boot

Logback console appender incomplete thread name

Unfortunately, I don't think that [%15t] is a solution for both worlds. It will be a breaking change for users who want the information that is logged to the right of the thread name to line up and who have one or more threads with a name that's greater than 15 characters in length.

cdalexndr

comment created time in 11 hours

issue commentspring-projects/spring-boot

Outdated library prevents server startup

One of auto-configuration's key features is to enable functionality based on what's available on the classpath. I would recommend encouraging your users to make use of Spring Boot's dependency management to influence the version of any additional dependencies that they are adding. If you are in a situation where you need to give your users free rein to add anything to the classpath, auto-configuration may not be a good fit for your use case.

Setting that aside for now, I do not think that it would be possible to distinguish with 100% accuracy between a failure that should only be logged and one that should stop the application from starting up. I expect that an attempt to implement this would add a significant amount of complexity and would be a source of a lot of bugs as cases that are handled incorrectly are identified.

I think our best option here is to identify and fix problems on a case-by-case basis. That will allow us to consider each case individually and decide if it's better for a particular piece of auto-configuration to back off when and older version of a library is present or if we should tolerate some incompatibilities via catching NoSuchMethodError and the like. I propose that we use this issue to consider what to do for GSON. Please feel free to raise additional issues for other similar problems as you encounter them.

stovocor

comment created time in 11 hours

issue commentspring-projects/spring-boot

spring-boot-starter-rsocket pom contains security dependencies

🤦‍♂ Thanks for spotting and reporting this, @rwinch. Not quite sure how I managed that during the migration.

rwinch

comment created time in 12 hours

issue commentspring-projects/spring-boot

Outdated library prevents server startup

We have a few places in our auto-configuration and in our web server support where we back off if an older version is on the classpath (via @ConditionalOnClass) or where we catch NoSuchMethodError to tolerate older versions. I think we should do one of those two things for our GSON auto-configuration.

stovocor

comment created time in 12 hours

issue commentspring-projects/spring-boot

Rewrite Actuator MVC adapter layer for Servlet Functional Endpoints

@bclozel missing "not" in "so no, this should break backwards compatibility"?

bclozel

comment created time in 12 hours

issue commentspring-projects/spring-boot

Liquibase 3.8.2 not working on Java 11

Thanks for the suggestion, @mpretzer. Situations like this are never easy to deal with as it isn't possible to please everyone. On the one hand, we will have users who are relying upon a bug fix in the latest 3.8.x release of Liquibase and who are unaffected by the unwanted side-effects. On the other hand, we will have users like you who would prefer to stick with 3.8.0 for the time being. In the absence of a solution that will work for everyone, leaving things as they are feels like the least disruptive option.

For those trying to follow along, there are a few Liquibase issues mentioned above. The one that is tracking the META-INF/services/ problem is CORE-3522.

@SteveDonie please let us know if there's anything that the Spring Boot team can do to help with diagnosing CORE-3522 and how Spring Boot's users are affected.

filiphr

comment created time in 12 hours

Pull request review commentspring-io/spring-javaformat

Fixed test with bad .java file(Wrong imports and annotations)

 		BANNED_IMPORTS = Collections.unmodifiableSet(bannedImports); 	} -	private static void addAnnotation(Set<String> annotations, String annotation) {

if we are using only the non FQN

I don't think we can't be certain that this is the case. One user could write @org.junit.Test while another could write @Test along with import org.junit.Test.

davebarda

comment created time in 12 hours

push eventspring-projects/spring-boot

Andy Wilkinson

commit sha 487328e4c006f97767ba845e84ed4ebc8e751f7a

Configure user name used for Gradle CI builds Closes gh-20312

view details

push time in 12 hours

issue commentspring-projects/spring-boot

spring.jackson.serialization.indent-output doesn't work with Spring Boot 2.3.0.M2 when using Actuator

Fixed by https://github.com/spring-projects/spring-boot/commit/ab72cc8fdbc55adf54a8c33371b77e7f8d9782e1 which reverted the first attempt at providing an Actuator-specific ObjectMapper.

izeye

comment created time in 13 hours

issue commentspring-projects/spring-boot

spring.jackson.serialization.indent-output doesn't work with Spring Boot 2.3.0.M2 when using Actuator

We need something in the M3 release notes to indicate that the regression's been fixed. I think we should use this issue to do that.

izeye

comment created time in 13 hours

issue commentspring-projects/spring-boot

Embedded Database - Prevent automatic dropping of tables.

@corneel We've changed our minds in the past and I am sure that we will again in the future, but this isn't a good way to ask us to do so. It leaves us frustrated as we struggle to assume positive intent and it leaves you frustrated as your suggestion isn't given serious consideration.

If you would like us to consider a change in behaviour here, please open a new issue that explains the problem that the current behaviour causes and what you think a better default would be.

kennyk65

comment created time in 13 hours

issue closedspring-projects/spring-boot

Logback console appender incomplete thread name

The logback console appender configured in https://github.com/spring-projects/spring-boot/blob/e73ee7b3fe2679e67685c3672493f9f9a9f9406f/spring-boot-project/spring-boot/src/main/resources/org/springframework/boot/logging/logback/defaults.xml#L11 logs thread name up to 15 characters: [%15.15t] causing logged thread names to be incomplete. The file log pattern logs the full thread name: [%t].

Console log pattern should be production ready and expected to be used for log parsing, so it must contain whole information.

Example use case: Using spring boot inside a docker container, the console output will be used by docker logs command and parsed by some log extracting service (elasticsearch filebeat).

Note that console pattern is defined in multiple files. For finding all files, search for [%15.15t] in all files.

closed time in 13 hours

cdalexndr

issue commentspring-projects/spring-boot

Logback console appender incomplete thread name

Thanks for the suggestion.

The use of a limited length for the thread name is intentional as it ensures that each column in the log output is of a fixed width. This ensures that the name of the logger and the message appear in the same place in each line that is logged. This aids human readability which we feel is important for console output.

This is a situation where there's no one answer that will be right for everyone. I can see the benefit of logging the complete thread name for some users but I can also see that it would be a breaking and unwanted change for others. Given that, leaving things as-is feels like the better option.

If you require a particular format for the console log output to meet your parsing requirements, please configure the console log pattern accordingly. You can do so using logging.pattern.console.

cdalexndr

comment created time in 13 hours

push eventspring-projects/spring-boot

Andy Wilkinson

commit sha cb2e3bd076ace6b8d955998a9a6a7aba189e8bd9

Upgrade to Reactor Californium-SR16 Closes gh-20196

view details

Andy Wilkinson

commit sha b4e0d52da58e9465220404676cbebc63c5b3e6b1

Merge branch '2.1.x' into 2.2.x

view details

Andy Wilkinson

commit sha 2059ff6c3968e76218069639299934b690e02756

Upgrade to Reactor Dysprosium-SR5 Closes gh-20200

view details

push time in 13 hours

push eventspring-projects/spring-boot

Andy Wilkinson

commit sha cb2e3bd076ace6b8d955998a9a6a7aba189e8bd9

Upgrade to Reactor Californium-SR16 Closes gh-20196

view details

Andy Wilkinson

commit sha b4e0d52da58e9465220404676cbebc63c5b3e6b1

Merge branch '2.1.x' into 2.2.x

view details

Andy Wilkinson

commit sha 2059ff6c3968e76218069639299934b690e02756

Upgrade to Reactor Dysprosium-SR5 Closes gh-20200

view details

Andy Wilkinson

commit sha 216ccc9b9f00bea75967cd85e979a9de444b06f8

Merge branch '2.2.x'

view details

push time in 13 hours

push eventspring-projects/spring-boot

Andy Wilkinson

commit sha cb2e3bd076ace6b8d955998a9a6a7aba189e8bd9

Upgrade to Reactor Californium-SR16 Closes gh-20196

view details

push time in 13 hours

issue closedspring-projects/spring-boot

Neo4J connection timed out in Spring Boot 2.2.4 but not in 2.0.5

As described on Stackoverflow I have an issue which might be caused by some versions of Spring Boot dependencies.

I have a Spring Boot app on version 2.2.4, which can connect to a local Docker instance of Neo4J. Also in a CI/CD pipeline, the app connects correctly to the docker. The problem arises when trying to connect to a neo4j vm instance on the Google Cloud Platform. The first thing that came to mind was a faulty network configuration, but after triple checking everything I tried with a very basic spring boot app which happened to run on version 2.0.5. With that project I could connect to every instance both locally and in the cloud. After that I ported the dependencies and app configuration one by one to my 2.2.4 app. It didn't work. Then when I tried version 2.0.5 there it worked again.

This is my build.gradle: image -> I also tried removing the org.neo4j.driver dependency as someone mentioned in the comments.

This are the versions that are effectively installed: image

And here is my application.properties:

spring.data.neo4j.uri=bolt://35.xxx.xxx.xxx:7687 # <- in prod
spring.data.neo4j.uri=bolt://localhost:7687 # <- in dev
spring.data.neo4j.uri=bolt://neo4j:7687 # <- in CI/CD
spring.data.neo4j.username=neo4j
spring.data.neo4j.password=****
spring.data.neo4j.embedded.enabled=false

closed time in 13 hours

jclaessens97

push eventspring-projects/spring-boot

Andy Wilkinson

commit sha 5ae66d4c08ef173a88c4ab5ef0c6a90f99377a61

Start building against Spring Framework 5.1.14 snapshots See gh-20197

view details

Andy Wilkinson

commit sha 29bc5d848e1351f4f7e98cd55d6186650fb7ee35

Start building against Spring Data Lovelace-SR16 snapshots See gh-20198

view details

push time in 6 days

push eventspring-projects/spring-boot

Andy Wilkinson

commit sha 5ae66d4c08ef173a88c4ab5ef0c6a90f99377a61

Start building against Spring Framework 5.1.14 snapshots See gh-20197

view details

Andy Wilkinson

commit sha 29bc5d848e1351f4f7e98cd55d6186650fb7ee35

Start building against Spring Data Lovelace-SR16 snapshots See gh-20198

view details

Andy Wilkinson

commit sha 319ac968f6c9d2e09c1b7b66ad061720008f9cb7

Merge branch '2.1.x' into 2.2.x

view details

push time in 6 days

push eventspring-projects/spring-boot

Andy Wilkinson

commit sha 5ae66d4c08ef173a88c4ab5ef0c6a90f99377a61

Start building against Spring Framework 5.1.14 snapshots See gh-20197

view details

Andy Wilkinson

commit sha 29bc5d848e1351f4f7e98cd55d6186650fb7ee35

Start building against Spring Data Lovelace-SR16 snapshots See gh-20198

view details

Andy Wilkinson

commit sha 319ac968f6c9d2e09c1b7b66ad061720008f9cb7

Merge branch '2.1.x' into 2.2.x

view details

Andy Wilkinson

commit sha 56475c19fb749a26502ef632a0ed8fce9f8df358

Merge branch '2.2.x'

view details

push time in 6 days

pull request commentspring-projects/spring-boot

reformatting namespace 'ext' from Liquibase databaseChangelog element to fix local test failures

Is this the only time you've ever heard of an external contributor having this issue?

Yes, it is.

I guess my expectation is that I would simply clone and run './gradlew build' without having to configure a local machine to be able to run a full end-to end build.

Barring any environmental issues, that's my expectation too.

mikesmithson

comment created time in 6 days

PR closed spring-projects/spring-boot

reformatting namespace 'ext' from Liquibase databaseChangelog element to fix local test failures status: feedback-provided status: waiting-for-triage

this is a change to db.changelog-override.xml to fix LiquibaseAutoConfigurationTests#changelogXml() test to fix a local test failure.

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

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 #. -->

+14 -15

4 comments

1 changed file

mikesmithson

pr closed time in 6 days

pull request commentspring-projects/spring-boot

reformatting namespace 'ext' from Liquibase databaseChangelog element to fix local test failures

Is there a reason why the test Liquibase xml's are using https and not http in them?

Yes, using HTTP introduces the risk of a man-in-the-middle attack. We moved to HTTPS (and enforce it via NoHttp) to avoid the problem described in this blog post.

I think the problem with HTTPS must be specific to your environment. It works fine on CI and on the local machines of everyone else that I'm aware of. Thanks for you efforts here, but we won't be able to make a switch from https to http so I'm going to close this pull request.

mikesmithson

comment created time in 6 days

issue openedreactor/reactor-core

Regression in Flux.cache in latest Californium snapshots

Expected Behavior

Flux.cache should cache emitted signals and replay them

Actual Behavior

Signals are not cached

Steps to Reproduce

@Test
public void fluxCaching() {
    AtomicInteger invocations = new AtomicInteger();
    Flux<String> flux = Flux.fromIterable(() -> {
        invocations.incrementAndGet();
        return Arrays.asList("spring", "boot").iterator();
    }).cache(Duration.ofHours(1));
    assertThat(flux.blockLast()).isEqualTo("boot");
    assertThat(flux.blockLast()).isEqualTo("boot");
    assertThat(invocations).hasValue(1);
}

The above fails with Californium-BUILD-SNAPSHOT as the value of invocations is 2. It passes with SR-15.

The problem is also reproduced by Spring Boot's test suite which is how I discovered the problem. See https://github.com/spring-projects/spring-boot/issues/20196.

Your Environment

  • Californium-BUILD-SNAPSHOT
  • Java 1.8.0_202
  • macOS

created time in 6 days

issue commentspring-projects/spring-boot

Upgrade to Reactor Californium-SR16

Current Californium snapshots cause a test in spring-boot-actuator to fail:

[INFO] Results:
[INFO] 
[ERROR] Failures: 
[ERROR]   CachingOperationInvokerTests.cacheInTtlWithFluxResponse:94 expected:<[1]> but was:<[2]>
[INFO] 
[ERROR] Tests run: 963, Failures: 1, Errors: 0, Skipped: 0

It appears that Flux caching doesn't work. The pure Reactor test passes with SR-15 but fails with the current BUILD-SNAPSHOT of Californium:

	@Test
	public void fluxCaching() {
		AtomicInteger invocations = new AtomicInteger();
		Flux<String> flux = Flux.fromIterable(() -> {
			invocations.incrementAndGet();
			return Arrays.asList("spring", "boot").iterator();
		}).cache(Duration.ofHours(1));
		assertThat(flux.blockLast()).isEqualTo("boot");
		assertThat(flux.blockLast()).isEqualTo("boot");
		assertThat(invocations).hasValue(1);
	}

The test fails because the value of invocations is two.

wilkinsona

comment created time in 6 days

issue closedspring-projects/spring-boot

After upgrade from SB.2.2.0 to SB2.2.1 and higher, SB cannot drop tables between tests

When running multiple tests using H2 embedded db, the subsequent tests fail as the hibernate cannot drop and create tables between tests. As the result the tests see "dirty" database from previous tests.

The tets pass if run individually. The whole application tests pass in SB2.2.0 but fail after the version bump.

Hibernates generates warnings during tests starts:

org.hibernate.tool.schema.spi.CommandAcceptanceException: Error executing DDL "drop table user_account if exists" via JDBC Statement
... ...
Caused by: org.h2.jdbc.JdbcSQLSyntaxErrorException: Cannot drop "USER_ACCOUNT" because "FK5XL7CHEG2RTTVSNCL6B1TVT1M, FK6UTG5IJMPW6B2WCUKCYS5RBFP" depends on it; SQL statement:
drop table user_account if exists [90107-200]

Then

org.hibernate.tool.schema.spi.CommandAcceptanceException: Error executing DDL "create table user_account ....
Caused by: org.h2.jdbc.JdbcSQLSyntaxErrorException: Table "USER_ACCOUNT" already exists;

And finally the second test which run fails cause of an attempted insert with the exsitng ID.

A maven project with one entity class, and two tests that fails if run togheter is under:

https://github.com/tzielins/SB2.2.4-ISSUE

closed time in 6 days

tzielins

issue commentspring-projects/spring-boot

After upgrade from SB.2.2.0 to SB2.2.1 and higher, SB cannot drop tables between tests

This is caused by a change in H2 with which Hibernate is not compatible. Please see https://github.com/spring-projects/spring-boot/issues/19666#issuecomment-578421774 for details.

tzielins

comment created time in 6 days

issue commentspring-io/issue-bot

Waiting for feedback label is removed too early in some edge cases

Yeah, that's right. It'd have to get a bit more sophisticated as we'd need to reset and start the clock when feedback-provided is removed and waiting-for-feedback remains. If we didn't reset it, the reporter might not get a reasonable amount of time to respond.

dreis2211

comment created time in 6 days

issue commentspring-projects/spring-boot

Remove TODO and FIXME comments from tests

@slavisah Thank you very much for the offer, but I think it's probably easiest if the core team take care of these.

philwebb

comment created time in 6 days

issue commentspring-projects/spring-boot

Support flexible duration parsing in placeholders for @Scheduled annotations

Thanks for the SpEL-based workaround.

I'm not sure if there any plans of including / moving DurationStyle in Spring Framework.

As noted above, @manderson23 opened a Framework issue for this: https://github.com/spring-projects/spring-framework/issues/22013.

manderson23

comment created time in 6 days

pull request commentspring-projects/spring-boot

Implement possibility to set custom java home for Gradle tasks

@dres2211 Thanks again for your work on this one. We discussed it and the broader topic today and concluded that we'd like two properties:

  1. buildJavaHome for controlling the Java home that's used for the whole build. This should affect compilation, javadoc, and tests
  2. testJavaHome for controlling the Java home that's used for tests.

We'll use testJavaHome on CI so that we can test Java 8-compiled byte code with later JDKs. This will cover what users are doing with our published binaries. We'll then use buildJavaHome on our own machines while exploring compatibility with JDKs that Gradle itself cannot yet run on.

This PR pretty much covers 1, other than renaming customJavaHome to buildJavaHome. If you have time to make that tweak, that'd be much appreciated, otherwise we can handle it as part of merging. We'll then add the other property as a separate task.

dreis2211

comment created time in 6 days

issue commentspring-projects/spring-boot

MetricsWebMvcConfigurer bean should take a list of WebMvcTagsProviders

@jfernandez We're going to explore the contributor approach. Out of interest, can you share with us some details of the sorts of tags that you want to be able to add?

jfernandez

comment created time in 6 days

issue openedspring-projects/spring-boot

Metrics are not recorded for nested requests made with RestTemplate

We need to back-port the fix for #19464 to 2.2.x.

created time in 6 days

PR closed spring-projects/spring-boot

Add shared jar launcher to core launcher implementations for: team-attention status: feedback-provided status: waiting-for-triage

We use this in production as it helps with different service runners (mainly to support windows proc-run that send stop/retart commands via the same open jvm and its running classloader)

The shared jar launcher means its possible to send commands to the same open service loaded via spring-boot

+63 -0

6 comments

1 changed file

alero

pr closed time in 6 days

pull request commentspring-projects/spring-boot

Add shared jar launcher to core launcher implementations

Thanks for the suggestion. We've discussed this today and the team have decided that we do not want to add shared launcher support to Spring Boot at this time. We haven't seen sufficient demand for the functionality to justify the ongoing maintenance cost. Thanks anyway.

alero

comment created time in 6 days

issue commentspring-projects/spring-boot

Ensure precedence of Maven command-line properties and POM configuration is consistent

We're going to align with Maven's defaults.

rawfg

comment created time in 6 days

issue commentspring-projects/spring-boot

Actuator 'loggers' endpoint does not return all loggers for log4j

That's good to know. Thank you.

alawrenc

comment created time in 6 days

push eventspring-io/start.spring.io

Eddú Meléndez

commit sha b87c125f9620e7d54c443368fa699d4fe23e50d0

Rename package from kotin to kotlin See gh-389

view details

Andy Wilkinson

commit sha 4265e9e56d4d1ca17b88aecf47214c603dd90ff8

Merge pull request #389 from eddumelendez * gh-389: Rename package from kotin to kotlin Closes gh-389

view details

push time in 6 days

pull request commentspring-io/start.spring.io

Rename package from kotin to kotlin

Well spotted, @eddumelendez. Thank you.

eddumelendez

comment created time in 6 days

pull request commentspring-projects/spring-boot

removing namespace 'ext' from databasechangelog element

Thanks for the suggestion.

The Liquibase FAQ includes the ext namespace declaration and does the XML format example. While the XML file you've altered doesn't, I think, use the namespace, I'm reluctant to remove it as we'd no longer be verifying that a changelog with the recommended namespaces works with Spring Boot.

Have you been able to determine why it fails for you locally?

mikesmithson

comment created time in 6 days

CommitCommentEvent
CommitCommentEvent
CommitCommentEvent

issue commentspring-gradle-plugins/dependency-management-plugin

Unexpected dynamic dependency version resolution

I think I can further refine the fixes for #77 and #151 so that the problem described here doesn't occur. With that change in place, all the existing tests pass other than the test that verifies compatibility with the versions plugin. I believe a further refinement that would also work with the Versions plugin is possible, but it requires Gradle 5.1 or later.

That leaves three options:

  1. Accept the problem described in this issue as a known limitation
  2. Fix the problem now and break compatibility with the Versions plugin
  3. Raise the supported version of Gradle to 5.1 and fix the problem then

I know from issues that have been raised in the past that option 2 will cause a problem for existing users. Option 1 is a bit of a cop-out so that leaves option 3.

A change in the minimum supported version of Gradle is long over due with the plugin currently supporting Gradle 2.9 and later and the current latest version of Gradle being 6.2. Spring Boot 2.3 milestones have raised the minimum supported version of Gradle to 5.6.x. A new version of this plugin with a similar requirement increasingly makes sense at this point.

GFriedrich

comment created time in 6 days

issue commentspring-projects/spring-boot

Websocket broker disconnects when client enable heartbeats

1002 indicates that the connection was closed due to a protocol error. Without some more information, the code alone isn't enough to confirm that it's the same issue as was originally reported here. If you can capture the problem with debug or trace logging enabled, that may help to determine the nature of the error. If you manage to do that or you can provide a minimal sample that reproduces the problem, please open a new issue and we can investigate.

rd-o

comment created time in 6 days

issue commentspring-gradle-plugins/dependency-management-plugin

Unexpected dynamic dependency version resolution

Digging a bit more, the fix for https://github.com/spring-gradle-plugins/dependency-management-plugin/issues/151 didn't introduce the problem.

In #77 (0.6.0) any dependency with a dynamic version was ignored completely. In #151 (1.0.1) that was refined so that only direct dependencies with dynamic versions were ignored. The sample fails in the same way with 1.0.1 of the plugin as it does with 1.0.9.

The problem that we have now is that the dependency is declared both directly and transitively and distinguishing between the two is problematic.

GFriedrich

comment created time in 6 days

pull request commentspring-projects/spring-boot

Include licence and notice files in shipped jars

Thanks very much, @dreis2211.

dreis2211

comment created time in 7 days

push eventspring-projects/spring-boot

dreis2211

commit sha e34cf8955c9ce969f82941479df58f462e004f7c

Include LICENCE and NOTICE files in shipped jars See gh-20058

view details

Andy Wilkinson

commit sha 8128f3090af9c3701bbdc7d99ff62bf9dd95d268

Polish "Include LICENCE and NOTICE files in shipped jars" See gh-20058

view details

Andy Wilkinson

commit sha d73366570a8cd5f3710b7dc13e1ac33982c13650

Merge pull request #20058 from dreis2211 * gh-20058: Polish "Include LICENCE and NOTICE files in shipped jars" Include LICENCE and NOTICE files in shipped jars Closes gh-20058

view details

push time in 7 days

PR closed spring-projects/spring-boot

Include licence and notice files in shipped jars for: merge-with-amendments type: task

Hi,

this PR includes the LICENSE.txt file in the META-INF directory when a jar is built. This should fix #15643 .

Let me know what you think. Cheers, Christoph

+342 -0

8 comments

4 changed files

dreis2211

pr closed time in 7 days

issue commentspring-io/start.spring.io

很棒的框架初始化功能,希望Python也应该有一个

From Google translate:

Great framework initialization function, hope that Python should also have one

Thank you for your kind words about start.spring.io. Our focus is on Spring and the JVM so providing something for Python is out of scope.

lushubeivip

comment created time in 7 days

issue closedspring-projects/spring-boot

org.springframework.boot.loader.jar.JarURLConnection doesnot work under some condition

The springboot support url format like this

jar:file:/xxx/xxx-jar!/yyy-jar!/zzz.xml

But in my application, my url format is like this:

jar:file:/xxx/xxx-jar!/www-jar!/yyy-jar!/zzz.xml

There is one more jar in it, but JarURLConnection cannot support this scenario,I hope you can improve it, the only thing we should do is just one line of code below.

org.springframework.boot.loader.jar.JarURLConnection line 273

The code is

  	JarEntry jarEntry = jarFile.getJarEntry(entryName.toCharSequence());

this should be changed to

  	JarEntry jarEntry = connectionJarFile.getJarEntry(entryName.toCharSequence());

I had tried, it worked very well.I even think it is a bug.

Thanks!

closed time in 7 days

islandoo

issue commentspring-projects/spring-boot

org.springframework.boot.loader.jar.JarURLConnection doesnot work under some condition

I disagree that your application is irrelevant to this issue. Seeing your application, or some equivalent code that reproduces the problem, would have allowed us to be certain that we understand the problem you're seeing.

From the information that you have provided, it sounds like you are trying to nest one fat jar within another. This isn't supported at the moment and we do not have any plans to support it in the future. Adding support would introduce too much complexity for insufficient benefit. Unfortunately, there is quite a bit more to it than just dealing with multiple !/ entries in the URL.

I would recommend that you revisit the packaging of your application so that only the outer-most jar is a fat jar and all the jars nested within it are standard jar files.

Thank you anyway for the suggestion. If I have misunderstood what you are trying to do, please provide a small sample (it need not be your actual application) that reproduces the problem and we can take another look.

islandoo

comment created time in 7 days

issue commentspring-projects/spring-boot

Custom datasource is not using the hikari configuration from the property file and using the default configuration

Can you please expand a bit on what you mean by a “custom DataSource”? If you have defined your own DataSource bean, it will only use the configuration properties if you’ve configured it to do so.

If you’d like is to spend some time investigating, please spend some time to provide a minimal example that reproduces the problem You can share it with us in a separate repository on GitHub or as a zip file attached to this issue.

sohailashraf003

comment created time in 7 days

issue commentspring-projects/spring-boot

org.springframework.boot.loader.jar.JarURLConnection doesnot work under some condition

@islandoo Thank you for the report and analysis of the problem. Before we can consider making a change, we will need to understand exactly what’s happening. To help is to do that, please provide a small sample that reproduces the problem you have described.

islandoo

comment created time in 7 days

issue commentspring-projects/spring-boot

Remove default favicon

@hanryusan That’s unrelated to this issue as, with or without a default favicon, the location will change if you configure a context path. In that case you should link to the favicon.

vpavic

comment created time in 7 days

issue commentspring-projects/spring-boot

Auto configuration of MethodValidationPostProcessor uses autowiring

We have a number of auto-configuration classes of our own that @Import an ImportBeanDefinitionRegistrar and we haven't seen any problems with beans not being eligible for post-processing. I'd like to make sure that we fully understand the problem before making a change. @AlesD, to help us to do that, can you please provide a small sample that reproduces the behaviour you have described?

AlesD

comment created time in 7 days

pull request commentspring-projects/spring-boot

Upgrade to Gradle 6.2

No apology is necessary. You are still approximately 12323549783489723 in credit.

dreis2211

comment created time in 7 days

pull request commentspring-projects/spring-boot

Upgrade to Gradle 6.2

I just tried it and gradlew.bat wasn't updated:

$ git reset --hard 16111f126e707fb5064bab6150df7a77f54850ee
HEAD is now at 16111f126e Use query-less datasource validation by default
$ ./gradlew --no-scan --version

------------------------------------------------------------
Gradle 6.1.1
------------------------------------------------------------

Build time:   2020-01-24 22:30:24 UTC
Revision:     a8c3750babb99d1894378073499d6716a1a1fa5d

Kotlin:       1.3.61
Groovy:       2.5.8
Ant:          Apache Ant(TM) version 1.10.7 compiled on September 1 2019
JVM:          1.8.0_202 (Oracle Corporation 25.202-b08)
OS:           Mac OS X 10.13.6 x86_64

$ ./gradlew wrapper --gradle-version=6.2 --no-scan
Starting a Gradle Daemon, 1 incompatible Daemon could not be reused, use --status for details

BUILD SUCCESSFUL in 38s
1 actionable task: 1 executed

$ git diff HEAD
warning: CRLF will be replaced by LF in gradlew.bat.
The file will have its original line endings in your working directory
diff --git a/gradle/wrapper/gradle-wrapper.properties b/gradle/wrapper/gradle-wrapper.properties
index 1b16c34a71..b7c8c5dbf5 100644
--- a/gradle/wrapper/gradle-wrapper.properties
+++ b/gradle/wrapper/gradle-wrapper.properties
@@ -1,5 +1,5 @@
 distributionBase=GRADLE_USER_HOME
 distributionPath=wrapper/dists
-distributionUrl=https\://services.gradle.org/distributions/gradle-6.1.1-bin.zip
+distributionUrl=https\://services.gradle.org/distributions/gradle-6.2-bin.zip
 zipStoreBase=GRADLE_USER_HOME
 zipStorePath=wrapper/dists

If I run the wrapper task again, it updates gradlew.bat:

$ ./gradlew wrapper --gradle-version=6.2 --no-scan

BUILD SUCCESSFUL in 4s
1 actionable task: 1 executed
$ git diff HEAD
warning: CRLF will be replaced by LF in gradlew.bat.
The file will have its original line endings in your working directory
diff --git a/gradle/wrapper/gradle-wrapper.properties b/gradle/wrapper/gradle-wrapper.properties
index 1b16c34a71..b7c8c5dbf5 100644
--- a/gradle/wrapper/gradle-wrapper.properties
+++ b/gradle/wrapper/gradle-wrapper.properties
@@ -1,5 +1,5 @@
 distributionBase=GRADLE_USER_HOME
 distributionPath=wrapper/dists
-distributionUrl=https\://services.gradle.org/distributions/gradle-6.1.1-bin.zip
+distributionUrl=https\://services.gradle.org/distributions/gradle-6.2-bin.zip
 zipStoreBase=GRADLE_USER_HOME
 zipStorePath=wrapper/dists
diff --git a/gradlew.bat b/gradlew.bat
index 9618d8d960..62bd9b9cce 100644
--- a/gradlew.bat
+++ b/gradlew.bat
@@ -29,6 +29,9 @@ if "%DIRNAME%" == "" set DIRNAME=.
 set APP_BASE_NAME=%~n0
 set APP_HOME=%DIRNAME%
 
+@rem Resolve any "." and ".." in APP_HOME to make it shorter.
+for %%i in ("%APP_HOME%") do set APP_HOME=%%~fi
+
 @rem Add default JVM options here. You can also use JAVA_OPTS and GRADLE_OPTS to pass JVM options to this script.
 set DEFAULT_JVM_OPTS="-Xmx64m" "-Xms64m"

Looks like you've found a bug.

dreis2211

comment created time in 7 days

pull request commentspring-projects/spring-boot

Upgrade to Gradle 6.2

FWIW, I think what you did to upgrade from 6.1 to 6.2 is right, @dreis2211. What I did (not specifying the version number) only worked because you'd already done the upgrade. Running ./gradlew wrapper --gradle-version=6.2 on 16111f126e707fb5064bab6150df7a77f54850ee (the commit immediately before the upgrade to 6.2) should update gradlew.bat, AFAIK.

dreis2211

comment created time in 7 days

pull request commentspring-projects/spring-boot

Upgrade to Gradle 6.2

Yeah, I'm on a Mac. I ran ./gradlew wrapper --no-scan.

dreis2211

comment created time in 7 days

issue closedspring-projects/spring-boot

Include licence files in shipped jars

@mp911de noticed that we don't include license/notice files inside our JARs whereas Spring Framework does. We do have copyright on each file and a license in our POM but we should consider if we also want to include it in the shipped JARs.

closed time in 7 days

philwebb

issue commentspring-projects/spring-boot

Include licence files in shipped jars

Closing in favour of #20058.

philwebb

comment created time in 7 days

pull request commentspring-projects/spring-boot

Include licence files in shipped jars

It's just occurred to me that the suggestion to use ${currentYear} was a bad one as it'll break the repeatability of the build. We should probably just hardcode it and update as needed. We can make that amendment as part of merging.

dreis2211

comment created time in 7 days

pull request commentspring-projects/spring-boot

Upgrade to Gradle 6.2

Good catch, @vpavic. Thank you. I've pushed the updates to gradlew.bat in https://github.com/spring-projects/spring-boot/commit/d8c309a31080f2db548178558522fc11769dd60c.

dreis2211

comment created time in 7 days

push eventspring-projects/spring-boot

Andy Wilkinson

commit sha d8c309a31080f2db548178558522fc11769dd60c

Update gradlew.bat with Gradle 6.2's changes See gh-20213

view details

push time in 7 days

pull request commentspring-projects/spring-boot

Upgrade to Gradle 6.2

If you have the time to do that, that'd be great. Thanks!

dreis2211

comment created time in 7 days

more