一、该问题的重现步骤是什么？
1. 翼总，我个人感觉OSS上传文件这里，你为什么不直接预留一个路径前缀的参数呢？仅仅为了添加一个路径前缀，我还要去自定义底层框架代码，感觉太麻烦了。。。是否这里应该支持轻量地指定前缀的快捷设定，这毕竟是个通用需求。我看帖子上至少不下3个人问。说真的，为了加个路径，我还要动底层源码。我觉得不太好。担心后期麻烦（部署和镜像。。。。）。
2.
3.
二、你期待的结果是什么？实际看到的又是什么？
三、你正在使用的是什么产品，什么版本？在什么操作系统上？
四、请提供详细的错误堆栈信息，这很重要。
五、若有更多详细信息，请在下面提供。
那如果blade-resource定位已经不算底层代码，而是业务代码，那我是否也可以定义blade-resource的Feign，方便Biz里的微服务直接去调用resource服务，而不需要使用okhttp去模拟前端调用oss。
另外，如果改动了blade-resource的源码，在镜像管理和后期部署方面，推送镜像需要改名单独管理自己的镜像吗？这里有什么建议，方便这种源码改动后的麻烦尽可能地影响小呢？那后期跟进框架代码的时候，merge合并有什么注意吗。。。
blade-resource可以自定义feign，不需要用okhttp去调用。
镜像不需要单独改名，只需要重新构建一下，并且maven仓库也不需要改动，因为没有涉及到bladex-tool的修改。
当然如果真的不想改源码，想升级更方便也是有办法的，就是用java的覆盖机制。也就是说把需要修改的类按照他原本的路径和命名，在对应业务工程新建，然后复制源码再自行修改。这样打包后，代码逻辑会走自己复制过去的这个类而不会走本身依赖的jar包了。
具体可以这么修改，不会变更原有的逻辑。
因为路径带斜杠，无法正确传参数。
blade-resource已经不算底层代码了，属于业务代码。已经开放了OssRule的自定义，真正的底层会动态读取。
如果说把路径的斜杠改成横杠传参，然后后台再改成斜杠，这种方法可行是可行，但是非常不优雅并且如果文件名带一个横杠名就冲突了。如果不用横杠改成其他符号，总有机会冲突。综合考虑下来，这个方案就被否决了，只能通过后端自定义命名规则的类来实现。
遇到需要自定义的情况，只需要改两处，已经算是非常小程度的改动了。
而且从全局来看，一种策略不可能满足所有人的需求，如果不满足需求必定要修改，不管怎样都是需要去改源码的，所以这方面已经设计的最小程度的改动了。
修改bladex的源码后，后面推送镜像，需要改镜像名吗？。。
扫一扫访问 Blade技术社区 移动端
加载中...
苏公网安备 32041102000998号