Java Web笔记

这里整理的是在编写JavaWeb时会出现的一些错误，以及解决方案。期间也会借鉴一些百度，CSDN等网站的知识，不妥之处还请见谅！同时呢，我也会在接下来的学习中不断完善整理出更多的问题和解决方案。

                                                                                                            JavaWeb问题

一、 Context [/javaweb01] startup failed due to previous errors

可能出错的地方：

1.web.xml文件  web应用部署描述符，里面的部署的xml文件或者类，如果这些找不到就会发生startup failed due to previous errors错误。

2.如果在应用spring的话，在配置文件applicationContext.xml中定义的类、xml文件找不到也会报这个错误。

3.在web.xml，struts.xml，applicationContext.xml文件中自身有任何一点错误都可能引起上面的这个问题，而不仅仅是附带的文件错误导致。

4.如果使用ibatis的话，在SqlMapConfig.xml中定义的xml文件找不到也会报这个错误。（hibernate的配置在整合spring的时候使用spring的配置文件）

5.JDK的版本问题，最好使用JDK5.0 或者更高的版本。

6.Eclipse和tomcat的版本兼容问题

7.框架整合的过程中在导入到lib下的jar包冲突也可能产生该错误。

8.jar包的缺少以及jar包的版本也可产生该错误。

9.其他的原因

Tomcat先将文件编译成.java----再到.class

Servlet生命周期： 用户发送请求--实例化---初始化---di调用service处理请求（do get / do post）----停止服务器---销毁

第二个以后的用户发送请求不会再初始化，直接调用service

再整个tomcat服务器中servlet激怒有一份。

Alt+ Shfit + s

R: 生成 get set

O: 生成 构造函数

Request： 请求

Response: 响应

二、This kind of launch is configured to open the debug perspective whenit suspends 是什么意思？

因为设置了断点才会弹出这个，不需要调试的情况可以把断点去掉；
但需要调试的时候这个就重要了，所以选择“Yes”就好了，不要每次都弹出这个就勾选“Remeber my  decision”记住我的选择就好了。

 

三、JDBC为什么要使用PreparedStatement而不是Statement？

PreparedStatement是用来执行SQL查询语句的API之一，Java提供了 Statement、PreparedStatement 和 CallableStatement三种方式来执行查询语句，其中 Statement 用于通用查询， PreparedStatement 用于执行参数化查询，而 CallableStatement则是用于存储过程。

 

PreparedStatement是java.sql包下面的一个接口，用来执行SQL语句查询，通过调用connection.preparedStatement(sql)方法可以获得PreparedStatment对象。数据库系统会对sql语句进行预编译处理（如果JDBC驱动支持的话），预处理语句将被预先编译好，这条预编译的sql查询语句能在将来的查询中重用，这样一来，它比Statement对象生成的查询速度更快。

 

预处理语句的优势：

PreparedStatement可以写动态参数化的查询

PreparedStatement比 Statement 更快

PreparedStatement可以防止SQL注入式攻击

Alt+ shift + z :异常处理

 

四、jsp中的三种输出

1.<%= %>

2.<% out.print(“要输出的内容”);%>

3. <% out.write(“要输出的内容”);%>

 

五、java.lang.NullPointerException

异常处理错误，将出错代码的（SQLException e）改为（Exception e）

 

六、Type safety: Unchecked cast from Object to List<Book>

 

首先，java语言室类型安全的，通常我们遇到这个问题是出现在Object转化为目标类型时，

这个转化并不是安全的。这个问题普遍认为因为使用了jdk1.5或者1.6的泛型，

request.getAttribute("***")得到的是一个默认为Object的类型，当把他们转成List<***>时，编译器认为有可能会出错，所以提示这个类型安全。

但是具体如何解除这个警告呢，以下是大家普遍用的取消警告的方法（不过危险并没有解除）

一：方法上添加@SuppressWarnings("unchecked")

 

二：Eclipse的Window->Preferences->Java->Compiler->Errors/Warning->Generictypes中Unchecked generic type operation设置为Ignore。

 

三：Eclipse的Window->Preferences->Java->Compiler将Compiler compliance level 设置为小于1.5

七、解决乱码问题

1.在Tomcat的server.xml中加上如下代码：

<ConnectorURIEncoding=”UTF-8”/>

此方法仅仅只是对get提交方法起作用；

在Servlet中写的代码只能对post提交方法起作用。

代码解决：

Servlet说：response.setContentType("text/html;charset=GBK")

JSP说：<%@page contentType="text/html; charset=GBK"%>

IE听：<metahttp-equiv="Content-Type"content="text/html; charset=GBK">

 

请求参数乱码解决：

1.繁琐但完全有效(强转)，对post,get都会起作用。

new String(x.getBytes(“iso-8859-1”), ”gbk”)

2.只对post有效

request.setCharacterEncoding(“gbk”)在getParameter()前设置

3．只对get有效(server.xml)

<Connector port="8080“ ..............URIEncoding="GBK"/>

 

八、session与cookie

1.Session机制

存储用户登录信息

客户端向服务端发出首次请求，服务器为此客户端产生session对象，并将生成一sessionId,应答时返回到客户端，客户端保存此id。

当同一个客户端向服务器发出新的请求时，要将上次得到sessionId一同发出，服务器检查用户的sessionId，根据他取得对应session对象。

服务器分配的保存客户端私有信息的一块内存空间

SessionId是session的唯一标识

Session存储在服务器端，服务器通过SessionID将客户端与Session数据对应起来

在tomcat中的web.xml文件中可以使用以下配置来控制session过期时间：

<session-config>

 <session-timeout>15</session-timeout>

</session-config>

 

2.cookie机制

Cookie

保证客户端可用cookie     

 

3.cookie与session的比较

比较内容	Session	Cookie
保存方式	数据内容保存在服务器端	数据内容保存在客户端
安全性	数据比较安全	数据相对不安全
生命周期	使用内存存放数据，当用户长时间未请求服务器或服务器重启，内容可能丢失	保存在客户端的内存或文件中， 可以指定Cookie的生存周期
资源占用	占用服务器的内存	每次请求时发送Cookie内容，占用带宽
存放内容	可以存放各种数据类型的数据	只能存放字符串类型的数据