今日完成

1.完善昨天的上传和修改图片功能。这个第三方Api看着挺好用的，整合到系统架构里面真的是bug不断。今天主要讲问题吧，没什么新内容。

遇到问题

1.还是redis。

（1）昨天因为添加字段修改了pojo类的字段。然后昨天之前存在redis中的内容也还在服务器上面，今天启动的时候就报错了，说序列化的uid不一致。听师兄解释后才知道这个反序列化的标示，用于确认是否是同一对象。

解决方案：进入redis-cli，使用命令flushall，删除所有缓存。

（2）redis

按照师兄的配置配了，还是时不时的报错，timeout。还没找到是什么问题。

2.springmvc

（1）使用mutlipartfile接收前端回传的文件，但是这种方式只支持post请求与get请求，也就是说，修改界面使用的一个假的put方法不会被前端控制器识别。导致报错500

post method didnot support

解决方案：将修改页面的的请求方式修改为post.

分析：主要问题还是出在enco上面，form请求的默认方式是application。即使不加这个，系统默认也有 ①application/x-www-form-urlencoded(默认值)
 ②multipart/form-data

使用后者那么http传输的方式也会发生变化。

参考：http://blog.csdn.net/xiaojianpitt/article/details/6856536

（2）调试bug

用户提交头像后，进入修改页面查看头像，有两种情况需要考虑，添加了新图片。那么需要删除原来的图片，上传新的图片，如果没有添加那么图片上传的内容就不处理。

相应的代码实现：

//如果picFile不为空，执行上传
if (null != picFile) {
    String newFilePath = FileUtils.uploadxx(picFile);
    //得到原图片路径
    String oldFilePath = studentCustom.getPic();
    //如果原图片不为空，删除原图片
    if (null != oldFilePath) {
        FileUtils.deleteObject(oldFilePath);
    }
    //set新的图片路径
    studentCustom.setPic(newFilePath);
}
//更新信息
studentService.updateStudent(id, studentCustom);
return "redirect:studentslist";

（3）诡异的事情出现了，添加用户后，上传了相应的图片，再次进入修改页面，不上传图片提交，可以看到这个mutlipartfile 里面尽然不是空的。那么后面逻辑就全乱套了。

解决方案：

推测，这个文件一定是上次操作遗留下来的。因为在将mutlipartfile 转换为file的时候使用了临时文件。 可以看到这个里面还有

1.在controller里面添加request，看看这个文件到底哪儿来的。可以看到使用mutlipartfile 之后，request的结构也发生了变化。

2.尝试上传完了把临时文件删除了。

debug看一下临时文件的位置。

这两个文件名不一样，不是这个地方的。

3.正常提交比对。只有大小不一样

解决问题。

（4）上传图片完成后一直弹这个

解决方案

关闭腾讯云的客户端

明日计划

1.用户注册验证，手机号验证。

收获

1.又发现一个十分强大的功能。

页面的日期字符串类型，在Long型前面加一个@DateFormt就可以直接把日期字符串转换为long型。具体操作：

2.如果想用含有long型bean类去接收的话。这样就可以转换器什么的全省了。