最近协助项目组部署 Tomcat 时遇到一种情况：同一 Tomcat 下多 war 包部署时，有一个简单的应用无法启动，所有日志渠道中都没有关于它异常信息，catalina 日志中只轻描淡写地说它部署失败了。在该应用的类路径下放置一个 logging.properties 文件后，看到了完整异常，最终改正配置、重启得以成功部署。
笔者因此对 Tomcat 日志框架产生了几个疑问：
为什么 catalina 日志文件中没有具体应用的异常信息
如何让应用启动异常信息输出
应用类路径下的 logging.properties 和 Tomcat 的 conf 目录下的该文件的关系如何
Tomcat 是如何做到应用日志隔离的
本场 Chat 将以笔者弄清楚上述疑惑的过程为背景，详细介绍 Tomcat 对 java.util.logging 的日志框架“偷梁换柱”的底层支撑：
java.util.logging 原始包中的 LogManager 
Tomcat 的 JULI 是什么
Tomcat 的 ClassloaderLogManager 是如何加载日志配置的
ClassloaderLogManager 替换 LogManager 的巧妙过程
官方日志配置的几点建议
启示录：-D , Java 中让人叹为观止的一种发明
阅读全文: http://gitbook.cn/gitchat/activity/5cdc9882f3f5110cf3822c3f
您还可以下载 CSDN 旗下精品原创内容社区 GitChat App ，阅读更多 GitChat 专享技术内容哦。

关于Fastjson 数组解析异常问题的排查

今日在使用字符串转json的时候，遇到问题，发现转换失败，

报错日志如下：
com.alibaba.fastjson.JSONException: expect '[', but string, pos 8, line 1, column 9"G2京沪高速"
	at com.alibaba.fastjson.util.TypeUtils.castToJavaBean(TypeUtils.java:1366)
	at com.alibaba.fastjson.util.TypeUtils.cast(TypeUtils.java:932)
	at com.alibaba.fastjson.JSONArray.toJavaList(JSONArray.java:450)
	at com.hysm.service.impl.OtaProviderServiceImpl.getRoutePriceAndPath(OtaProviderServiceImpl.java:772)
	at com.hysm.service.impl.OtaProviderServiceImpl.getResultMessage(OtaProviderServiceImpl.java:187)
	at sun.reflect.GeneratedMethodAccessor79.invoke(Unknown Source)

遂紧急排查问题，定位到报错代码如下：
JSONArray paths = json.getJSONObject("route").getJSONArray("paths");
List<Paths>     pathsList = paths.toJavaList(Paths.class);

将原始字符串获取下来，线下测试确实无法转换。但是经过测试 发现 原来是获取高德路径规划接口的时候，高德返回参数值不规范。

接口连接：https://restapi.amap.com/v3/direction/driving

此接口的 toll_roal 如果为空则返回列表，有值则返回字符串。

大厂神奇的规范不深做吐槽。
接下来有发现一个有意思的事情：
JSONArray paths = json.getJSONObject("route").getJSONArray("paths");
 List<Paths> pathsList = JSON.parseArray(paths.toJSONString(),Paths.class);

此代码又可以正常运行！！ why？

都是fastjson提供的方法，为什么会形成差异。
带着问题进入源码，先看 JSONArray.toJavaList。
public <T> List<T> toJavaList(Class<T> clazz) {
        List<T> list = new ArrayList(this.size());
        ParserConfig config = ParserConfig.getGlobalInstance();
        Iterator var4 = this.iterator();

        while(var4.hasNext()) {
            Object item = var4.next();
            T classItem = TypeUtils.cast(item, clazz, config);
            list.add(classItem);
        }

        return list;
    }

关键代码是里面的 TypeUtils.cast()。

TypeUtils的代码比较丑，基本就是根据字段类型来进行值的转换。
public <T> T deserialze(DefaultJSONParser parser, Type type, Object fieldName) {
        if (parser.lexer.token() == 8) {
            parser.lexer.nextToken(16);
            return null;
        } else if (type == JSONArray.class) {
            JSONArray array = new JSONArray();
            parser.parseArray(array);
            return array;
        } else {
            Collection list = TypeUtils.createCollection(type);
            Type itemType = TypeUtils.getCollectionItemType(type);
            parser.parseArray(itemType, list, fieldName);
            return list;
        }
    }

