牛虻说：也许不少人没有看懂这则新闻，有可能这是影响未来五年IT行业最重要的新闻之一。一直到昨天，仍然有人就XML、HTML的长长短短跟牛虻争个不休，牛虻这裡再次强调：XML/HTML不是同一层次的东西，实际上，HTML就是由W3C提供了视觉解释标準的一种XML；XML要发挥作用，比自定义标签更重要的是解释这些标签的程序和方法，这就构成了对XML的专利。如同每个人都可以用汉语取名，汉语不是任何人的专

系统权限根据会员按组别划分，权限按组别分配的方式进行管理。管理原则按白名单方式进行，即除非是指定享有某种操作的权限，否则都是禁止的。会员获得权限的方式是被分配到某个有权限设定的组。有两个特殊的约定组：ANY和ALL，前者指任何用户，即使是没有登录；后者指已经登录的用户，不管他是不是分配组别。简单地说，各种公开内容的display权限是赋予ANY。所有的定义都在WEB-INF/*.xml中进

后记：按这个范式建立的数据结构，在实际使用上一次性地使用少量编码回避了关系数据库的多表连接查询，收到了很好的效果。看来，这种范式是可以推而广之的；不过，它要求程序员对于数据对象、xml处理有很好的基本功，牵涉的知识比较广，真正能够这样做的人并不多。由于对象属性脱离了关系数据库，所以排序次序功能要单独实现。总的经验是小量的子对象序列（相当于小子表），适合做成这种形式，而单个的对象属性，不适合做到xm

        我原来的项目程序方式看来就和XP差不多，当然pair programming做不到；但测试是完全做到了。至于说需求变动，我认为是最不可能的地方。事实上，最经常碰到的故事是user story说了千百遍，大家都没有异义，甚至快速原型也做出来了，然后按这个开始开发，各模块也测试得差不多了，甚至完成最后内部可用性测试，但用户一看到出来的样子，马上出一大堆新的需求，这也罢了，故

地址JSTL标签是SUN带头与apache社区合作的产品，可惜从一出现就已经是一个过时的技术。SUN的软件架构师似乎缺乏从顾客角度考虑技术取向的能力，与微软相比差之千里。就标签技术而言，它的目的是令菜鸟中的菜鸟变得可以写JSP，还是令一般程序员写JSP显得更方便，更好管理？显然，SUN的那位笨蛋架构师没有想明白这个道理（越是看得多它的文档介始，越是觉得那个家伙是个大笨蛋)，把SUN数千名天才工程师

对内容的访问控制可以抽象为全局权限；contenttype权限和行记录权限对内容的访问控制可以抽象为全局权限；contenttype权限和行记录权限<p>昨晚睡得很好，今天加快进度，把事情做完它，装进LINUX，更新到网上去。上午效率不算太高，到博客上的时间偏多了一点。12：04分，完成了从XML到解释的步骤，过去，在应用程序中调用时工作量最大，不过现在由于程序都是现成的，只是扩展方法

一直沒有仔細考慮在自已的hanva框架中多表查詢的情況。今天算是真實碰到了，並不算太緊，這時侯正好可以較詳細地思考這個比較理論化的問題。事實上，當表達層變得需要通過應用層去訪問數據庫時，如同J2EE試圖做到的一樣，單個的實體bean不會有太大的問題；而如果是條件性列表，就已經比較麻煩了，如果是多表的話，原則上無法繼續。原因就在於這種三層結構需要使用相應的預編寫的java類去

近兩天為了搜索引擎橫沖直撞的故事，開始修正多jsp的框架。所謂多，是相對于過去重複性極高的servlet的方案而言的，實際上我的jsp重用程度高到不能再高。如果說多，比起我見過的一般的jsp網站，jsp的數量一般只是他人的十分一以下。代碼量更是少得可憐，原因在于幾乎所有邏輯都已經封裝了。即使是這樣仍是有著再次壓縮的空間，而且，盡管重新達到整網一頁沒有必要，（那是使用servlet達到的，運

原载:       在设想使用XML和关系数据库形成一个对象数据库>一文中，已经阐述了关系数据库和对象数据库的主要区别：对外键的使用是通过直接记录，还是遍历外键子表来获得。而这里，是面对另一个重要的区别：如何释放对象的资源。对于对象数据库而言，它等同于是一批直接存于数据库中的串行化对象，它的实际存储形式到底是不是按关系结构存储并不是最重要的，重要的是调用程序读入内存的就是一个对象，而不是游标映射；

在Hanva的框架中，多表連接的查詢，一般由以下的方式完成：1、對於條件限制上的連接，可以直接採用entity讀取，條件上的多表，僅限於條件上的擴充，與一般的單表查詢沒有什麼不同；可以設定list,也可以在entities標簽中直接設定連接條件；2、對於選定域也是多表的，如果沒有相應的類可選，原則上是依靠database.service把基表的連預先設出來，從而把多表的連接轉化為單表上的連

      载自：      即使对于一个大部分基本逻辑都包装在标签/类/servlet/EJB中的网站，以至于在jsp中看不到任何的javalet代码，随着规模的扩大和项目时间的延长，目录中总是堆满了越来越多的垃圾文件。有些文件本身不是垃圾，而是被包容的子文件，但是jsp服务器可不管这个，如果不是jsp后缀，它就会被jsp把源代码下载到客户端；或者，同样是jsp一样时就让维护者头大。如果

WEB界面静态化进入最后的环节，可以令管理员分门分类分子网地选择项目进行静态化，主要是首页，效率很高，按由XML设定的静态化项目，一个网站管理员可以在几分钟内完成上千个首页的静态化发布。但是当进入到再翻页部分时，却令我沉思了整整半天，觉得前面几天的路,也许走错了。要知道错在什么地方，最好先看看为什么要进行WEB界面静态化。我绝不在乎已经浮了两年多的所谓不能把WEB界面变成静态页面就是技

    jsp可以令菜鸟直接写简单的网页程序（网友言），而servlet却有jsp所不及的集成程度和易维护性。两者在JAVA/BS系统中无法简单取代，但同时并存却令开发者陷入近两年来最常见的陷阱中：必须在一个即使是相对简单的项目中维持多套程序模式的方案，显然，这是高成本的。本文考虑并初步实验了使用标签组件连续完成类似servlet的处理效果，从而达到鱼和熊掌兼得的目的，看来有一定的效果。    在

牛虻对於RSS是久已闻名，但一直不知道它有什么必要的作用，看过它的xml代码，简单得很，要处理也是很容易的，互联网上干嘛要留个这样的东西也搞不清楚。就把它当成是用xml发布的内容好了。但必要性呢？仍然不清楚的。但居然满世界地看到吹鼓手就给它吹嘘，今天更看到一份声称说专家都看好它，是代替邮件什么的云云。於是下定决心抽出了半小时搜索了一下google然后申请了两个在线的RSS阅读服务，并下载了一个RS

      电子商务网站中的收费缴费框架主要使用客户预存款的形式，客户通过缴费途径把钱存入电子商务网站络有限公司客户名下，并由计费框架主进行用款帐目和明细的管理；向客户提供帐单结算。客户可以通过个人控制中心审查自已的预存余额，历史帐单；现行定单；冻结金额；并可以要求发票和帐单投递（投递费可以假定作为一项服务扣费），当然也可以客户自行到网站公司营业部打印帐单。     一、缴费框架； 使用充值卡缴费

这是使用DBCopier的附加文档。针对需要使用 Clazz read情况。DBCopier最早的出现是现实中的需要：常常需要把旧的或分散的系统（数据库）中的记录按要求倒到新的数据库并建立相应的联系。这时侯，很自然就会产生一个设想：这些程序是否可以以某种方式实现重用呢？DBCopier 本来是针对数据库一行对一行的过录。对于多子表和集合属性的表类型，使用Clazz方式与源数据的一行记录绑定，这里需

 jsp实际上是servlet草稿，在第一次运行时由服务器编译成servlet，以后每次重启就把已经编译好的serlvet载入内存，成为一种系统服务。因此，在重新发布后第一次访问的速度会比较慢，是可以理解的。“比较”的意思就是明显可以感觉到推延，但充其量在第二第三次访问后就会变快，这是 jsp的常识。但近日的几次发布失败，似乎是在挑战这条常识，而结论是直指jsp2.0系统级结构的不合理。这是第二第

 一、网站广告的计费模式      一个网站的广告服务器（Ads Server）模块部分从业务模式上看，广告服务器需要最少支持两个计费模式：按时及按点击次数计费。    对于按发布时间计费，发布事件是很容易获得的，难的是终止发布时间，假如没有一个计时器的话。对于大量应用运行的服务器，鉴于资源消耗量的考虑，使用多线程的计时器要慎重，毫无疑问，分散到模块级自行决定计时器是低效而且危险的。如果是单一模块

在使用JSP标签时，有大量的操作代码是重复的，这些代码分别集中到BaseSimpleTagSupport,BaseTagSupport, BaseBodyTagSupport三个标签支持父类中，分别继承三个基础类，SimpleTagSupport,BaseTagSupport, BaseBodyTagSupport。作为大部分情况下，使用SimpleTagSupport生成的处理程序，结合logi

DBCopier同樣是在多數據庫環境中，爲了適應數據整理和拷貝而開發的可重用構件。不過，實際上，更多的情況是用在不同的開發過程中由于表結構的修改，而需要對曆史數據進行整理歸一的過程。DBCopier的工作核心是mission.xml，每一個mission是一個拷貝任務；不同的數據庫連接在connectionset元素中定義，實際上，這與ConnextionManger和DAO中的定義和解釋

 BEA使用的是Catalina,也就是tomcat，无意中发现一个非常隐蔽的也许不算致命的BUG，在JSP中某处的标签如果执行错误，会在前面某处输出缓冲区时无异常退出，而不是在真实错误地点发出错误异常。10：45 分：却发现FormTag执行异常退出，而且错误日志没有任何输出；所以决定转过去先看看是什么回事。非常奇怪的是，就算在doEndTag中输入断点后，错误日志仍没有输出。最后的检查结果，不

 這幾天在處理動態網站和博客的應用時，發現效率很低，其中的一個原因就是由于不得不在jsp的代碼層來來去去地進行很接近卻略有不同的編碼。在一般的習慣，我會傾向于使用其同包含的代碼片結合變量實現重用，只要重複達到三次以上就值得這樣做。這次，有幾個原因令我手工重複處理而不是使用可用用的代碼片。第一個原因是這裡重用的一般都是兩三次之間，而沒有出現三次；其次是近來的經驗發現大部分准備重用的代碼片也極少調用超

 原文最终还是手工输出XML对象可靠 2005年 01月06日 和xml打交道，常常是哭笑不得：我为什么要花那么大力气和整个XML文档打交通呢？实实在在的，我只不过想存取其中一个对象的属性罢了！！前段时间了解了castor觉得这是一个解决方案，不过也还是需要整个文档的读写更新。一来是时间限制不允许当前深入研究，而且那也是一个不算成熟的项目；二来呢，采纳的话会和现在的digester读取模式发生冲突

 原文许多人认为JSP是JAVA向微软ASP挑战的成功产品，到今天，围绕着JSP方案发展出了TAG/EL等技术，JSP作为JAVA的BS前台界面方案看来已经是无法逆转。但在我看来，JAVA选择JSP这种表达形式，恰恰是它最失败的地方，是对ASP的一种拙劣的模仿，它本来可以做得更好的，甚至可能据此让微软彻底退出服务器领域，但最终，却可能成为足以令JAVA最终失败的重大战略方向性错误。JAVA到今天仍

原文： 在Java 对数据库记录对象化映射实现的考虑中，多对多结构一向是一个令人头痛的问题。对于一个单一的表结构来说，包括它的基表和子表，都不难用一个类进行表达，也不难通过反射的办法把一个类通过一个容器实现与数据表行记录的持久性映射。不过，对于一个多对多表就不一样了，CMP如果不是做不到，就是太复杂而且不易变更；BMP也不容易，实际上这意味着在一个类中表达两个实体的关系，而这两个实体又各自可以是一

原文dao.Processor是在多数据库多实体环境下以JAVA对象的数据对象化和持久化的核心类，它的使用方法总结如下：一、与Entity绑定；针对dao.entity对象,可与EJB.entity设置兼容。与entity兼容的典型使用方法是：Processor pro =ProcessorFactory.getProcessorInstance(ent);或：Processor pro  =Pr

原文： 在Unix/Linux上令(java)JVM支持中文输出一、在Unix/Linux上令JVM支持中文输出如果用户使用的是UNIX的远程服务器，就会遇到中文字体在图像中输出的问题，特别是由于许多管理员并不喜欢把主机的locale定为zh(因为意味着可能出乱码或必须装微形图形终端象zhcon，但很多情况下这样的条件并不具备)。大部分程序员的JAVA经验苟限于JSP脚本程序，部分熟练的程序员大概

软件测试的概念最早是大学时从老师那里记来的两句话（其他都丢光了）：开发是尽可能地让程序通过；而测试，则是尽可能地让程序通不过。两者的区别，在于选取测试实例在设计上的指导思想的不同。这句话虽然简单，但易记，自已也觉得真是收益菲浅。当时还没有什么javawindows之类的故事，所谓软件，其实是C语言和汇编，不过这个思想我却是觉得可以用到软件开发和测试的几乎方方面面。一般说来，可用性测试和黑盒测试这类

原文：使用DBCP连接池后访问速度提高了100-150%,但是实验表明，如果负载压力达到实际负荷的10倍以上，即超出内设的最大连接数10倍左右，DBCP原因不明地崩溃，并常常不能最终恢复服务。原因之一是由于在高负载下，DBCP把已经关闭或过时的连接返回给呼叫者，造成流溢出，从而令所有IO进程悬挂。唯一的办法就是重启tomcat。 解决办法是在得到连接后先检验连接是否关闭，并最后有防止DDOS拒绝响

原文： 今天企业应用环境中一般情况下要面对不止一个或一类数据库；另一方面不同时期的不同种类的数据库形成一个个的荒岛；在java中，技术潮流倾向于不是直接操作数据库记录，而是通过中间层的数据库对象持久化处理达到OO的目的。无论那一种，都要求比较容易地面对多个数据库连接。多个数据库连接比较为人所熟悉的是微软的ODBC数据源设置，除了没有实现中间层持久化外，ODBC其实比JDBC要全面也更容易处理。Co

原文：测试一般是放在系统完成后进行测试，但今天，却常常听到资深开发人员劝导新人们：“测试是开发的第一步”这句话如何理解呢？如果从日本人发明的巴克质量管理的方式去理解，大概是指每一个环节交给下一级时都应该进行测试。有些测试对后面的操作没有太大的影响，如图片不漂亮，菜单不合理，布局很难看之类；而另一些，却直接让下一级无法开始工作，象用例不清晰；用例自相矛盾；组件内部错误；框架不合理等等。固然，一级级把

 《选择jsp而不是servlet作为BS前台主流方案是JAVA的战略性方向错误 》一文是经验角度对jsp选择方向的一种质疑；其不受“公论”（公论对中国人的思维影响很大）的逆向思维方式本身就会引起争论，本是意料中的。现把部分争论回答归纳起来，学习、实践、争论、归纳、再实践，这是取得提高和突破的途径。首先，JSP是一种WEB界面处理方式（不是语言），所以是否适用MCV模式实际在存在着很大的争议。所以

 目前我多数是选在周一早上更新系统，然后就到总部开周会。不过似乎近来形成了一个传统，明明运行得好好的东西，一旦我升级完毕开始打算舒心开会时，它就会出问题罢工，直到给急call，尽管系统总是已经经过一定强度的测试了——当然，不是每次都进行过重力测试。升级也实在太频繁了，不可能每次测试完全。上一次是升级了两个小时后开始变慢，经过压力测试和debug后，去除了不算太肯定的一些代码，反正似乎是经受住了严格

软件项目中由技术实现方提出的需求变动  软件项目中由技术实现方提出的需求变动  软件项目总会出现需求变迁，同时这种变动在需求者看来是天经地义的并轻而易举的，这是令开发者最头痛的地方；需求需要变动，也就是软件的软字的由来。有一位前辈的话最具代表性："软件项目就象是建筑工程，在大型建筑工程中，象建一座桥，在差不多完工后要求桥转90度的情况需求既不会在实际中发生，也不会被人看作是合理的；而原来的需求是公

 JSP默认发生错误时把错误页面显示出来，不过这通常会让人觉得程序不稳定，但在软件开始投入使用的最初一段时间中却是难免的。同时，这种反应运行时异常的情况许多时侯并不是真的程序错误，而是不正确的操作，象密码不对或条件不对等等；不妨称为条件性通知。在程序中抛出异常，只是为了节省机时。我一直在尝 试组织一套可以通用一点的错误导向方式，希望能满足以下要求：一是能够保存真正的错误信息，以便调试使用；二来是如

 MVC模式提供了标准的表达层和业务层逻辑分离的模块建立的原则，不过在JSP中实现MVC要面临无状态的环境，而状态维护是MVC模式实现的前题。因此，维护MVC中的状态成为实现MVC/JSP时的最大难题和成本构成因素之一，它的缺点在struts项目中显露无遗。状态维护的困难最终表现为多步控制参数维护上的困难，OPflow提供了一个试图面对流程对象进行维护的方式，但随着JSP标签的出现，令JSP MV

 不难认识到，在web应用中图片/多媒体和长文体的处理策略，很大程度上决定中一个系统的性能和负载能力。    这几天在处理图片上载的同时，也在考虑着最合理的对图片和长文本的存储。多年前，我喜欢把图片和长文本都存进oracle中，目的是备份方便，只需要 exp就可以连图片一起备分起来，不用一个个地照顾目录。但是缺点也随着访问量上升而一点点显示出来：一来是大大加重了数据库服务器的负担；二来使用 BLO

统计来自于，每次访问这个标签就会记录一次浏览情况，包括访问路径和referer、参数。反复的检测表明，计数器没有错；而且每一个页面前后输出的断点计算也完全符合递增性，唯一的解释就是每次点击都重复访问了。那么错误到底是在什么地方呢？一点点地缩小范围，直到最后一段是什么呢？“”，美工人员大概是大算用一个小图片，不知如何的变成一个空图片。在a的href中如果=""就是对本页作原条件刷新。那么这里表现出来

 Apache是用了很长时间，但也只是用了很长时间，要说精通还谈不上。所以这四五天存在着补课的味道在里面：既然公司不能提供好的系统管理员，也只能是自已兼任了。经过对Apache和tomcat结合后的进行SEO优化的处理，四五天后，对这几件工具的基本逻辑框架有了统一的认识。对URL重写的了解需要是针对这样的需求：偏向于HTML的SEO搜索引擎优化，以及提供不定量的二级域名便于模块管理和推广。搜索引擎

 这几天的工作主要围绕着文件（主要是图片）上载，并可以在线和HTML编辑器集成，操作简便与目前引用网上图片相似。我是有点小看了这件事情，不过也不无道理：一来以前使用servlet完成过，其中的核心DoUpLoadBean也的确是可以工作；其次集成到编辑器则在使用php的本人的私人博客上做过，看不出有什么特别难的地方。但实际上在展开后就发现，简单实现上载是容易的，但要合理地安排上载的策略，就不得不小