tomcat向weblogic移植需要注意的问题

1.在开发阶段，对应用程序热部署时，会抛出ClassCastException异常，这是因为类加载器的原因，因为在对程序热部署会由不同的类加载器加载同一个类，解决办法：重启weblogic或在console中WEB模块配置中对问题程序点击重新部署


2.用frameset实现的框架页面，其中的页面有时会得不到主页面的session,原因是frameset是放在一个htm页面上而不是ASPX页面。在一般情况下，如果frameset是aspx页面，当你请求页面时，它首先将请求发送到Web服务器，此时已经获得了SessionID，接着浏览器会分别请求Frame中的其他页面，这样所有页面的SessionID就是一样的，就是FrameSet页面的SessionID。然而如果你使用Html页面做FrameSet页面，第一个请求将是HTML页面，当该页面从服务器上返回是并没有任何Session产生，接着浏览器会请求Frame里面的页面，这样这些页面都会产生自己的SessionID，所以在这种情况下就会出现这种问题。当你重新刷新页面时，SessionID就会一样，并且是最后一个请求页面的SessionID。一个常见的误解是以为session在有客户端访问时就被创建，然而事实是直到某server端程序调用HttpServletRequest.getSession(true)这样的语句时才被创建，注意如果JSP没有显示的使用<%@pagesession="false"%>关闭session，则JSP文件在编译成Servlet时将会自动加上这样一条语句HttpSessionsession=HttpServletRequest.getSession(true);这也是JSP中隐含的session对象的来历。



3.编码问题：tomcat下缺省编码方式是ISO-8859-1,而在weblogic下缺省的编码是GBK，所以在对用URL传递的参数无须再做处理，比如在TOMCAT下要对参数的编码方式由ISO-8859-1转换为GBK，而在weblogic下就不能再这么做了，否则会出现乱码


4.对于用include包含的页面在tomcat下要单独对每个包含的页面指定编码方式，否则会出现乱码，但在weblgic下就不能这么做了，第一个原因是被包含的页面会遵从主页面的编码方式，第二个原因是如果重复定义JSP页面的编码方式，会使jsp页面无法编码，在运行时出错