Spring Data Rest 资源处理器用于投影异常

Question

我已创建了以下的投影。

@Projection(name = "select", types = {Organisation.class})
public interface OrganisationSelectProjection {

    Long getId();

    String getName();

}

我想要将这段代码基本上用于“选择”组件中，因此需要尽可能少的数据。因此，我还想使用 ResourceProcessor 删除所有链接，所以我创建了以下内容：

@Bean
public ResourceProcessor<Resource<OrganisationSelectProjection>> organisationProcessor() {
    return resource -> {
        resource.removeLinks();
        return resource;
    };
}

然而，看起来这破坏了整个API，因为无论我访问哪个端点，都会收到以下异常消息：org.springframework.hateoas.PagedResources cannot be cast to org.springframework.hateoas.Resource

你有任何想法我做错了什么吗？

- ChrisGeo

---

你使用的 spring-hateoas 版本是什么？Spring-boot 1.5.2（当前版本）带有 spring-hateoas-0.23，应该可以正常工作... - Cepr0

我正在使用0.20.0版本和Spring-Boot 1.4.3，但我将升级到1.5.2并尝试它。 - ChrisGeo

已测试过1.5.2版本，仍然无法正常工作。 - ChrisGeo

你能否尝试使用这个替换你的bean？ - Cepr0

Answer 1

如果您想保留匿名类，请使用ResourceSupport而不是Resource，这样可以解决问题。

@Bean
public ResourceProcessor<ResourceSupport> organisationProcessor() {
    return resource -> {
        resource.removeLinks();
        return resource;
    };
}

但在这种情况下，处理器将被用于每个资源，而不管内容的类型（您可以在方法体内检查）。

您可以将匿名ResourceProcessor的子级定义为独立类：

public class OrganizationResourceProcessor implements ResourceProcessor<Resource<OrganisationSelectProjection>> {
    @Override
    public Resource<OrganisationSelectProjection> process(Resource<OrganisationSelectProjection> resource) {
        resource.removeLinks();
        return resource;
    }
}

@Bean
public OrganizationResourceProcessor  organisationProcessor() {
    return new OrganizationResourceProcessor();
}

您所遇到的问题与类型擦除有关，因为匿名类实现中没有任何类型参数。您的定义是类型安全的，但它缺乏在运行时用于确定特定ResourceProcessor是否能够处理资源的相关数据类型。因此，spring-data-rest认为匿名organizationProcessor能够处理PagedResources，并将其提供给处理器，在那里发生ClassCastException。

spring-data-rest通过ResourceProcessor处理的并不是所有的Resource。可能会有不同的org.springframework.hateoas.ResourceSupport类的后代（例如在您的情况下的PagedResources），其中大多数并未继承自Resource。

- Oleg Kurbatov

---

很遗憾，这是Lambda实现方式的限制。我已经在邮件列表上提出了这个问题，但没有得到太多回应：http://mail.openjdk.java.net/pipermail/compiler-dev/2017-January/010675.html - Oliver Drotbohm