Java - CWIKIUS

获得的错误信息为： Exception in thread "main" java.lang.IllegalStateException: Logback configuration error detected: ERROR in ch.qos.logback.core.joran.util.PropertySetter@34237b90 - A "net.logstash.logback.encoder.LogstashEncoder" object is not assignable to a "ch.qos.logback.core.Appender" variable. ERROR in ch.qos.logback.core.joran.util.PropertySetter@34237b90 - The class "ch.qos.logback.core.Appender" was loaded by ERROR in ch.qos.logback.core.joran.util.PropertySetter@34237b90 - [jdk.internal.loader.ClassLoaders$AppClassLoader@16f65612] whereas object of type ERROR in ch.qos.logback.core.joran.util.PropertySetter@34237b90 - "net.logstash.logback.encoder.LogstashEncoder" was loaded by [jdk.internal.loader.ClassLoaders$AppClassLoader@16f65612]. at org.springframework.boot.logging.logback.LogbackLoggingSystem.loadConfiguration(LogbackLoggingSystem.java:169) at org.springframework.boot.logging.logback.LogbackLoggingSystem.reinitialize(LogbackLoggingSystem.java:222) at org.springframework.boot.logging.AbstractLoggingSystem.initializeWithConventions(AbstractLoggingSystem.java:73) at org.springframework.boot.logging.AbstractLoggingSystem.initialize(AbstractLoggingSystem.java:60) at org.springframework.boot.logging.logback.LogbackLoggingSystem.initialize(LogbackLoggingSystem.java:118) at org.springframework.boot.context.logging.LoggingApplicationListener.initializeSystem(LoggingApplicationListener.java:306) at org.springframework.boot.context.logging.LoggingApplicationListener.initialize(LoggingApplicationListener.java:281) at org.springframework.boot.context.logging.LoggingApplicationListener.onApplicationEnvironmentPreparedEvent(LoggingApplicationListener.java:239) at org.springframework.boot.context.logging.LoggingApplicationListener.onApplicationEvent(LoggingApplicationListener.java:216) at org.springframework.context.event.SimpleApplicationEventMulticaster.doInvokeListener(SimpleApplicationEventMulticaster.java:172) at org.springframework.context.event.SimpleApplicationEventMulticaster.invokeListener(SimpleApplicationEventMulticaster.java:165) at org.springframework.context.event.SimpleApplicationEventMulticaster.multicastEvent(SimpleApplicationEventMulticaster.java:139) at org.springframework.context.event.SimpleApplicationEventMulticaster.multicastEvent(SimpleApplicationEventMulticaster.java:127) at org.springframework.boot.context.event.EventPublishingRunListener.environmentPrepared(EventPublishingRunListener.java:80) at org.springframework.boot.SpringApplicationRunListeners.environmentPrepared(SpringApplicationRunListeners.java:53) at org.springframework.boot.SpringApplication.prepareEnvironment(SpringApplication.java:345) at org.springframework.boot.SpringApplication.run(SpringApplication.java:308) at org.springframework.boot.SpringApplication.run(SpringApplication.java:1237) at org.springframework.boot.SpringApplication.run(SpringApplication.java:1226) at com.ossez.edtestbank.service.Application.main(Application.java:44) 问题和解决这个是包的兼容性问题。 logback-core 需要设置为 1.2.0 版本，如果你设置了更高的版本的话，你就会遇到上面的问题。请参考下面链接中的问题： https://jira.qos.ch/browse/LOGBACK-1326 貌似到现在还没有解决。如果你还希望使用 logstash-logback-encoder 的话，那么需要将 logback 设置为 1.2.0 版本。 https://www.ossez.com/t/logstash-logback-encoder-logback/767

2020年12月14日 0Comments 1632Browse 5Like Read more

现在很多编译器和软件都开始要求使用 JDK 11 了。因此我们希望在 CentOS 上安装 JDK 11。运行下面的命令： yum install java-11-openjdk-devel 如果你的系统中还装有不同版本的 JDK 的话。你需要运行： alternatives --config java 来选择默认的 JDK。随后你就可以验证安装的 JDK 了。 https://www.ossez.com/t/centos-7-jdk-11/637

2020年11月04日 0Comments 459Browse 0Like Read more

