Spring Data Rest / Spring Hateoas Custom Controller - PersistentEntityResourceAssembler
Estoy intentando agregar algo de lógica comercial adicional a los puntos finales generados automáticamente desde RepositoryRestResource. Por favor vea el código a continuación:
Recurso:
@RepositoryRestResource(collectionResourceRel="event", path="event")
public interface EventRepository extends PagingAndSortingRepository<Event, Long> {
}
Controlador:
@RepositoryRestController
@RequestMapping(value = "/event")
public class EventController {
@Autowired
private EventRepository eventRepository;
@Autowired
private PagedResourcesAssembler<Event> pagedResourcesAssembler;
@RequestMapping(method = RequestMethod.GET, value = "")
@ResponseBody
public PagedResources<PersistentEntityResource> getEvents(Pageable pageable,
PersistentEntityResourceAssembler persistentEntityResourceAssembler) {
Page<Event> events = eventRepository.findAll(pageable);
return pagedResourcesAssembler.toResource(events, persistentEntityResourceAssembler);
}
}
He visto los siguientes dos artículos de stackoverflow:
¿Puedo hacer que un controlador personalizado refleje el formato de las clases generadas por Spring-Data-Rest / Spring-Hateoas?Habilite la serialización HAL en Spring Boot para el método de controlador personalizadoSiento que estoy cerca, pero el problema que estoy enfrentando es que:
return pagedResourcesAssembler.toResource(events, persistentEntityResourceAssembler);
devuelve un error que dice:
"The method toResource(Page<Event>, Link) in the type PagedResourcesAssembler<Event> is not applicable
for the arguments (Page<Event>, PersistentEntityResourceAssembler)".
El método toResource tiene una firma de método que acepta un ResourceAssembler, pero no estoy seguro de cómo implementar esto correctamente y no puedo encontrar ninguna documentación al respecto.
Gracias de antemano, - Brian
Editar
Mi problema fue que pensé que podría anular los métodos del controlador que se crean automáticamente desde@RepositoryRestResource
anotación sin tener que crear mi propio recurso y ensamblador de recursos. Después de crear el recurso y el ensamblador de recursos pude agregar mi lógica de negocios al punto final.
Recurso:
public class EventResource extends ResourceSupport {
private String name;
public String getName() {
return name;
}
public void setName(String name) {
this.name = name;
}
}
Ensamblador de recursos:
@Component
public class EventResourceAssembler extends ResourceAssemblerSupport<Event, EventResource> {
public EventResourceAssembler() {
super(EventController.class, EventResource.class);
}
@Override
public EventResource toResource(Event entity) {
EventResource eventResource = createResourceWithId(entity.getId(), entity);
eventResource.setName(entity.getName());
return eventResource;
}
}
Controlador actualizado:
@RepositoryRestController
@RequestMapping(value = "/event")
public class EventController {
@Autowired
private EventRepository eventRepository;
@Autowired
private EventResourceAssembler eventResourceAssembler;
@Autowired
private PagedResourcesAssembler<Event> pageAssembler;
@RequestMapping(method = RequestMethod.GET, value = "")
@ResponseBody
public PagedResources<EventResource> getEvents(Pageable pageable) {
Page<Event> events = eventRepository.findAll(pageable);
// business logic
return pageAssembler.toResource(events, eventResourceAssembler);
}
}
Lo que no me gusta de esto es que parece vencer el propósito de tener un RepositoryRestResource. El otro enfoque sería utilizar controladores de eventos que se llamarían antes y / o después de las operaciones de creación, guardado y eliminación.
@RepositoryEventHandler(Event.class)
public class EventRepositoryEventHandler {
@HandleBeforeCreate
private void handleEventCreate(Event event) {
System.out.println("1");
}
}
No parece haber ningún evento para las operaciones findAll o findOne. De todos modos, ambos enfoques parecen resolver mi problema de extender los métodos de controlador generados automáticamente desde RepositoryRestResource.