L 的专栏

一、规范中的SESSION描述（PortletSession objects must be scoped at the portlet application context level. Each portlet application has its own distinct PortletSession object per user session. The portlet contai

二、LIFERAY中的实现LIFERAY在构建ActionRequestImpl和RenderRequestImpl时，会设置PORTLET SESSION，如下代码所示：public RenderRequestImpl(HttpServletRequest req, Portlet portlet,        CachePortlet cachePortlet,        Portlet

问题：当业务使用了SSESSION保存某些对象，怎样在集群时复制这些对象？TOMCAT5已经考虑过这种集群所导致的问题，其实也就是cluster的问题。如果采用了TOMCAT 的cluster解决方案，我相信应该可以保证session等信息的同步可操作。另外，TOMCAT要求放到SESSION里的对象要需要实现Serializable，以确保各个对象能被正常复制。有人提出疑问，SESSION使用的

最近花了点时间研究Ioc，这的确是一个好东东。IoC的概念很是悬乎（主要是被国内同胞解释出来的），刚开始还真的晕了头，后来在一位仁兄的文章中看到了最为通俗的解释：就是通过XML文件定义来生成对象。IoC还有另外一个别名：Dependence Injection。意思是依赖注入，看起来比IoC好懂，但总的来说，还是上面的解释好！这个解释真的很清楚明了，也让我真正的进入IoC中来了。随着不段的深入，我

三、问题由于上述原因，LIFERAY可能面临如下问题：- 用户本来是想保存私有的数据到本应用的SESSION中，但是实际上却保存到PORTAL系统的SESSION对象中了- 其他应用的可以随意的访问不属于本应用的SESSION 数据- 其他系统可以随意访问PORTAL系统的SESSION数据- 不同的应用不能使用相同的KEY来保存数据，如果这样做，则会相互覆盖数据。以上是我对LIFERAY的一点分

今天看了TOMCAT的Ajp13这个类的源代码，发现一个很值得注意的地方，那就是不管是否继承了某类，都在构造函数中调用super()方法。我已经看了一些关于TOMCAT的代码了，但是以前却没有发现该现象。今天不知道怎的，突然发现它了。*********************    public Ajp13() { super(); initBuf();        reqHandler=new

系统使用Hibernate, 感觉还可以. 从其强大的功能中获利不少. 于是hibernate 3.1出来后, 就升级到了这个版本. 但是新版本的一个Event机制, 却透露出其设计的一个大毛病.在hibernate 3.1中, 所有的操作都是由Event来驱动的. 于是就存在了各种各样的EventListener. 按照设计原理, 既然是EventListener, 而且可配置, 那么就可以去掉

今天又看到一篇讨论Spring的文章: http://blog.youkuaiyun.com/easyjf/archive/2006/07/12/910060.aspx我不知道为什么这样的讨论会激发出人们丑恶的一面. 可能是人们的私心在作怪吧. 每个人都想证明自己是正确的, 自己大理论应该得到大家大认同. 其实这个没有什么可以争论的, 对于不同的应用环境Spring绝对不能全部适应. 在有些环境下,