介绍 slf4的api和最佳实践

在pom文件中加入下面的依赖

  <dependency>
		<groupId>org.slf4j</groupId>
		<artifactId>slf4j-api</artifactId>
		<version>1.7.2</version>
	</dependency>
	<dependency>
		<groupId>org.slf4j</groupId>
		<artifactId>slf4j-log4j12</artifactId>
		<version>1.7.2</version>
	</dependency>
	<dependency>
		<groupId>log4j</groupId>
		<artifactId>log4j</artifactId>
		<version>1.2.17</version>
	</dependency>

log4j.properties使用说明

# 输出级别的种类   ERROR、WARN、INFO、DEBUG

# 配置日志信息输出目的地,log4j.appender.appenderName = fully.qualified.name.of.appender.class

## org.apache.log4j.ConsoleAppender(控制台)

## org.apache.log4j.FileAppender(文件)

## org.apache.log4j.DailyRollingFileAppender(每天产生一个日志文件)

## org.apache.log4j.RollingFileAppender(文件大小到达指定尺寸的时候产生一个新的文件)

## org.apache.log4j.WriterAppender(将日志信息以流格式发送到任意指定的地方)

# 配置日志信息的格式,log4j.appender.appenderName.layout = fully.qualified.name.of.layout.class

## org.apache.log4j.HTMLLayout(以HTML表格形式布局)

## org.apache.log4j.PatternLayout(可以灵活地指定布局模式)

## org.apache.log4j.DailyRollingFileAppender(每天产生一个日志文件)

## org.apache.log4j.SimpleLayout(包含日志信息的级别和信息字符串)

## org.apache.log4j.TTCCLayout(包含日志产生的时间、线程、类别等等信息)

# 控制台选项

## Threshold=DEBUG:指定日志消息的输出最低层次。

## ImmediateFlush=true:默认值是true,意谓着所有的消息都会被立即输出。

## Target=System.err:默认情况下是:System.out,指定输出控制台

# FileAppender 选项

## Threshold=DEBUF:指定日志消息的输出最低层次。

## ImmediateFlush=true:默认值是true,意谓着所有的消息都会被立即输出。

## File=mylog.txt:指定消息输出到mylog.txt文件。

## Append=false:默认值是true,即将消息增加到指定文件中,false指将消息覆盖指定的文件内容。

# RollingFileAppender 选项

## Threshold=DEBUG:指定日志消息的输出最低层次。

## ImmediateFlush=true:默认值是true,意谓着所有的消息都会被立即输出。

## File=mylog.txt:指定消息输出到mylog.txt文件。

## Append=false:默认值是true,即将消息增加到指定文件中,false指将消息覆盖指定的文件内容。

## MaxFileSize=100KB: 后缀可以是KB, MB 或者是 GB. 在日志文件到达该大小时,将会自动滚动,即将原来的内容移到mylog.log.1文件。

## MaxBackupIndex=2:指定可以产生的滚动文件的最大数。

#  日志信息格式中几个符号所代表的含义

## -X号: X信息输出时左对齐;

## %p: 输出日志信息优先级,即DEBUG,INFO,WARN,ERROR,FATAL,

## %d: 输出日志时间点的日期或时间,默认格式为ISO8601,也可以在其后指定格式,比如:%d{yyy MMM dd HH:mm:ss,SSS},输出类似:2002年10月18日 22:10:28,921

## %c: 输出日志信息所属的类目,通常就是所在类的全名

## %t: 输出产生该日志事件的线程名

## %l: 输出日志事件的发生位置,相当于%C.%M(%F:%L)的组合,包括类目名、发生的线程,以及在代码中的行数

## %L: 输出代码中的行号

## %m: 输出代码中指定的消息,产生的日志具体信息

## %n: 输出一个回车换行符,Windows平台为"\r\n",Unix平台为"\n"输出日志信息换行

# 自定义类的设置 category

log4j.appender.fileout=org.apache.log4j.DailyRollingFileAppender

log4j.appender.fileout.Encoding=utf-8

log4j.appender.fileout.DatePattern =‘.‘yy-MM-dd HH‘\u65F6.log‘

log4j.appender.fileout.File=G:/log/jmoco_mag.log

log4j.appender.fileout.layout=org.apache.log4j.PatternLayout

log4j.appender.fileout.layout.ConversionPattern=-[%d{yy-MM-dd HH:mm:ss}]<%p><%c>{\u4FE1\u606F\uFF1A %m}%n

时间: 2024-10-21 19:28:42

介绍 slf4的api和最佳实践的相关文章

RESTful API 设计最佳实践(转)

摘要:目前互联网上充斥着大量的关于RESTful API(为了方便,以后API和RESTful API 一个意思)如何设计的文章,然而却没有一个”万能“的设计标准:如何鉴权?API格式如何?你的API是否应该加入版本信息? 背景 目前互联网上充斥着大量的关于RESTful API(为了方便,以后API和RESTful API 一个意思)如何设计的文章,然而却没有一个”万能“的设计标准:如何鉴权?API格式如何?你的API是否应该加入版本信息?当你开始写一个app的时候,特别是后端模型部分已经写完