使用下面的方法： logger.debug("Current DateTime in milliseconds - [{}]", new DateTime().getMillis()); 上面的代码输出的内容是： 15:01:51.331 [main] DEBUG c.i.s.c.t.utilities.CodecUtilsTest - Current DateTime in milliseconds - [1603998111331] 获得当前日期时间的毫秒数，这个毫秒数是从 1970-01-01T00:00:00Z 开始计算的。 1970年， Unix正式诞生，在第一版《Unix Programmer’s Manual》中把“1971年11月3日”定义为“自1970年1月1日0时0分0秒以来以1/60秒为单位的时间”。此后，这个定义由于可定义的时间范围，时区，闰秒等问题被重新定义。 https://www.ossez.com/t/java-datetime-unix/623

2020年10月30日 0Comments 596Browse 0Like Read more

假定我们有一个文件位于：src/test/resources/data/azure_storage.json 目录中。 azure_storage.json 为数据文件，我们希望将这个文件中的内容读取到测试类中。 azure_storage.json 数据文件在编译成功后会被拷贝到：target/test-classes/data/azure_storage.json 目录中。进行读取在测试类中，我们可以在初始化数据的时候读取数据。 /** * Init Data * @throws IOException */ @BeforeAll public void setUp() throws IOException { ClassLoader loader = Thread.currentThread().getContextClassLoader(); // INIT properties props.load(loader.getResourceAsStream("log4j.properties")); // INIT Azure Storage Test File try { InputStream inputStream = loader.getResourceAsStream(fileName); FileUtils.copyInputStreamToFile(inputStream, azureStorageFile); } catch (IOException e) { logger.error("Init data send to azure error." ,e); } } fileName 使用下面的定义： private String fileName = "data/azure_storage.json"; 需要注意的是 PATH，应该使用的是相对路径。在数据初始化的时候，我们使用下面的代码： InputStream inputStream = loader.getResourceAsStream(fileName); 先将资源文件中数据读取为 InputStream ，这个时候你的数据已经在内存中了，我们在上面的代码中使用代码 FileUtils.copyInputStreamToFile 来将内存中的数据写到一个临时目录中，然后你就可以对文件进行操作了。当然你也可以直接使用 InputStream 来进行必要的下一步测试和操作就可以了。使用这样的配置好处就是在测试的时候，因为不同的人使用的系统是不同的，不同的测试文件路径会导致没有办法进行路径的同步。 https://www.ossez.com/t/java-unit-resources/622

2020年10月29日 0Comments 399Browse 0Like Read more

有时候我们需要知道一个文件的大小。我们可以使用一些方法，比如说将文件读取成 InputStream，然后再使用 available() 获得长度就可以了。我们也可以使用 FileUtils 来获得。使用的方法是： FileUtils.sizeOf(localFileCache) localFileCache 中定义的是文件对象。关于 sizeOf 的使用为：返回指定的文件或者文件夹的大小。如果你的 File 对象为一个文件的话，这个方法将会返回文件的大小。如果你的 File 对象为一个目录的话，那么上面的方法将会返回这个文件夹的大小。这个文件夹的大小将会包含这个文件夹中所有子文件夹的内容。换句话说，这个方法是进行递归大小查询的。但是，如果一个文件夹或者子文件夹有安全限制，不允许访问的话，那么这个方法将不会将上面的文件夹的内容进行计算。 https://www.ossez.com/t/java/620

2020年10月29日 0Comments 376Browse 0Like Read more

在 Azure 上传文件的时候遇到了一个下面的异常： java.io.IOException: mark/reset not supported at java.base/java.io.InputStream.reset(InputStream.java:655) at com.azure.storage.common.Utility.lambda$convertStreamToByteBuffer$4(Utility.java:236) at reactor.core.publisher.FluxDefer.subscribe(FluxDefer.java:46) at reactor.core.publisher.Mono.subscribe(Mono.java:4213) 问题解决当给定的流不支持 mark 和 reset 就会报这个错误。我们用的代码是： blobClient.upload(inputStream , inputStream.available()); InputStream 是不支持 mark 和 reset 的。 BufferedInputStream继承于FilterInputStream，提供缓冲输入流功能。缓冲输入流相对于普通输入流的优势是，它提供了一个缓冲数组，每次调用read方法的时候，它首先尝试从缓冲区里读取数据，若读取失败（缓冲区无可读数据），则选择从物理数据源（例如你指定的文件）读取新数据（这里会尝试尽可能读取多的字节）放入到缓冲区中，最后再将缓冲区中的内容部分或全部返回给用户。由于从缓冲区里读取数据远比直接从物理数据源（譬如文件）读取速度快。 Azure 使用上面的方法来尽量保障数据能够上传到存储中。解决方案是用 BufferedInputStream 再把原来的流包装一层。什么时候会出现这种错误呢，当你获得一个 InputStream 流，这个流是不允许读写头来回移动，也就不允许 mark/reset 机制。所以上面的代码修改为： blobClient.upload(new BufferedInputStream(inputStream) , inputStream.available()); 然后再重试，你就会看到文件上传上去了。登录控制台查看上传的文件。 https://www.ossez.com/t/java-io-ioexception-mark-reset-not-supported/617/2

2020年10月28日 0Comments 455Browse 0Like Read more

在文件上传到服务器的时候，我们希望能够获得文件的指纹以确定文件没有被篡改过。常用的算法最开始使用的是 MD5，随后随着技术的发展，MD5 算法已经被确定是不安全的了。目前可能使用更多的是 HSA3_256 哈希算法。哈希算法通常有以下几个特点：正像快速：原始数据可以快速计算出哈希值逆向困难：通过哈希值基本不可能推导出原始数据输入敏感：原始数据只要有一点变动，得到的哈希值差别很大冲突避免：很难找到不同的原始数据得到相同的哈希值哈希算法主要有MD4、MD5、SHA。 MD4 1990年输出128位（已经不安全） MD5 1991年输出128位（已经不安全） SHA-0 1993年输出160位（发布之后很快就被NSA撤回，是SHA-1的前身） SHA-1 1995年输出160位（已经不安全） SHA-2包括SHA-224、SHA-256、SHA-384，和 SHA-512，分别输出224、256、384、512位。 (目前安全) 在 Java 中，可以使用 Apache 提供的 Apache Commons Codec，非常容易的获得文件的哈希字符串指纹。方法也非常简单，第一步就是需要将文件读取为 InputStream。如果自己写的话，可能这一步有点代码。你可以使用 Apache 提供的 FileUtils.openInputStream 就可以直接将文件读取为 InputStream 了。考察下面的代码： InputStream is = FileUtils.openInputStream(new File(SCOConstants.PATH_DATA_EXCHANGE + "Estimated vs Original Manual (JIRA) 10-23-20.csv")); MD5 哈希在文件读取后，你只需要使用 Apache Commons Codec 提供的 DigestUtils 方法就可以了。 /** * Test to get file's MD5 Hash * * @throws Exception */ @Test public void fileMD5Test() throws Exception { String md5 = StringUtils.EMPTY; try { InputStream is = FileUtils.openInputStream(new File(SCOConstants.PATH_DATA_EXCHANGE + "Estimated vs Original Manual (JIRA) 10-23-20.csv")); md5 = DigestUtils.md5Hex(is); } catch (Exception e) { e.printStackTrace(); } logger.debug("MD5 for File: {}", md5); } 上面的代码就可以直接获得 InputStream 的 MD5 哈希。程序的输出为： 09:32:31.522 [main] DEBUG c.i.s.c.t.utilities.CodecUtilsTest - MD5 for File: 1ec6473fc1bd50a982767f555734af64 SHA3 256 与 MD5 哈希算法是一致的。你需要首先也将文件读取为 InputStream ，然后使用 Apache 提供的 DigestUtils.sha3_256Hex(is); 就可以了。考察下面的代码： /** * Test to get file's SHA3_256Hex Hash * * @throws Exception */ @Test public void fileSHA3_256HexTest() throws Exception { String sha3Hex256 = StringUtils.EMPTY; try { InputStream is = FileUtils.openInputStream(new File(SCOConstants.PATH_DATA_EXCHANGE + "Estimated vs Original Manual (JIRA) 10-23-20.csv")); sha3Hex256 = DigestUtils.sha3_256Hex(is); } catch (Exception e) { e.printStackTrace(); } logger.debug("SHA3_256Hex for File: {}", sha3Hex256); } 运行程序的输出为： 09:35:48.093 [main] DEBUG c.i.s.c.t.utilities.CodecUtilsTest - SHA3_256Hex for File: https://www.ossez.com/t/java/615

2020年10月27日 0Comments 422Browse 0Like Read more

很多公司都在做这方面的转型。尤其是在公司达到一定运营规模后，PHP 的问题会让公司花费更多的时间去部署排查问题。当时公司选择 PHP 的主要原因，就是因为开发简单，框架也还不错，部署也比较快。持续集成的问题可能没有太多的问题。如果一开始要上 Java 的话，很多时候需要面临从框架，数据库，ORM，CI，DevOps 各个不同方面的技术协调和沟通，对不是财大气粗的公司来说，这个负担还是比较重的。毕竟人力成本还在那里摆着。相对以前来说，现在 Java 世界也保持比较开放的态度，有 Spring 全家桶，基本上能够帮你解决很多快速部署的问题，采取微服务可以前台和后台分离，采取混合云架构，可以将一些网络和存储压力转移。其实不管选何种语言都差不多，可能你们公司在使用 PHP 的时候已经达到了 PHP 的性能瓶颈和极限了，转型 Java 再正常不过了。也有用 .NET 的，很多公司不会考虑，主要是版权问题和微软绑定的问题。另外，如果你搜索在互联网世界中有多少个网站使用 Java 有多少网站使用 PHP 的，这个其实是没有任何意义的。因为一个 WordPress 就能碾压很多网站了。 PHP 的优势在于快速部署，没有多少人愿意花费几天时间去安装数据库，部署应用，调试 Log ，并且界面还不好调整。使用 PHP 能够飞速部署一些小应用，对个人，初创公司，想利用一些已有的框架的时候就非常方便了。 https://www.ossez.com/t/php-java/592

2020年10月17日 0Comments 430Browse 1Like Read more

Java 路径接口是 Java NIO 2 更新的一部分，Java NIO 在 Java 6 和 Java 7 中接收 Java 路径接口。 Java路径接口已添加到Java 7中的Java NIO。路径接口位于 java.nio.file 包中，所以Java Path接口的完全包名是 java.nio.file.Path。 java.io.File => java.nio.file.Path 可以考察下面的代码来对 Path 进行测试。 @Test public void getPathfromFile() { // Convert File to Path File file = new File("/home/cwikius/test/file.txt"); Path path = file.toPath(); assertNotNull(path); } 将 Path 转换为 File 请考察下面的代码，可以将 path 转换为文件。 @Test public void getPathToFile() { // Convert Path to File Path path = Paths.get("/home/cwikius/test/file.txt"); File file = path.toFile(); assertNotNull(file); } https://www.ossez.com/t/java-nio-path/584

2020年10月14日 0Comments 415Browse 0Like Read more

在 Hibernate 或者 ORM 映射中，我们可能会存在 1 对多的情况。在这个时候，如果你使用 Jackson 将对象序列化的时候，就会出现双向引用导致的无限递归（infinite recursion）的情况。 @JsonManagedReference 和 @JsonBackReference 注解就是为了避免这个双向引用的情况。 @JsonBackReference 和 @JsonManagedReference：这两个标注通常配对使用，通常用在父子关系中。假设我们有 2 个对象。一个对象是 QIndex 和 QTitle 一个 QIndex 可能对应有多个 QTitle。那么在 JPA 中的对应关系的 QIndex 应该定义为： @OneToMany(mappedBy = "qIndex", cascade = CascadeType.ALL, orphanRemoval = true) @OrderBy("questionNumber ASC") @JsonManagedReference private List<QTitle> qTitleList = new ArrayList<>(); 在 JPA 的 QTitle 中应该定义为： @ManyToOne() @JsonBackReference private QIndex qIndex; 在序列化的时候，@JsonManagedReference 注解的属性则会被序列化，@JsonBackReference 的注解将会被忽略。 @JsonManagedReference 注解，通常说明这个字段是一个双向引用的字段，这个字段在这个双向引用中的角色为 “父”，与这个字段对应的引用需要注解为 @JsonBackReference。 @JsonBackReference 注解，通常说明这个字段是关联的一个双向引用字段，这个字段在这个双向引用的角色是 “孩子”。这个字段的值只能是对象（Bean），不能是集合（Collection），图（Map），数组（Array）和枚举类型（enumeration）。总结 @JsonManagedReference 和 @JsonBackReference 总是成对出现的 @JsonManagedReference 定义在父级角色 @JsonBackReference 定义在孩子级角色 @JsonBackReference 不能使用任何集合和数组等多的数据结构有了上面的解释，应该比较容易的理解为了避免双向引用导致无限递归而出现的问题的。 https://www.ossez.com/t/jackson-jsonmanagedreference-jsonbackreference/574

2020年10月11日 0Comments 464Browse 0Like Read more

12 3 4 5…6

Logstash-logback-encoder 和 logback 出现错误

CentOS 7 安装 JDK 11

Java DateTime 获得当前 Unix 的时间戳

Java Unit 测试中如何获得 resources 中的文件

Java 如何获得一个文件或文件夹的大小

java.io.IOException: mark/reset not supported 异常

Java 获得文件的指纹

公司初创期使用 PHP，为什么很多公司都会慢慢转型到 JAVA

Java NIO Path 接口

Jackson 的 JsonManagedReference 和 JsonBackReference 注解