关于jHipster框架在构建中的出现的error修复
jhipster The JDL object and the database type are both mandatory.这个错误应该是在构建基于jHipster的spring-cloud项目中经常遇到的,因为这个在这个过程中会读取.yo-rc文件,之后生成相关的.json文件,再之后生成相关的.java文件,层层依赖,一环扣一环。以下是出错时的系统日志
yerlkyu@HP-Z440:/xxx/xxxx/jdls jhipster import-jdl pl.jdl
INFO! Using JHipster vers ion installed globall, INFO! Executing import-jdl pl.jdl
INFO! Options: from-cli: true INFO! The JDL is being parsed.
Error: The JDL object and the database type are both mandatory. ERROR!
Error while parsing applications and entities from the JDL Error: The JDL obiect and the database type are both mandatory.
Error: The JDL object and the database type are both mandatory. at object.parse (/usr/Lib/node modules/generator-ihipster/node modules/ihinstercore/lib/parser/entity parser. is:59:11)
at getJSONEntities (/usr/lib/node modules/ceneratorihipster/node modules/ihipster-core/1ib/idu/idl importer.is: 154:23
at importonlyEntities (/usr/lib/node modules/generator-ihipster/node modules/ihipstercore/ib/idl/idl importer.is: 102:24
at JDLImporter.import (/usr/lib/node modules/generator-ihipster/node modules/ihipster-core/lib/idl/id importer.is:67:43)
at JDLProcessor.importJDL (/usr/lib/node modules/qenenator-ihipster/cli/impont-id. is: 76:411
at JDLProcessor. importJDL (/usr/Lib/node modules/generator-ihipster/cli/import-idl.is : 292:38)
at module.exports {/usr/lib/node modules/generator-ihipster/cli/import-idl.is: 446:21)
at Command.command, allowUnknownOption.description.action. args (/usr/lih/node modules/cenerator-ihipster/cii/cli.is:72:36)
at Command.listener (/usr/lib/node modules/qeneratorihipster/node modules/commander/index, is:315:8)
at Command.emit (events.js:189:13)
修改完一份jdl文件,之后我们需要重新生成json文件,通过import-jdl这条指令让其自动生成文件,然而一直触发这个错误,大概意思是说找不到这.yo-rc文件,其依赖于.yo-rc.json这个文件的开发,由于直接进入jdl文件所在的文件夹不能搜索到根目录中的.yo-rc.json文件,因此,在根目录上执行导入jdl文件即可,例如
1. jhipster import-jdl ./jdl/p1.jdl 2. jhipster import-jdl ./jdl/p1.jdl --force
注意这两条命令的区别,作为前者,仅仅只会变更修改过的信息,不过由于这个框架在运行的过程中有某些原因,有时候并不会自动生成变更文件,那么此时建议使用指令2,这个时候会强制覆盖所有的文件,不过这个指令会带来一个风险,即会把原来的文件覆盖,比如会生成类似HEAD等乱码、或者覆盖原来修改的文件。
其依赖json文件的生成生成,json文件如图所示,
生成的文件,比如mapper层,数据库表结构,DTO、impl等接口的生成都是依赖于这个jdl的生成,这个框架的集成会自动覆盖之前生成的文件,如果你已经做了修改的话,建议通过查询修改历史 记录,恢复原来修改的数据,这个是这套框架的一个bug,开着团队声明说他们已经修复了这个错误,但看起来并不是很好的能够修复他,因此,我们需要进行手动修复。修复过程如图所示
至于说jHipster这个框架所生成的mapper文件则是通过运行gradle 服务,使其自动生成*mapper这个映射层文件。
参考资料
jhipster官方网站:https://www.jhipster.tech/
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
一次线上zabbix server 挂掉的思考
突然间发现zabbix 挂了,咋发现的呢?报警的世界突然安静了,你就会觉得不妥了。这是运维人员的通病,有报警嫌烦,没报警心里会不安。1,图形界面上确实显示zabbix server is not running 2,排查zabbix server 日志tail /var/log/zabbix/zabbix_server.log 发现有如下报警: zabbix_server [22890]: cannot open log: cannot create semaphore set: [28] No space left on device zabbix_server [22894]: cannot open log: cannot create semaphore set: [28] No space left on device zabbix_server [22898]: cannot open log: cannot create semaphore set: [28] No space left on device zabbix_server [22902]: cannot op...
- 下一篇
记一次线上DPDK-LVS的故障排查
背景 我们内部基于dpdk自研的高性能负载均衡器dpvs已经在多个机房部署上线,运行正常,但近期有多个金融相关的业务反馈,服务数据包在经过dpvs转发后,会出现hang住的情况。 问题 dpvs已经在多个机房上线,运行时间已超过半年,为何突然有业务反馈异常反馈问题的业务多与金融区相关(金融区由于其特殊性,会额外增加安全方面的加固策略)为什么问题表现均为服务hang住 问题排查 首先,我们怀疑与dpvs或与金融的某些安全策略相关,因此我们做了如下测试(后端上跑的均是相同的测试代码,并模拟了服务端逻辑): client < ----- > dpvs < ----- > rs(金融区) 不正常client < ----- > dpvs < ----- > rs(非金融区) 正常client < ----- > lvs < ----- > rs(金融区) 正常client < ----- > lvs < ----- > rs(非金融区) 正常 通过1、2组测试能够得出结论:该问题与金融区相关且dpv...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- SpringBoot2编写第一个Controller,响应你的http请求并返回结果
- CentOS8,CentOS7,CentOS6编译安装Redis5.0.7
- MySQL8.0.19开启GTID主从同步CentOS8
- CentOS7,CentOS8安装Elasticsearch6.8.6
- Docker使用Oracle官方镜像安装(12C,18C,19C)
- Jdk安装(Linux,MacOS,Windows),包含三大操作系统的最全安装
- Linux系统CentOS6、CentOS7手动修改IP地址
- CentOS7安装Docker,走上虚拟化容器引擎之路
- CentOS7编译安装Cmake3.16.3,解决mysql等软件编译问题
- SpringBoot2全家桶,快速入门学习开发网站教程