是否有更好的替代方法来扩展SlingPostServlet？

Question

在Sling应用程序中，我想确保使用特定sling:resourceType创建的节点始终具有使用特定属性创建的子节点。实现这一目标的方法符合最佳实践？

1. 扩展SlingPostServlet类并添加在doPost()方法中添加子节点的功能。这看起来很合适，因为乍一看，可以将servlet链接到特定的资源类型，并调用super.doPost()来使用默认的SlingPostServlet处理。但是，在安装捆绑包时，org.apache.sling.servlets.post.impl无法解析（a similar problem was encountered by another user），这会阻止捆绑包运行。
2. 创建SlingPostProcessor并在process()方法中添加功能。这似乎不太理想，因为它不依赖于一种特定的资源类型。
3. 使用Sling Eventing。

我想避免扩展SlingAllMethodsServlet，因为保持对SlingPostServlet中所有默认功能的访问会很有用。然而，是否有可能扩展SlingPostServlet，而不是SlingAllMethodsServlet？

Answer 1

我不认为有一个简单的解决方案将该行为绑定到单个资源Type。您需要检查新资源并在需要时应用更改。我认为最好的两个选项是你提到的SlingPostProcessor和Resource observation。

资源观察允许您“监听”资源的变化并执行您认为合适的任何操作。

实施也相当直接。创建一个新的OSGi服务，该服务实现ResourceChangeListener接口并添加一些属性来过滤您感兴趣的更改类型。这类似于使用JCR事件和作业，但更直接。

这样做的好处是，这与任何邮寄请求无关。缺点是您需要使用新会话来执行更改。 （你可以使用ResourceResolverFactory.getServiceResourceResolver）

例如。

@Component(property = {
    ResourceChangeListener.CHANGES + "=ADDED",
    ResourceChangeListener.PATHS + "=glob:/content/*",
})
public class ResourceObserver implements ResourceChangeListener {

  @Override
  public void onChange(@Nonnull List<ResourceChange> changes) {
      //go through the list of changes and do what you need to do.
  }
}