1手动编译servlet工程：
要编译servlet，则类路径classpath中必须包括Servlet API 的相关类，如果使用的web容器是Tomcat，则这些类通常封装在在tomcat的lib目录中servlet-api.jar。上面的编译出的.class文件会出现在build的classes目录中，并有对应的包层级。（上一篇随笔已讨论过，如果系统classpath设置第三方jar包路径了，编译时就不需手动加上包路径）
Eclipse这种IDE会自动完成类路径设置，并完成编译等事宜。
2 如何引入tomcat的lib下jar包，如常用的tomcat-api.jar
项目右键Build path --Add Library选择 Server runtime ,next后点击Apache Tomcat .OK
操作完成后，工程Libries下就有了Apache Tomcat库
3 对于sqljdbc4.jar包所放位置问题
（1）普通的Java Project:
右键构建路径添加扩展包，找到sqljdbc4.jar所在位置。结果如下图。
（2）动态网站
放在WEB-INF/lib下.
注意：复制包到WEB-INF/lib下，会发现Libraries下的Web App Libraries就有了相应jar包。
说明：web-inf下的lib目录:主要存放我们web程序下需实现某个功能所需要的jar包。.WEB-INF 是WEB容器路径，也就是说，当把应用部署到网络上去的时候。程序会到WEB-INF\LIB 下去找相应的包。 jar包：ar包就是别人已经写好的一些类，然后将这些类进行打包，你可以将这些jar包引入你的项目中，然后就可以直接使用这些jar包中的类和属性了，这些jar包一般都会放在lib目录下的。 如：文件上传功能需要使用到commons-fileupload-1.2.1.jar，commons-io-1.3.2.jar。连接Oracle数据库需要使用到ojdbc14.jar
不同工程jar所放位置不同分析原因：
通俗的讲是和classLoader有关，对于纯java项目，它不存在WEB-INF目录，所以在引入jar包的时候一般都是通过buildpath直接引入，例如我要引入sqljdbc4.jar，那么先定义一个user library，然后通过build path引入。
纯java项目使用的本地自己的JRE，那么classLoader在加载jar和class时候是分开的，对于我们自己编写的class，会在APP_HOME/bin下。导入的jar包或者user library的配置信息会出现在APP_HOME/.classpath文件中，ClassLoader会很智能去加载这些classes和jar。
.classpath文件内容如下：
<?xml version="1.0" encoding="UTF-8"?>
<classpath>
<classpathentry kind="src" path="src"/>
<classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/JavaSE-1.7"/>
<classpathentry kind="con" path="org.eclipse.jdt.USER_LIBRARY/lei"/>
<classpathentry kind="output" path="bin"/>
</classpath>
而对于java web项目，就不一样了，虽然eclipse的workspace中仍然有.classpath文件，你导入的了自己定义的user library，也会出现在.classpath中，但就是不去加载。这到底是为什么呢？？？
对于java web项目，它最终不是通过本地的JRE去运行，而是部署到web 服务器，如Tomcat、Weblogic、WebSphere等，这些服务器都实现了自身的类加载器。
以Tomcat典型结果为例，它的目录结构分别对应四个不同的类加载器，关系如下：
common --- CommonClassLoader
server --- CatalinaClassLoader
shared --- SharedClassLoader
webapps --- WebappClassLoader
我们的 web 应用都是部署到 webapps 目录下，而WebappClassLoader加载器专门负责加载 webapps 下所有web项目的 WEB-INF 下的类库和类文件。而我们通过 user library 引入的 jar 包自然不会被 WebappClassLoader 加载器加载，所以才会出现 ClassNotFoundException 。
比如tomcat应用服务器,它有其自己的类加载器,根据J2EE的规范去%web-project%/WEB-INF/lib的规范去找相应的lib,这就是为什么我们发布的WEB应用要符合那个格式
另有说法：eclipse工程下的library是用来编译里面的src中java文件的 实际发布到tomcat时,仅仅只复制了WEB-INF/lib里面的jar包,所以出现eclipse可以正常编译但tomcat运行是找不到类,
总结：如果是编译java代码用到的jar可以作为library引用，如果是框架非java代码部分用到的jar就必须放在WEB-INF/lib
3. 使用标注（@WebServlet("/Servlet3")）来定义Servlet是Java EE 6中 Servlet 3.0之后才有的功能，先前的版本必须通过web.xml定义相关Servlet信息。在Servlet3.0中，也可以使用web.xml来定义servlet，会覆盖掉标注。
<servlet>
<servlet-name>Serv</servlet-name>
<servlet-class>com.lei.Servlet3</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>Serv</servlet-name>
<url-pattern>/myservlet1</url-pattern>
</servlet-mapping>
注意： <servlet-name>可以为任意名字。
注意：建工程的时候，自动生成的web.xml在哪WEB-INF下
二 . BAE
实验算是成功，外网可以访问到了。后期可以学学连mysql，BAE支持这个数据库。
问题：1 目前只能是新建个版本，svn check out下来 ，按默认的目录把相应文件放进去，这相当于是BAE帮我们维护的文件组织形式。
Src放的是源码即.java文件，里面是BAE默认的包结构，可以整个替换src目录。
Svn commit后，会提交到BAE，BAE后台会帮我们编译（支持JAVA，就是说明有JAVA编译器）有错误在云平台也可以查看。至于编译后的目录我们无法查看
（即看不到编译后的.class文件）。不像在本地编译好后，我们可以查看发布到tomcat的包结构。
WEB-INF目录进去，classes放的是编译好的.class文件。
（本地的tomcat的webapps中放置的是部署到Tomcat的编译过的组织结构）
BAE帮助文档中说
所用的web容器是jetty,当用户通过SVN更新项目代码后，执行环境自动将编译为标准的WAR包后发布。
不同容器维护的工程结构不同，所以不能直接上传由eclipse导出的war包。不支持，所以无法访问。
注意，目前BAE不支持servlet标注定义servlet的url。只能通过web.xml来配置。所以eclipse生成的标记通过svn上传时可以删掉，不删也没影响，但是必须在xml中配置好。
