Java 黑客攻击Xodus文件存储机制以部署到Heroku或Openshift

如果我尝试破解Xodus文件I/O，会有什么后果（或我可能面临的问题），因此我将使用ByteBuddy替换对Java文件I/O的所有访问，Xodus将实际“持久化”到该接口而不是磁盘I/O，因为我发现在云平台上拥有持久存储效率低下（几乎不可能）（Heroku，Openshift，仅举几个例子）--我想这个黑客程序是创建我自己的Java文件I/O，而不是保存到磁盘，它将保存到一个更具弹性的存储中，比如谷歌云存储、S3和其他对象存储。这样我就可以在Heroku或Openshift中运行我的应用程序

---

如果我用ByteBuddy替换文件I/O，或者Xodus数据库对此不可知，那么Xodus会有副作用吗？

为了更干净的方法，您应该重构为使用NIO2

文件系统

抽象，然后使用您打算使用的文件系统。同时，我理解这并不总是可能的

如果您想替换

文件

API，最简单的方法可能是重新定义

文件

类，以按照您想要的方式实现操作。请查看

AgentBuilder

API，并使用

重新定义策略。重新转换

重新定义

文件

类时，您可以使用

Advice

，它内联模板的代码，还允许您覆盖实现。在这种情况下，您可以使用

Advice

作为拦截器：

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

在这里，您可以控制实现，通常是通过退出通知，在退出通知中，您可以按如下方式设置返回值：

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

如果您想保持

文件

API的部分完整，还可以使用advice作为decorator：

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

---

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

例如，当您替换文件API时，它是否会在整个应用程序生命周期中替换？例如，对于web应用程序，它是否会替换每个调用（例如，来自其他库的调用，可能需要实际写入文件以进行增强等）或者只针对特定的软件包？它会重写代码，就好像您实际上是这样编程的。它影响的类取决于您如何设置

类型

步骤匹配器和

忽略

语句。