我们知道，weblogic的工程比tomcat强大得多，用惯了tomcat，想从实际应用上比较一下二者的差别，于是决定先部署一个Servlet应用程序。

从服务器上下载weblogic应用程序，为了方便学习。决定使用比较老的版本，原因如下：

1. 程序较小，下载方便，等待时间较少

2. 早起的应用程序扩展功能可能较少，实际功能较新版本比较单一

3. 实际应用部署的多，可以查阅的资料比较多

在这里我使用的是weblogic8.1.6。在windows下按照向导顺利创建域mydomain。

接下来就是将该应用部署web应用程序中去。这里选用的集成开发环境是myeclipse。用myelipse关联weblogic,配置参数。由于配置域的时候忘记了账号和密码，这里先随便填一个，看它待会怎么报错！

按照常用的servlet的开发方式，在这里做一个简单的servlet的小程序。Servlet在web.xml中的配置如下：

HelloWorldServlet实现的功能是，当用户以get/post方式访问时，返回能够区分的话语，并在myeclipse中打印使用get/post哪个方法处理的此操作。部署，启动服务器。

不出意外，他果然报错了！详细信息大致如下：

什么意思？由于流的序列化原因造成本地类不兼容，以至于找到的类不能使用。它怎么不是weblogic的账号和密码不匹配啊？经过查找的资料和验证，据说是jre的版本太高了，换成weblogic自带的jre就行了。jre的版本太高了？不是都可以向下兼容的吗？难道是weblogic的自带的jre中的包与系统的jre包有什么不同（weblogic自己添加了新的包）？先不管照着做就行了。重新启动服务器，不出意外他又报错了！这次的是weblogic.security.SecurityInitializationException: Authentication denied: Boot identity not valid; The user name and/or password from the boot identity file (boot.properties) is not valid. 

……

好的，这次是账号和密码问题，意料之中嘛。怎么办？删掉这个域，再重新创建？还是看能不能冲配置文件中找到用户名和密码。查看配置文件，大致在这个地方

好像被加密了，不做死就��会死。找资料发现，可以如下这般……

1. cd到你的域目录（domain home）

2.运行java -cp <weblogic_home>\weblogic81\server\lib\weblogic.jar weblogic.security.utils.AdminAccount adminuser adminpassword .

参数第一个adminuser是你增加一个新用户的用户名��第二个参数adminpassword是该新用户的密码；第三个参数（一个.）是指当前目录（域目录）

注意：千万不要忘了第三个参数“.”,这不是句末结尾的英文句号！

3.删掉myserver/ldap/DefaultAuthenticatormyrealmInit.initialized 

4.删掉 boot.properties   (如果有的话)

5.重启server

恭喜，这次它又异常了，还有完没完？

这次的异常大概是这样的：Deployment descriptor "web.xml" is malformed. Check against the DTD: org.xml.sax.SAXParseException: cvc-elt.1: Cannot find the declaration of element 'web-app'.“你的web.xml是畸形的，……你的dtd有问题。”怎么可能？创建web项目之后不是都有web.xml文件吗，并且从来没有出现过问题？并且在工作空间下还能够看到这个文件没有出现警告或者红叉啊！你出毛病了吧？再找找吧……

这次的情况是这样的，每一个xml文件如果有<!DOCTYPE……就表示他是要符合某一个规范的，这个约束文件可以是scheme也可以使DTD，一般它会在本地找，然后才通过联网校验。在这里这个校验没有通过，所以他不承认这个web.xml。

解决方法：不能用以前这中xml配置了：

好吧，你狠，你的地盘你做主吧！继续重启服务器。有惊无险，��个世界清静了。终于没有报错了。应该能运行了吧？

访问：

错误代码 500，控制台报错：,

你不能这样欺负人啊！这又是什么？还是找不到？打开weblogic的应用目录，明明有那个文件，你瞎了？

管他呢，先试试index.jsp能否显示，结果又能正常访问，怎么回事？

原因：出现java.lang.UnsupportedClassVersionError 错误的原因，是因为我们使用高版本的JDK编译的Java class文件试图在较低版本的JVM上运行，所报的错误。 
因为，高版本的JDK生成的class文件使用的格式，可能与低版本的JDK的.class文件格式不同。这样，低版本的JVM无法解释执行这个.class文件，会抛出java.lang.UnsupportedClassVersionError不支持的Class版本错误。这个错误尤其在JDK5与JDK5之前的版本上表现明显。因为，JDK5在Java语法上作了不少增强，引入了一些新的.class文件的元素，导致旧版本的JVM无法解释、执行.class文件。即使这个类并没有使用任何JDK5的新元素，但是JDK5生成的.class文件，JDK1.4及其以前的JVM都无法辨认！

由于index.jsp的文件在weblogic的jsp解析引擎中转成的.class文件，使用的是weblogic的jdk，所以又能够访问其中的jsp文件。难道就全部使用jsp文件？这不可能！

好吧，既然这样，最好的解决方法莫过于下载新版本的weblogic应用程序。这可能要花费一段时间，既然这样，能不能试试其他的解决方法。降低应用程序的编译环境。注意是编译环境不是执行环境。

再次重启服务器，程序照样正常运行。访问等待……

至此，servlet算是在weblogic上运行起来了。

现在总结出现问题的原因：

1.思维没有转变过来，在servlet方面。虽然tomcat和weblogic都按照j2ee规范实现了servlet,但是二者在实现上还是有差别的。

2.Weblogic和开发环境的工程项目都有一个jre。在加载文件.java,.jsp文件的时候，工程项目中的jre负责将.java编译成可以被weblogic执行的.class文件。当请求过来的时候，如果需要，weblogic会加载此class文件，考虑到一般程序的向下兼容，因此，项目中使用的jre环境应该小于或等于weblogic的使用环境，jdk1.4和jdk5的差距应该被特别注意。当然，项目中用于编译.java文件的jre的编译水平低于weblogic也是可以的。该jre几乎不负责项目的运行，因此，这种情况下，运行环境（使用版本）无需太在意。

3.从这些错误报告中大致可以看出，用weblogic部署servlet应用程序时的一般执行流程大致是这样的：weblogic绑定jre启动服务——>加载weblogic的配置文件config.xml，同时审计myeclipse中配置的weblogic的域的信息——>如果通过，加载web项目中的web.xml文件，并检查该文件是否符合标准——>按照web.xml中配置的监听器，过滤器，servlet等加载并由项目中的jre编译对应.java文件，当用户请求时，weblogic先监听请求，如果是以一个请求，加载.class文件，在执行对应的servlet服务……