Hibernate/Spring/Struts架构使用OpenSessionInView的问题

applicationContext是有层次的，那样的方式会让struts plugIn中配置的sessionFactory比root中的sessionFactory占优，这个struts plugIn中的bean都是访问这里配置的sessionFactory。

都是高 人啊

opensession的最大问题还是长链接的时候无法释放session的问题，在对外系统中问题尤为突出。springMVC可以仗着先天优势用interecptor，但是webwork可就没有这样的优势了，尝试自己做一个适合webwork的，但是发现一旦有安全框架介入，session作用的切面就变得难以把握。到现在还无果~~~~

在 ContextLoaderPlugIn 类的 initWebApplicationContext() 方法中

WebApplicationContext parent = WebApplicationContextUtils.getWebApplicationContext(getServletContext(););;

		WebApplicationContext wac = createWebApplicationContext(parent);;

在 createWebApplicationContext(WebApplicationContext parent) 方法中 可以看到

ConfigurableWebApplicationContext wac =
				(ConfigurableWebApplicationContext); BeanUtils.instantiateClass(getContextClass(););;
wac.setParent(parent);;

也就是说 在这个plugin里创建的ApplicationContext 的 parent 是 ContextLoaderListener 创建的 ApplicationContext ，是这样一个层次关系
所以，还是要把含有SessionFactory 配置的文件作为 ContextLoaderListener  初始化参数

据说可以做个ResponseWrapper，把所有的页面内容生成完，再向浏览器输出，不过我怀疑，如果是对外系统，并发量大的话，内存消耗也是很客观。

web下用filter 那么普通程序下这个问题怎么做呢！

遇到同样的问题。发现，和downpour说的第2种配置一样。采用了downpour的方案解决了问题。又多学了一课。

  我觉得这个问题讨论的原因是，大家没有了解J2EE的思想，既然大家都知道B/S，知道系统分层，既然系统分了WEB，业务，DAO等层，那么SPRING的配置文件还放在一个XML里面，这个不是自己打自己脸。
   我用SPRING从来是根据系统的分层把配置文件分层，然后写个类来收集配制文件，这样每个项目只要把配制文件写到特定的方法里就可以了。
   事业说一个基础的构件是项目前不可缺少了！

  说不上一定要OpenSessioInView，OpenSessioInView以后带来了什么优点，有什么缺点？
如果不用OpenSessioInView这个缺点会出现多少次？
  我是很少OpenSessioInView的，我觉得这样把数据库与WEB都耦合了，但是在特殊情况下也可以这样做，但是如果不做说不上就没有办法解决了啊？
   我觉得由于SESSION的问题造成的不同SESSION的问题不是很多，可以在DAO层封装个方法，来强行LOAD也可以解决啊。
   解决问题方式多样，要看什么更适合当前的问题，而不是一定采用那个方式。
   也许有人说：我说的于帖子不符合把3，个人见解，做J2EE时间不长。从硬件转J2EE的，但是我觉得任何东西都有思想，使用要灵活

都是高手呀