Spring Boot 1.5.6迁2.1.7遇问题：Filter转发失效与排序NPE

Hey Robin, let’s break down these two tricky migration problems and answer your Spring Data 2.0 question—migration always has these hidden gotchas, right?

1. Filter Not Triggered After RequestDispatcher.forward() #

The root cause here is a change in Filter registration defaults between Spring Boot 1.x and 2.x:

• In Spring Boot 1.5.x, filters were registered to apply to all DispatcherType values (REQUEST, FORWARD, INCLUDE, etc.) by default.
• In Spring Boot 2.x, filters are registered only for DispatcherType.REQUEST unless explicitly configured otherwise. That’s why your forward call isn’t triggering the filter anymore.

Fix Options: #

• If using FilterRegistrationBean:
  Add explicit dispatcher types to your bean definition:

  @Bean
  public FilterRegistrationBean<YourDecryptionFilter> decryptionFilter() {
      FilterRegistrationBean<YourDecryptionFilter> registrationBean = new FilterRegistrationBean<>();
      registrationBean.setFilter(new YourDecryptionFilter());
      registrationBean.addUrlPatterns("/*");
      // Include both REQUEST and FORWARD dispatcher types
      registrationBean.setDispatcherTypes(DispatcherType.REQUEST, DispatcherType.FORWARD);
      return registrationBean;
  }
  

• If using @WebFilter annotation:
  Specify the dispatcher types directly in the annotation:

  @WebFilter(urlPatterns = "/*", dispatcherTypes = {DispatcherType.REQUEST, DispatcherType.FORWARD})
  public class YourDecryptionFilter implements Filter {
      // ... your filter logic
  }
  

2. NullPointerException in Querydsl.applySorting() #

This error ties directly to changes in Spring Data 2.0’s sorting/pagination null handling rules—you’re spot-on to question that!

What Changed: #

• In Spring Data 1.x, passing a null Sort or Pageable parameter was treated as "no sorting/pagination" (the framework would ignore it gracefully).
• In Spring Data 2.0+, the framework no longer tolerates null for these parameters in most cases. When your endpoint receives no sorting input, if your code passes null to the repository method, the Querydsl implementation tries to process it and hits an NPE at applySorting() (since it expects a valid Sort instance, not null).

Fix Steps: #

1. Check Controller Layer:
   When handling requests that don’t specify sorting parameters, return Sort.unsorted() instead of null. For example:

   @GetMapping("/api/users")
   public List<User> getUsers(@RequestParam(required = false) String sort) {
       Sort sortObj = (sort == null) ? Sort.unsorted() : Sort.by(sort);
       return userRepository.findAll(sortObj);
   }
   

2. Adjust Repository Methods (if needed):
   If you’re using custom Querydsl queries, explicitly handle null Sort values by replacing them with Sort.unsorted() before passing to applySorting():

   public List<User> findAllCustom(Sort sort) {
       JPAQuery<User> query = new JPAQuery<>(entityManager);
       // Ensure sort is never null
       Sort safeSort = (sort == null) ? Sort.unsorted() : sort;
       Querydsl.applySorting(safeSort, query);
       return query.from(user).fetch();
   }
   

3. Use @Nullable (if necessary):
   If you must support null parameters in your repository methods, mark the Sort/Pageable parameter with @Nullable and add a null check:

   @Override
   public List<User> findAll(@Nullable Sort sort) {
       Sort effectiveSort = (sort == null) ? Sort.unsorted() : sort;
       // ... rest of the logic
   }
   

Confirmation on Spring Data 2.0 Sort/Pageable Null Rules #

Yes, Spring Data 2.0 introduced this breaking change to enforce more explicit handling of "no sorting/pagination" scenarios. The official guidance is to use:

• Sort.unsorted() instead of null for no sorting
• Pageable.unpaged() instead of null for no pagination

This makes code more readable and avoids hidden null-related bugs down the line.

内容的提问来源于stack exchange，提问作者Robin Lamberte