[翻译] API测试最佳实践 - 身份验证(Authentication)

API测试最佳实践 - 身份验证 适用等级:高级 1. 概况 身份验证通常被定义为是对某个资源的身份的确认的活动,这里面资源的身份指代的是API的消费者(或者说是调用者).一旦一个用户的身份验证通过了,他将被授权访问那些期待访问的资源或API. 验证(Authentication)- 指的是对API最终使用者的确认的活动. 授权(Authorization)- 指对那些验证通过的用户能所能够访问的资源进行确认的活动. 2. 身份验证的标准(Authentication Standars) 身份验

RESTful API 设计最佳实践

1. 背景 REST(英文:Representational State Transfer,表述性状态转移)描述了一个架构样式的网络系统,比如 web 应用程序. 目前互联网上充斥着大量的关于RESTful API(为方便,下文中"RESTful API "简写为"API")如何设计的文章,然而却没有一个"万能"的设计标准:如何鉴权?API 格式如何?你的API是否应该加入版本信息?当你开始写一个app的时候,特别是后端模型部分已经写完的时候,你

RESTful API 设计最佳实践(转)

背景 目前互联网上充斥着大量的关于RESTful API(为方便,下文中“RESTful API ”简写为“API”)如何设计的文章,然而却没有一个”万能“的设计标准:如何鉴权?API 格式如何?你的API是否应该加入版本信息?当你开始写一个app的时候,特别是后端模型部分已经写完的时候,你不得不殚精竭虑的设计和实现自己app的public API部分.因为一旦发布,对外发布的API将会很难改变. 在给SupportedFu设计API的时候,我试图以实用的角度来解决上面提到的问题.我希望可以设计

API测试最佳实践 - 身份验证

适用等级:高级 1. 概况 身份验证通常被定义为是对某个资源的身份的确认的活动,这里面资源的身份指代的是API的消费者(或者说是调用者).一旦一个用户的身份验证通过了,他将被授权访问那些期待访问的资源或API. 验证(Authentication)- 指的是对API最终使用者的确认的活动. 授权(Authorization)- 指对那些验证通过的用户能所能够访问的资源进行确认的活动. 2. 身份验证的标准(Authentication Standars) 身份验证的标准和技术太多了,比如, 2.

[翻译] API测试最佳实践 - 组织你的测试

组织你的测试 适用级别:初学者 在最底层,一个测试步骤(Test Step)用来验证一个单独的操作.组合若干测试步骤到测试用例,允许你验证那些被分隔出来的一个一个的功能,这些功能是应用程序所需要的.接下来,若干个测试用例可以组成一个测试套件(Test Suite),验证其中一个交付物的完整功能,这是用户想要的.最后,组合若干测试套件到一个测试工程(Test Project),就能验证一个完整产品的功能了. 词语工程(Project)和套件(Suite)某些情况下可以互换使用,但是意思都差不多,包

编写 Node.js Rest API 的 10 个最佳实践

Node.js 除了用来编写 WEB 应用之外,还可以用来编写 API 服务,我们在本文中会介绍编写 Node.js Rest API 的最佳实践,包括如何命名路由.进行认证和测试等话题,内容摘要如下: 正确使用 HTTP Method 和路由 正确的使用 HTTP 状态码 使用 HTTP Header 来发送元数据 为 REST API 挑选合适的框架 要对 API 进行黑盒测试 使用基于 JWT 的无状态的认证机制 学会使用条件请求机制 拥抱接口调用频率限制(Rate-Limiting) 编

[转]10个有关RESTful API良好设计的最佳实践

Web API已经在最近几年变成重要的话题,一个干净的API设计对于后端系统是非常重要的. 通常我们为Web API使用RESTful设计,REST概念分离了API结构和逻辑资源,通过Http方法GET, DELETE, POST 和 PUT来操作资源. 下面是进行RESTful Web API十个最佳实践,能为你提供一个良好的API设计风格. 1.使用名词而不是动词 Resource资源 GET读 POST创建 PUT修改 DELETE /cars 返回 cars集合 创建新的资源 批量更新c

10个有关RESTful API良好设计的最佳实践

Web API已经在最近几年变成重要的话题,一个干净的API设计对于后端系统是非常重要的. 通常我们为Web API使用RESTful设计,REST概念分离了API结构和逻辑资源,通过Http方法GET, DELETE, POST 和 PUT来操作资源. 下面是进行RESTful Web API十个最佳实践,能为你提供一个良好的API设计风格. 1.使用名词而不是动词 Resource资源 GET读 POST创建 PUT修改 PATCH部分修改 DELETE /cars 返回 cars集合 创建