破解Xodus文件存储机制以部署到Heroku或Openshift

Question

如果尝试破解Xodus文件I / O，后果是（或可能会遇到的问题），因此，我将使用ByteBuddy替换对Java File I / O的所有访问，而Xodus实际上将“持久”存储到该接口而不是磁盘I / O，因为我发现在云平台（Heroku，Openshift等）上进行持久存储效率低下（几乎是不可能的），所以我在想这种黑客方法是创建自己的Java文件I / O不会保存到磁盘，而是会保存到更具弹性的存储中，例如Google Cloud Storage，S3和其他Object存储。这样我就可以在Heroku或Openshift中运行我的应用程序。

如果我用ByteBuddy替换File I / O或Xodus数据库是不可知的，那么Xodus会有副作用吗？

Answer 1

为了更简洁的方法，您应该重构为使用NIO2 FileSystem抽象，然后使用您打算使用的文件系统。同时，我知道这并不总是可能的。

如果您想替换File API，最简单的方法可能是重新定义File类以按照您想要的方式实现操作。看一下AgentBuilder API并使用RedefinitionStrategy.RETRANSFORM。

重新定义File类时，可以使用Advice内联模板代码，还可以覆盖实现。在这种情况下，可以将Advice用作拦截器：

builder = builder.method(...).intercept(Advice.to(MyAdvice.class));

通常在退出建议中控制实现的位置，您可以在其中设置返回值，如下所示：

class MyAdvice {
  @Advice.OnMethodExit
  void exit(@Advice.Return(readOnly = false) Void value) {
    value = ...;
  }
}

如果要保留File API的完整部分，也可以将建议用作修饰符：

builder = builder.visit(Advice.to(MyAdvice.class).on(...));

您可以在其中确定是否应从enter方法执行原始方法。