关键的地方来了：
public void parseArray(Type type, Collection array, Object fieldName) {
        int token = this.lexer.token();
        if (token == 21 || token == 22) {
            this.lexer.nextToken();
            token = this.lexer.token();
        }

        if (token != 14) {
            throw new JSONException("expect '[', but " + JSONToken.name(token) + ", " + this.lexer.info());
        } else {
            ObjectDeserializer deserializer = null;
            if (Integer.TYPE == type) {
            

很明显，此处的toll_road字段 因为定义的是List 所以在经过fastjson的jsonarray的list解析器的时候，发现值类型不匹配 抛出异常。 逻辑合理。
下面来看看JSON.parseArray(paths.toJSONString(),Paths.class); 这段代码的实现。

里面的方法实现：
public static <T> List<T> parseArray(String text, Class<T> clazz) {
        if (text == null) {
            return null;
        } else {
            DefaultJSONParser parser = new DefaultJSONParser(text, ParserConfig.getGlobalInstance());
            JSONLexer lexer = parser.lexer;
            int token = lexer.token();
            ArrayList list;
            if (token == 8) {
                lexer.nextToken();
                list = null;
            } else if (token == 20 && lexer.isBlankInput()) {
                list = null;
            } else {
                list = new ArrayList();
                parser.parseArray(clazz, list);
                parser.handleResovleTask(list);
            }

            parser.close();
            return list;
        }
    }

发现最后进入的是 JavaBeanDeserializer 这个类。和上面的解析器不同。中间代码也是比较难看的类型比对，跳过。比对后进入ArrayListTypeFieldDeserializer。

关键代码如下：
public void parseField(DefaultJSONParser parser, Object object, Type objectType, Map<String, Object> fieldValues) {
        JSONLexer lexer = parser.lexer;
        int token = lexer.token();
        if (token != 8 && (token != 4 || lexer.stringVal().length() != 0)) {
            ArrayList list = new ArrayList();
            ParseContext context = parser.getContext();
            parser.setContext(context, object, this.fieldInfo.name);
            this.parseArray(parser, objectType, list);
            parser.setContext(context);
            if (object == null) {
                fieldValues.put(this.fieldInfo.name, list);
            } else {
                this.setValue(object, list);
            }

        } else {
            this.setValue(object, (String)null);
        }
    }

进入parseArray 方法。
while(true) {
                if (lexer.isEnabled(Feature.AllowArbitraryCommas)) {
                    while(lexer.token() == 16) {
                        lexer.nextToken();
                    }
                }

                if (lexer.token() == 15) {
                    lexer.nextToken(16);
                    break;
                }

                Object val = itemTypeDeser.deserialze(parser, (Type)itemType, i);
                array.add(val);
                parser.checkListResolve(array);
                if (lexer.token() == 16) {
                    lexer.nextToken(this.itemFastMatchToken);
                }

                ++i;
            }

重点来了，上述的

Object val = itemTypeDeser.deserialze(parser, (Type)itemType, i);

array.add(val);

他是先将list 实例话，在去获取里面的值，最后进行插入。而没有进行严格的类型校验。

这个做法可以说是比较灵活，但是实际使用过程中，因为定义的不规范可能又会引发其他更可怕的问题。

使用Hive进行分析的过程中遇到了这个异常的信息，一开始看到比较惊讶，因为感觉代码并没有什么不太合理的地方，不过还是抛出了一堆的异常信息，我把日志信息读了一下，发现导致最终异常的是FastJson在封装的时候找不到无参构造函数，虽然最终原因不是Hive引起的，但是上面的一堆异常也的确是唬人的。
异常信息
Error: java.lang.RuntimeException: org.apache.hadoop.hive.ql.metadata.HiveException: Hive Runtime Error while processing row {"sourceid":"4649475029B8","sourcelabelw":"[{\"Name\":\"XX\",\"Weight\":6},{\"Name\":\"XX\",\"Weight\":6}]"}
        at org.apache.hadoop.hive.ql.exec.mr.ExecMapper.map(ExecMapper.java:195)
        at org.apache.hadoop.mapred.MapRunner.run(MapRunner.java:54)
        at org.apache.hadoop.mapred.MapTask.runOldMapper(MapTask.java:430)
        at org.apache.hadoop.mapred.MapTask.run(MapTask.java:342)
        at org.apache.hadoop.mapred.YarnChild$2.run(YarnChild.java:167)
        at java.security.AccessController.doPrivileged(Native Method)
        at javax.security.auth.Subject.doAs(Subject.java:396)
        at org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1556)
        at org.apache.hadoop.mapred.YarnChild.main(YarnChild.java:162)
Caused by: org.apache.hadoop.hive.ql.metadata.HiveException: Hive Runtime Error while processing row {"sourceid":"4649475029B8","sourcelw":"[{\"Name\":\"XX\",\"Weight\":6},{\"Name\":\"XXX\",\"Weight\":6}]"}
        at org.apache.hadoop.hive.ql.exec.MapOperator.process(MapOperator.java:550)
        at org.apache.hadoop.hive.ql.exec.mr.ExecMapper.map(ExecMapper.java:177)
        ... 8 more
Caused by: org.apache.hadoop.hive.ql.metadata.HiveException: Unable to execute method public java.lang.String cn.siti.main.MergeUDF.evaluate(java.lang.String,java.lang.String)  on object cn.siti.main.MergeUDF@9fd062 of class cn.siti.main.MergeUDF with arguments {[{"Name":"XXX","Weight":6},{"Name":"XXX","Weight":6}]:java.lang.String, XXXX,7:java.lang.String} of size 2
        at org.apache.hadoop.hive.ql.exec.FunctionRegistry.invoke(FunctionRegistry.java:1243)
        at org.apache.hadoop.hive.ql.udf.generic.GenericUDFBridge.evaluate(GenericUDFBridge.java:182)
        at org.apache.hadoop.hive.ql.exec.ExprNodeGenericFuncEvaluator._evaluate(ExprNodeGenericFuncEvaluator.java:166)
        at org.apache.hadoop.hive.ql.exec.ExprNodeEvaluator.evaluate(ExprNodeEvaluator.java:77)
        at org.apache.hadoop.hive.ql.exec.ExprNodeEvaluator.evaluate(ExprNodeEvaluator.java:65)
        at org.apache.hadoop.hive.ql.exec.SelectOperator.processOp(SelectOperator.java:79)
        at org.apache.hadoop.hive.ql.exec.Operator.forward(Operator.java:793)
        at org.apache.hadoop.hive.ql.exec.CommonJoinOperator.internalForward(CommonJoinOperator.java:638)
        at org.apache.hadoop.hive.ql.exec.CommonJoinOperator.genAllOneUniqueJoinObject(CommonJoinOperator.java:670)
        at org.apache.hadoop.hive.ql.exec.CommonJoinOperator.checkAndGenObject(CommonJoinOperator.java:754)
        at org.apache.hadoop.hive.ql.exec.MapJoinOperator.processOp(MapJoinOperator.java:242)
        at org.apache.hadoop.hive.ql.exec.Operator.forward(Operator.java:793)
        at org.apache.hadoop.hive.ql.exec.TableScanOperator.processOp(TableScanOperator.java:92)
        at org.apache.hadoop.hive.ql.exec.Operator.forward(Operator.java:793)
        at org.apache.hadoop.hive.ql.exec.MapOperator.process(MapOperator.java:540)
        ... 9 more
Caused by: java.lang.reflect.InvocationTargetException
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at org.apache.hadoop.hive.ql.exec.FunctionRegistry.invoke(FunctionRegistry.java:1219)
        ... 23 more
Caused by: com.alibaba.fastjson.JSONException: default constructor not found. class cn.siti.domain.TagInfo
        at com.alibaba.fastjson.util.JavaBeanInfo.build(JavaBeanInfo.java:212)
        at com.alibaba.fastjson.parser.ParserConfig.createJavaBeanDeserializer(ParserConfig.java:486)
        at com.alibaba.fastjson.parser.ParserConfig.getDeserializer(ParserConfig.java:433)
        at com.alibaba.fastjson.parser.ParserConfig.getDeserializer(ParserConfig.java:288)
        at com.alibaba.fastjson.parser.DefaultJSONParser.parseArray(DefaultJSONParser.java:651)
        at com.alibaba.fastjson.parser.DefaultJSONParser.parseArray(DefaultJSONParser.java:630)
        at com.alibaba.fastjson.parser.DefaultJSONParser.parseArray(DefaultJSONParser.java:625)
        at com.alibaba.fastjson.JSON.parseArray(JSON.java:491)
        at cn.siti.main.MergeUDF.evaluate(MergeUDF.java:21)
        ... 28 more

在使用的过程中请注意这一点，Hive中报错的时候，先看日志，从上往下找最终导致异常的地方，然后进行解决。

此外有时候会遇到一个很无奈的问题
FAILED: Execution Error, return code 1 from org.apache.hadoop.hive.ql.exec.mr.MapRedTask 
 There are 3 datanode(s) running and no node(s) are excluded in this operation
本次运行中出现了这样的问题，我这边造成问题的主要原因是：nodemanager停止了，然后任务分发的时候出现问题。
重新启动yarn即可
转载注明出处：Hive数据仓库--HiveUDF异常解析与其中的坑

前言
就在今天遇到一个很诡异的技术问题，Unity调用Quick苹果SDK支付。Quick 支付需要游戏(Unity)传入一些数据到原生OC中，格式是json,在OC中打印的日志看着数据是没问题的，但是解析json却一直显示失败 。问题最终还是解决了，用倒推法给大家说一下解决的思路。

场景重现
下面代码是OC中定义的支付方法，void *payData是接Unity中传过来的支付json数据，当用户点击支付按钮的时候，Unity把支付的数据传到IOS 原生OC中。没有了解过的可以看下之前写过的文章 :Unity接入ios SDK(小7手游)没有你想的那么难。
//支付
void SDk_pay(void *payData){
       NSLog(@"SDk_pay"); //控制台展示这段日志说明Unity调用到了OC的支付方法

       NSString *idList = [NSString stringWithUTF8String:payData];
       NSLog(@"获取的支付数据=======：%@",idList);

       //将解析得到的内容存放字典中，编码格式为UTF8，防止取值的时候发生乱码

       NSData *jsonData = [idList dataUsingEncoding:NSUTF8StringEncoding];
       NSError *err;
       NSDictionary *dic = [NSJSONSerialization JSONObjectWithData:jsonData
                                               options:NSJSONReadingMutableContainers error:&err];
       
       if(err) {
           NSLog(@"json解析失败：%@",err);
           return;
       }
}

当点击完成支付按钮后，控制台显示Json解析异常日志如下所示：
json解析失败：Error Domain=NSCocoaErrorDomain Code=3840 "Unescaped control character around character 206." 
UserInfo={NSDebugDescription=Unescaped control character around character 206.}



解决问题思路和过程
上面解析Json异常去Google 上去搜了一下，根据搜索内容的解释,出现这个问题的原因就是：返回的Json字符串里面有换行符、空格。既然知道是什么原因导致的，那么我们一步步分析一下。
NSLog(@“SDk_pay”);控制台有这么一段日志，说明Unity调用OC的支付方法是没问题的，成功调用到了。再看下一个日志点，获取Unity传过来的数据 idList ,传过来的数据字段如下代码：

看着上面显示的日志乍一看返回的数据都是正常，没有什么特殊啊？但是异常报错不会错的。于是把我上面的Json数据放到了格式化工具上查看，果然发现了问题所在。Json中 orderid字段多一个空格(截图中小红点就是一个空格)。

既然知道是订单号的问题，我们来倒推一下，订单号(orderid字段)是拼的加密字符串由游戏服务器原样返回，其中一部分数据取自客户端的ChannelId。我把代码贴出来乍一看还是没问题吧。

其实所有问题的关键都指向了return MakeStringCopy(“10184”)这货。最开始我定位到GetSdkChannelId()方法里了，但是怎么看怎么也不像有空格的样子啊？于是我尝试用光标一点点试看有没有空格，一试果然试出问题了。
下面截图就是我从有问题的那段注释里copy出来放到VSCode里面，一看10184后面已有一个空格的。当时我都惊了，同一个字符串在Xcode里面显示的正常,在VSCode里面却多出一个空格。
Xcode(11.5版本)还有这个操作？ 由于我不是专业搞IOS的，我查了资料还有询问了一些写IOS的朋友。最终结论基本上都是Xcode编译器自带的Bug。把空格去掉继续跑程序，一点事都没有。事情就这样解决了，你学废了吗？

结尾
如果文章对你有帮助留下一个赞呗，你的支持是我继续写下去的动力,如有不对劳烦大家多多指正。