1. 22 3月, 2019 1 次提交
  2. 20 3月, 2019 1 次提交
    • S
      Update documentation for WebJar support · ef11aa45
      Sam Brannen 提交于
      Prior to this commit, documentation for WebJar support referenced the
      webjars-locator artifact; however, Spring now uses the
      webjars-locator-core artifact.
      
      This commit updates the documentation to reflect this.
      
      Closes gh-22613
      ef11aa45
  3. 28 6月, 2018 1 次提交
  4. 23 6月, 2018 1 次提交
  5. 09 3月, 2018 1 次提交
  6. 26 2月, 2018 1 次提交
  7. 07 6月, 2017 1 次提交
    • J
      Consistent use of @Nullable across the codebase (even for internals) · f813712f
      Juergen Hoeller 提交于
      Beyond just formally declaring the current behavior, this revision actually enforces non-null behavior in selected signatures now, not tolerating null values anymore when not explicitly documented. It also changes some utility methods with historic null-in/null-out tolerance towards enforced non-null return values, making them a proper citizen in non-null assignments.
      
      Some issues are left as to-do: in particular a thorough revision of spring-test, and a few tests with unclear failures (ignored as "TODO: NULLABLE") to be sorted out in a follow-up commit.
      
      Issue: SPR-15540
      f813712f
  8. 27 5月, 2017 1 次提交
    • S
      Introduce null-safety of Spring Framework API · 87598f48
      Sebastien Deleuze 提交于
      This commit introduces 2 new @Nullable and @NonNullApi
      annotations that leverage JSR 305 (dormant but available via
      Findbugs jsr305 dependency and already used by libraries
      like OkHttp) meta-annotations to specify explicitly
      null-safety of Spring Framework parameters and return values.
      
      In order to avoid adding too much annotations, the
      default is set at package level with @NonNullApi and
      @Nullable annotations are added when needed at parameter or
      return value level. These annotations are intended to be used
      on Spring Framework itself but also by other Spring projects.
      
      @Nullable annotations have been introduced based on Javadoc
      and search of patterns like "return null;". It is expected that
      nullability of Spring Framework API will be polished with
      complementary commits.
      
      In practice, this will make the whole Spring Framework API
      null-safe for Kotlin projects (when KT-10942 will be fixed)
      since Kotlin will be able to leverage these annotations to
      know if a parameter or a return value is nullable or not. But
      this is also useful for Java developers as well since IntelliJ
      IDEA, for example, also understands these annotations to
      generate warnings when unsafe nullable usages are detected.
      
      Issue: SPR-15540
      87598f48
  9. 13 4月, 2017 1 次提交
  10. 02 2月, 2017 1 次提交
  11. 14 9月, 2016 1 次提交
  12. 06 9月, 2016 1 次提交
    • R
      Resource handling support for Spring Web Reactive · 1ae64bfb
      Rossen Stoyanchev 提交于
      A straight-forward port of the resource handling support in
      spring-webmvc to spring-web-reactive. Primarily adapting contracts and
      implementations to use the reactive request and response and the
      reactive ResourceHttpMessageWriter.
      
      Issue: SPR-14521
      1ae64bfb
  13. 06 5月, 2016 1 次提交
  14. 29 4月, 2016 1 次提交
  15. 04 3月, 2016 1 次提交
  16. 09 9月, 2015 1 次提交
  17. 30 7月, 2015 1 次提交
  18. 27 7月, 2015 2 次提交
  19. 20 5月, 2015 2 次提交
    • B
      Polish · 57e0c789
      Brian Clozel 提交于
      Issue: SPR-12323
      57e0c789
    • B
      Add a ResourceResolver implementation for WebJars · 9e5a33c1
      Brian Clozel 提交于
      Prior to this commit, WebJars users needed to use versioned links within
      templates for WebJars resources, such as `/jquery/1.2.0/jquery.js`.
      This can be rather cumbersome when updating libraries - all references
      in templates need to be updated.
      
      One could use version-less links in templates, but needed to add a
      specific MVC Handler that uses webjars.org's webjar-locator library.
      While this approach makes maintaing templates easier, this makes HTTP
      caching strategies less optimal.
      
      This commit adds a new WebJarsResourceResolver that search for resources
      located in WebJar locations. This ResourceResolver is automatically
      registered if the "org.webjars:webjars-locator" dependency is present.
      
      Registering WebJars resource handling can be done like this:
      
      ```java
      @Override
      protected void addResourceHandlers(ResourceHandlerRegistry registry) {
        registry.addResourceHandler("/webjars/**")
                .addResourceLocations("classpath:META-INF/resources/webjars")
                .resourceChain(true)
                    .addResolver(new WebJarsResourceResolver());
      }
      ```
      
      Issue: SPR-12323
      
      polish
      9e5a33c1