设置idea的自动编译
上图中2号标记的位置需要手动勾选,使得当前项目能够自动编译;
上图中3号标记的位置表示自己加载的文件类型,默认的值带有.java文件,默认文件如下
在上图3号位置配置html后缀,配置后如下图
如果需要自动加载.js文件,仿照上面的“自动加载配置html”的方式配置
上图中2号位置标记的地方,每新建一个项目都需要手动勾选一下
1.这个时候重启容器,重启完后修改.java文件,发现可以自动加载,只是从修改完成到自动加载需要几秒的时间
2.如果1步骤没有实现自动加载,那么重启idea,再次打开项目就可以实现自动加载了
以上所述是小编给大家介绍的springboot+idea热启动设置方法(自动加载),希望对大家有所帮助,如果大家有任何疑问请给我留言,小编会及时回复大家的。在此也非常感谢大家对脚本之家网站的支持!
如果你觉得本文对你有帮助,欢迎转载,烦请注明出处,谢谢!
经过去年的Log4j-core的治理工作,我们通过Maven的依赖仲裁机制,在蚂蚁集团静态代码扫描平台-STC 和资产威胁透视-哈勃2款产品的联动合作下,很好的完成了直接依赖和间接依赖场景下的治理工作。但路还很远,新的场景层出不穷,故事还远远没有结束,我们要做的事情还非常多。
在今年的某一天,一位好朋友找到了我,给我讲了一个有意思的故事。
"他说他发现他负责的Bu的生产服务器上,有危险版本log4j-core的pom文件和相关的字节码文件。"
听到这里我下意识地说:"在主pom的依赖和依赖管理的位置引入安全版本,并且子pom不要写任何版本号就可以了"。已经不知道今年看到多少这种问题了,不自觉的产生了肌肉反应。
"不不不不",他急促的打断了我,我开始意识到事情应该没那么简单了。
"是业务引入了一个不是很流行的三方Jar包,这个三方Jar包又把log4j的源代码给打进去了(但是没有修改包路径),并且业务同学由于安全团队给他发了工单,业务同学也按照我们说的方式,重新引入了安全版本的Log4j。这个时候,应用上就同时拥有了安全版本的Log4j和危险版本的。"
讲到这里,我已经听明白了。一个应用同时引入了安全版本的Log4j 和 经过重打包之后的危险版本的Log4j。由于重打包的Jar包并不是很流行,其作者也不会第一时间重新打一个安全版本。这样就造成了短时间重打包版本不能升级的情况下,这个应用到底是安全的,还是不安全的,还是说这个结果是不可预测的?
最后我也是答应我的好朋友尝试研究一下这个问题,争取给他一个满意的答复!
挂完电话,我把已知的一些细节尝试梳理了一下。此时线上服务的依赖情况应该是下图这个样子。
业务代码在依赖JDK,安全版本的Log4j和重打包的危险版本log4j时,此时此刻无非就4个猜想的答案。
既然Hibernate是关于Java对象和关系数据库之间的联系的话,也就是我们MVC中的数据持久层->在编写程序中的DAO层...
首先,我们来回顾一下我们在DAO层写程序的历程吧:
我们来看看使用DbUtils之后,程序的代码是怎么样的:
配置管理类:主要管理配置文件的一个类
它拥有一个子类AnnotationConfiguration,也就是说:我们可以使用注解来代替XML配置文件来配置相对应的信息
通常我们在DAO层中都会有以下的方法,Session也为我们提供了对应的方法来实现!
我们在快速入门中使用到了save(Objcet o)方法,调用了这个方法就把对象保存在数据库之中了。Session对象还提供着其他的方法来进行对数据库的更新
我们来使用一下update()方法吧....既然是更新操作了,那么肯定需要设置主键的,不设置主键,数据库怎么知道你要更新什么。将id为1的记录修改成如下:
通过主键来查询数据库的记录,从而返回一个JavaBean对象
HQL是面向对象的查询语言,可以用来查询全部的数据!
当然啦,它也可以传递参数进去查询
//这里的?号是从0开始的,并不像JDBC从1开始的!
从上面的HQL查询,我们就可以发现:HQL查询是需要SQL的基础的,因为还是要写少部分的SQL代码....QBC查询就是完全的面向对象查询...但是呢,我们用得比较少
我们来看一下怎么使用吧: