积累,创造,分享!

按照hibernate3的官方中文说明文档，进行配置运行，将文档中提出所必须的包引用完毕，运行时却发现报错。错误如下：ClassNotFound  javax.transaction.SystemException。将jta.jar拷入后问题便解决。于是产生了一个疑惑，jta包到底是不是必须的？这个问题有待深入。

最近在项目当中负责了登录模块的开发，采取的方式是最常见的那种，即提交表单到业务层对数据库中的字段进行比较。这使我有了进一步想了解JAAS的冲动，sun的tutorial还没来得及看，E文看的比较慢，还是先google出中文得到一个大概的印象吧。
Java Authentication and Authorization Service 在 JDK 1.4 正式加入 Java 标准的 Security 模块, 简单来说, JAAS 就是让我们把身份验证与权限管控使用标准的方法来开发。根据google到的信息得知。
JAAS主要的类如下：
普通对象

• Subject
• Principals
• Credentials

身份验证相关的对象

• LoginContext
• LoginModule
• CallbackHandler
• Callback

权限管控相关的对象

• Policy
• AuthPermission
• PrivateCredentialPermission

接下来便是利用空余时间通过JDK，tutorial进行研究了。希望不是半途而废，也谨以此文记下，以表决心。

前段时间瞎逛Jdon和Javaeye，2个都是名气非常大的Java社区。上面不乏许多国内IT界的名人，大牛。
仔细看了他们的帖子，发现这两个社区之间的争斗也是非常有意思的。争斗的源头是EJB与Hibernate。
两派人士论经据典，摆资论阔。最后都已经针对上个人了，双方都是些人物。谁是谁非暂且就不在这里评论了，但这让我突然想起了一句话，“做技术的一定要学会宽容。”这是位业内的前辈告诫我的，是的，一项新技术的出现，必然有他的道理，不要贸然去评判它，你所做的，是先弄清它，然后再吸取它的经验，好的地方可以借鉴，不好的地方，尽量去避免。刻薄的评论，只会显得自己的幼稚与浅薄。而这些错误，是我们经常犯的。
做人的道理尚且如此，做技术的呢？

对于一种不够完美的技术，批评它总是容易的；若是拿不出更有建设性的方案，那批评也只能叫廉价的批评。
“虽然是做程序员，但是不能只把自己 当成程序员。你还可以为你的老板和公司着想。但并不是找到问题就万事大吉，任何公司从来不缺挑刺儿的人。因为你看到的问题，可能不晓得有多少人早抱怨过 了！所以你与其就这么跑去找老板而于事无补，还不如调查研究后，带着解决方案去找老板，这才是上策。只有一个指出了核心问题又拿出了有效解决方案的员工， 才会得到老板的重视和信任。【唐骏语】

在和银行的合作中，我们遇到不少困难。但正因为有困难，整件事情才更有操作的价值和意义。如果这个东西三天就做好了，那么我肯定对这个事情没有兴趣。 【马云语】
题外音：
对于技术问题，太简单说明没有技术含量。
对于商业问题，太简单就容易模仿没有核心竞争力。

我做这个公司卖什么？不买产品，也不买公司，我卖的是我自己。你只要让别人觉得你值得信任，那么什么产品都卖得出去。【tr老板语】

权限控制是每个项目必不可少的一块。在最近的一个MVC模式(Struts)的实践当中，在进行权限访问控制时做了一个这样的尝试，即在action当中进行权限控制，它所控制的粒度可以到用户的每个操作上，比如说增删改查，当然，我这里所说的权限是控制到功能级的，系统还没有复杂到对实例级别的控制。
具体的例子如下：先定义一个BaseDispatchAction，此类继承Struts当中的DispatchAction，其中有个权限检查的方法  

funcId指的是当前的栏目，operationId为当前栏目的功能操作ID，将功能ID与操作ID在checkPermit方法当中与当前用户所在的角色资源进行判断，看是否符合当前操作。
比如具体到一个新增操作，可以在相对应的功能操作表中定义对应的操作ID。在接下来的具体某个action当中，先继承BaseDispatchAction，比如用户管理模块的UserManangeAction。然后在新增方法当中加入如下代码控制，   

这样，对具体的某个功能操作就进行了很好的控制。