В чем разница между "STS - Run As - Spring Boot App" и использованием "gradlew bootRun" для запуска Spring Boot Application?

Question

Spring Boot Версия: 2.1.5.RELEASE

У меня есть простое приложение Spring Boot MVC, которое использует Redis для хранения весенних сессий.

spring:

  session:
    store-type: redis

    redis:
      flush-mode: on-save
      namespace: spring:session

  redis:
    host: localhost
    password: 
    port: 6379
    database: 0

Когда я запускаю его на STS («Запуск от имени» - «Spring Boot App»), он использует мою установку Redis для хранения сеансов.Я вижу ключи, добавленные в Redis (ключи *).

Но, когда я запускаю его с помощью bootRun в командной строке, все, что связано с сессиями, кажется, работает нормально, но я не вижу ключей на сервере Redis.Кажется, что он даже не подключается к моему серверу Redis.Я даже могу безопасно отключить Redis, ничего не затрагивая.

Я убедился, что у меня одинаковые системные свойства между двумя режимами работы.В чем может быть разница?Где это может быть подключение в последнем сценарии?

[EDIT]

Что-то, что я заметил в файлах журнала после включения TRACE на org.springframework.session -

Когдазапустить на STS, я вижу эти записи журнала (ожидается) -

2019-06-27 14:23:47.086 DEBUG No session found by id: Caching result for getSession(false) for this HttpServletRequest. | HP-20111108 | org.springframework.session.web.http.SessionRepositoryFilter.SESSION_LOGGER | nio-8080-exec-1 
2019-06-27 14:23:47.087 DEBUG A new session was created. To help you troubleshoot where the session was created we provided a StackTrace (this is not an error). You can prevent this from appearing by disabling DEBUG logging for org.springframework.session.web.http.SessionRepositoryFilter.SESSION_LOGGER | HP-20111108 | org.springframework.session.web.http.SessionRepositoryFilter.SESSION_LOGGER | nio-8080-exec-1 
java.lang.RuntimeException: For debugging purposes only (not an error)
    at org.springframework.session.web.http.SessionRepositoryFilter$SessionRepositoryRequestWrapper.getSession(SessionRepositoryFilter.java:332) [spring-session-core-2.1.6.RELEASE.jar:2.1.6.RELEASE]
    at org.springframework.session.web.http.SessionRepositoryFilter$SessionRepositoryRequestWrapper.getSession(SessionRepositoryFilter.java:354) [spring-session-core-2.1.6.RELEASE.jar:2.1.6.RELEASE]
    .....
2019-06-27 14:24:00.003 DEBUG Cleaning up sessions expiring at Thu Jun 27 14:24:00 CDT 2019 | HP-20111108 | org.springframework.session.data.redis.RedisSessionExpirationPolicy | pool-2-thread-1 

При запуске с использованием bootRun, это единственная запись в журнале, которую я вижу -

2019-06-27 14:27:05.936  WARN Creation of SecureRandom instance for session ID generation using [SHA1PRNG] took [382] milliseconds. | HP-20111108 | org.apache.catalina.util.SessionIdGeneratorBase | nio-8080-exec-1

Возможно, Tomcat вступает во владениеуправление сессией при запуске с помощью bootRun?Как это происходит?

Answer 1

Черт!Кажется, это была моя вина.Мой проект в СТС был выключен.Это проект Gradle, и я внес в него некоторые изменения и не знал, что должен был выполнить «Обновить проект Gradle».В любом случае, они синхронизированы и ведут себя одинаково, но печально то, что оба ведут себя не так (не использует Redis), но я думаю, что это отдельная проблема.