在启动整个spring boot项目时，出现错误： Could not resolve placeholder 原因：没有指定好配置文件，因为src/main/resources下有多个配置文件，例如application-dev.properties, boss.properties等。     解决办法： 在application.properties中加入 spring.profiles.active=@env@ 很多时候，我们项目在开发环境和生成环境的环境配置是不一样的，例如，数据库配置，在开发的时候，我们一般用测试数据库，而在生产环境的时候，我们是用正式的数据，这时候，我们可以利用profile在不同的环境下配置用不同的配置文件或者不同的配置 spring boot允许你通过命名约定按照一定的格式(application-{profile}.properties来定义多个配置文件，然后通过在application.properyies通过spring.profiles.active来具体激活一个或者多个配置文件，如果没有没有指定任何profile的配置文件的话，spring boot默认会启动application-default.properties。   https://www.ossez.com/t/spring-boot-could-not-resolve-placeholder/14140

根据官方的文档说明：Spring Data JPA - Reference Documentation     可以在查询的参数后面添加 True 或 False 来进行查询。 例如，如果需要对下面的参数进行查询： True findByActiveTrue() … where x.active = true False findByActiveFalse() … where x.active = false 那么我们在查询的接口上可以使用： @Query public Iterable<Entity> findByEnabledTrue(); 来完成查询。   https://www.ossez.com/t/spring-jpa/14137

让编译能够通过是最基本的要求了。     是不会运行有错误存在的。   https://www.usreio.com/t/topic/302

在国内小朋友的帮助下，已经初具雏形了。 为了帮助大家在签证时候的签证行政审查，我们做了一个小工具希望能够帮助到所有在路上的人。     要改的还在继续，我们还在持续推进喔。 https://www.usvisatrack.com/

我们在使用 Spring JPA 测试项目启动的时候，得到下面的错误： Unable to acquire JDBC Connection     问题和解决 出现这个问题的主要原因是我们在资源文件夹中还有一个 hibernate.properties 文件。 这个文件中配置了 Hibernate 的数据库参数。 因为这个文件的存在，对我们 Spring JPA 使用的数据源进行了干扰。 解决办法就是删除 Hibernate 的属性配置文件。     将上面的属性配置文件删除即可。   https://www.ossez.com/t/spring-unable-to-acquire-jdbc-connection/14133

Spring 进行测试的时候提示的错误信息如下： SEVERE: Caught exception while closing extension context: org.junit.jupiter.engine.descriptor.JupiterEngineExtensionContext@c63c11ed java.lang.IllegalStateException: Unable to find a @SpringBootConfiguration, you need to use @ContextConfiguration or @SpringBootTest(classes=...) with your test     问题和解决 这个问题的主要原因是测试的包和项目的包的路径可能不一致。 这将会导致测试没有办法找到有关 Spring 有关的配置。     对比上面的图，我们就可以看到这个问题。 解决方法就是确定包的路径是一致的，这样 Spring 的测试类可以找到 Spring 有关的配置。   https://www.ossez.com/t/spring-unable-to-find-a-springbootconfiguration/14132

属性文件乱码通常是中文乱码，在英文下通常没有这个问题。     如上图显示的，中文字符在属性文件中读取后会显示为乱码. 问题和解决 导致这个问题的主要原因是属性文件如果你不进行设置，那么将会默认使用 ISO-8859-1 字符集来存储的。 通常我们也不建议在属性文件中过多使用中文，一般来说属性文件都是一些配置，如果需要中文的配置可以存储在其他的文件中。 如果非要使用，也是可以的。 不修改字符集 在不修改字符集的情况，将中文字符使用 Unicode 来表示就可以了。 如上面的例子，使用下面的字符。 name = \u5C5E\u6027\u6587\u4EF6 Inject a value to a static field 在程序输出的时候就可以显示成中文了。 转换成 UTF-8 编码 可以把属性文件转换成 UTF-8 编码。 这个 IDEA 能够很好的帮我们进行转换。 选择文件编码，然后选择 UTF-8，然后选择后面的选项。     然后在更新过代码的属性文件中输中文。 再次运行后，我们就可以看到能够正常显示中文了。 如上图完成修改后，就可以显示中文了。   https://www.ossez.com/t/java/14131

在 Spring JPA 1 对多查询的时候出现死循环的问题。 如下图所示：     所有的配置都是正确的的，就是没有办法获得数据，并且出现死循环 问题和解决 因为使用lombak的 @Data ，在toString()方法中产生死循环。 因为我们使用了 @Data 注解。     所有让 lombok 定义的 @ToString 类将会实现一个 toString() 方法。 在默认的情况下，将会指向类的名称，同时和每一个字段。 例如在使用 lazy @OneToMany 方法调用 hashCode() 的时候，fetch 可能有所有的实体类，这个对应用程序的运行可能产生非常大的性能问题。 同时，如果你在事务以外使用的话，可能会得到 LazyInitializationException 异常。 如果查询一个User实体，并打印，打印调用的是toString() 方法，toString()方法里面又有关联Dept对象。 所以导致 User 和子对象之间的两个对象互相调用并打印，形成一个递归调用，最后堆栈溢出。 基于上面的考虑，我们认为 @EqualsAndHashCode 和@Data 不应该应用在 JPA 的实体类上使用。 @ToString 还是可以使用的，因为我们可以使用 @ToString.Exclude 来设置不需要的字段或者使用 @ToString(onlyExplicitlyIncluded = true ) 来移除类， 对于 non-lazy 字段，我们可以使用@ToString.Include 注解。 例如我们的解决方案就是在 JPA 实体类中只使用 @Getter @Setter 注解。   基于上面的原因，这也是很多人建议使用 Lombok 的原因。 我们的理解还是可以使用的，别滥用，别图省事一个 @Data 到头。   https://www.ossez.com/t/spring-lombok/14129

有一个项目启用了 Spring Security，后台使用的是 H2 数据库。 使用用户名和密码登录后没有问题，但登录后提示 ‘X-Frame-Options’ to ‘deny’. 错误。     错误信息如上图。 问题和解决 X-Frame-Options HTTP 响应头是用来给浏览器指示允许一个页面可否在 <frame>、<iframe>、<embed> 或者 <object> 中展现的标记。站点可以通过确保网站没有被嵌入到别人的站点里面，从而避免点击劫持 攻击。 X-Frame-Options有三种可配置值 X-Frame-Options: DENY X-Frame-Options: SAMEORIGIN X-Frame-Options: ALLOW-FROM https://example.com/ 第一个例子告诉浏览器不要（DENY）把这个网页放在iFrame内，通常的目的就是要帮助用户对抗点击劫持。 第二个例子告诉浏览器只有当架设iFrame的网站与发出X-Frame-Options的网站相同，才能显示发出X-Frame-Options网页的内容。 第三个例子告诉浏览器这个网页只能放在 https://example.com/ 网页架设的iFrame内。 不指定X-Frame-Options的网页等同表示它可以放在任何iFrame内。 X-Frame-Options可以保障你的网页不会被放在恶意网站设定的iFrame内，令用户成为点击劫持的受害人。 如上图所展示的内容，受害者通常是因为点击了来路不明的网页，在这个网页中通常有一个 IFrame 嵌入。 然后攻击者就可以利用这个漏洞来对用户的点击进行劫持。 Spring Security 的启用 在 Spring 中，我们可以使用下面的代码来进行同源性校验。 http.headers().frameOptions().sameOrigin(); 当然，更可以直接禁用这个校验。     针对我们的问题，使用同源性校验就可以满足要求了。   https://www.ossez.com/t/spring-security-x-frame-options-to-deny/14123

尝试使用 H2 数据库创建表，但是老是提示 expected "identifier 这个错误。     问题和解决 经过搜索后才知道，上面的错误是因为我们使用的表名 USER 是 H2 的关键字。 H2 的关键字列表为：Advanced 很明显这里 是一个关键字。     可以： 简单粗暴的对使用的关键字使用单引号 在JDBC 连接中使用 ;NON_KEYWORDS=USER 数据库关键字 到底应不应该使用 USER 作为用户表的命名呢？ 搜索了下不同的说法，大部分都认为不应该将用户表的名称命名为 USER ，而应该使用 Person。 根据 ISO/IEC 11179-6:20 中规范的说法，我们应该避免使用 USER 来命名用户表，也不要使用 USERS 来命名。 数据库表的命名可以使用前缀和后缀的方式。 下面是有关的一些实例。 前缀 如果你的表可能超过有 100 个表的话，可以使用定义的前缀来命名，例如： REF_ 为参考表 OE_ 为 Order Entry 相关，这个值针对为物理级别的命名，而不是逻辑级别的 后缀 永远不要使用后缀来命名表，而应该使用后缀来命名其他的东西，但是这也不是绝对的的。 例如针对视图我们可以使用 _V 这个前缀来命名。 _fk 外键 _cac 缓存 _seg Segment _tr 事务 _fn 函数等 总结 针对表的命名没有绝对的统一的说法，但是针对一个公司或者一个项目，最好使用统一命名的标准。 对表进行一些系统性的区分，能够让我们更好的区分用途。 例如： 系统表（S_）可以用来定义系统的基本信息，更多是元数据等，这些数据是有关于系统运行的，通常例如可以定义 系统用户表（S_USER）、系统角色表（S_ROLE）等。 这样可以有效的避免关键字冲突。 很多时候，可能觉得这个是不是有点麻烦呀，很多项目可能不会超过几百个表。 但，免不了一些奇葩项目，有上千个表，经历过一个不是非常复杂的逻辑项目，但是表有 1300 多个，真不知道这个表是怎么建的，并且是各种奇葩的命名都有。 另外，千万别用 tbl 作为前缀来命名表，简直就是脱了裤子放屁，谁不知道你这个表是 tbl？   https://www.ossez.com/t/h2-expected-identifier/14122