2006年08月26日

2006年08月02日

SNA(Share Nothing Architecture),号称是php/ror承载高并发的终极方案,产品现在就知道有memcached(BSD开源协议),比起java的session复制优点多多。

对于java,如何不修改代码即可实现SNA?
包装一个新的HttpSession,delegate原始session,对它的setAttribute和getAttribute进行改写,调用memcached API。搞个Filter在最外层注入。

当session中某个复杂对象的状态发生了变化,又没有调setAttribute更新怎么办?
方法1: 要求开发者调用setAttribute通知更新。
方法2: 设计初期规定某个类,所有要在session中存储的内容必须以成员变量的方式定义。禁止直接使用session.set/get attribute,只能通过某些方法操作该类的实例。 在这个类里,通过AOP或其它的途径检测自身的更新,自动更新memcached。

据robbin称java的Serialize效率较低,关注一下。
能确信在设计前期不考虑集群的问题,后期可以方便迁移就可以了。

http://www.danga.com/memcached/
http://www.whalin.com/memcached/javadocs/
http://forum.javaeye.com/viewtopic.php?t=20298

2006年06月04日

不行就到fixdown瞅瞅,hiahia

http://www.unfish.net/index.php?serendipity%5Baction%5D=search&serendipity%5BsearchTerm%5D=confluence

http://www.blogjava.net/freddychu/archive/2005/11/05/18319.html

2006年05月27日

软件开发过程就是编程语言和开发工具结合使用的过程。


编程语言用来描述,其上有库、框架。


开发工具用来生产,包括软件生命周期中智能的或可视化的辅助工具。


java的现状是重语言而轻工具。


动态语言表现力强,必然会轻工具重语言(目前的单腿跳也不爽);而静态语言的开发工具仍有很大发展空间。


要实现楼主的需求,对于一门不能指望工具的静态语言,就只好寄希望于框架了。但过于动态 本不是静态语言和关系型数据库的强项。


把开发工作交由客户来做,实在是理想啊。


展望下未来:


我们只提供系统页面的template、theme和一组component(ui component、service
component),甚至于只给客户个page designer。
客户在线设计自己想要的页面框架,可在线编辑页面的文字区域,甚至可以达到每客户一perspective的效果。



对于domain的设计,给客户个model designer,让客户设置field,对应的list和form页面同时生效。允许客户在线调整字段的显隐、存取权限、对应component等。


另加一个model relationship designer,叫客户拽来拽去设定model间的关联,同时form页面自动可以编辑关联数据(AJAX),list页面也自动生效。可视化的形式设定search form,data grid等。


提供可视化工作流在线编辑器等工具。



至于涉及到的复杂业务逻辑,提供Action代码编辑器,在客户口述的情况下程序员现场编码在线调试。



注意,上面说的都是系统生产环境下的功能,不是开发环境的单独工具 – 想像成生产环境下的perspective(Eclipse那样的),点击生产环境页面上的Model Design卡去操作…


至少Zope/Plone有部份类似功能。



展望的结果是,开发过程相对模式化的情况下,程序员不得不去做一些重要的事情。



展望完了,如何实现?

2006年04月19日

[quote]错误提示信息:
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:156)
[color=red]Caused by: org.xml.sax.SAXParseException: The content of element type "class" must match "(meta*,(cache|jcs-cache)?,(id|composite-id),[/color]discriminator?,(version|timestamp)?,(property|many-to-one|one-to-one|component|dynamic-component|any|map|set|list|bag|idbag|array|primitive-array)*,(subclass*|joined-subclass*))".
at org.apache.xerces.util.ErrorHandlerWrapper.createSAXParseException(Unknown Source) [/quote]

<class>下必须有id或composite-id子元素,形式是:
<id ..>
而你是

[quote] <property name="id"
type="java.lang.String"
update="true"
insert="true">
<column name="Fid"/>
</property> [/quote]

hibernate对视图的支持我不了解,至少可以google下吧。

肯定进回收站或直接删除。

难道说入门级提问多起来,可以证明hibernate已经大面积普及了?

如果用IDEA或eclipse装上个插件(xman?),事情就会更明了。

哪个编程语言在语法级支持国际化?入门时学会看异常是道坎啊。
异常信息国际化了,可能入门的人上手更快吧。

看swt-designer支持国际化的方式挺不赖
[quote="gigix"]IDE的作用,说穿了无非是帮助你更快地写出一大堆跟你想做的事情不搭嘎的代码罢。[/quote]

经典!
java IDE最大的作用是弥补语言本身的缺陷,真是个遗憾,难道java程序员天生不喜欢IDE?.net framework和delphi显然不止这些,至少它们以不同perspective操作源码的技巧用得更好。
IDE能做什么、应该怎么做,我经常胡想这个问题,改天摆这个话题yy一下,顺便体验一下在非windows平台的人们用emacs、textmate等兵器有啥感受。

话又说回来,期待值上去了,现实不会改进,只会打击自己的士气。

说了这么多,版主还是删掉吧。哪天想明白了再开贴子聊,目的是充分利用IDE的优势,尽量少打击自己的士气。
komodo3.5.2也支持ruby的code intelligence了,尽管不好用,总比没有好。

2006年04月17日
gigix 写道:
我觉得差不多,反正不管改配置文件还是改代码,改完以后都要build all然后run all tests,对我来说没区别。





记得去年一个讨论AOP的贴子里,gigix的观点是Annotation只是把元数据从配置文件挪到了源代码,没有实现其他的东西,我本人很赞同。


对于元数据,可以存放到 java代码、脚本、配置文件中,其区别大致是书写方便性、IDE友好性(编译时检查、code assist、设置向导)、布署便捷性。



对Annotation的质疑很大程度上是 在变更时布署上带来的麻烦,那么细究下来,产品什么时候布署新版本? 公司产品的版本计划和新版本布署方案是什么样的? 大概不会太频繁吧,都会build all吧。


那么对于开发过程呢?我想只要支持热布署,和以前的开发过程一样,不须我重启应用服务器就OK了。


没用过jdk5.0,希望各位指正。最好讲讲您是怎么用Annotation的,与传统方式在编码和开发布署流程下有什么需要注意的的吗?


======================


xml配置确实有它作为文本的好处。


引用:
这些例子都是我在实际项目中实实在在碰到过的情况,很多时候你在本地开发环境好好的系统,在生产环境就会遇到很多小毛病,这些小毛病往往只是需要你调整一下配置就可以解决的,但是如果放在annotation里面的话,你就必须经过一个很漫长的修改过程。




上面两个例子是在生产环境吧?


生产环境与开发环境不一致现象,毕竟不像开发中应对的事情多吧,当然,遇到后,解决的难度和压力也是很重要的。大概annotation对咨询过程不够友好吧 Smile



正常情况下集成测试不会太频,时间间隔也不会很短吧,对于俺们开发人员,充份利用IDE调试就可以啊。



说点题外话,关于开发环境的集成度,感觉差异也是挺大的,常规的IDE(内置web程序调试支持)+版本控制+问题跟踪,好的可以无缝集成DB管理、文档
写作、单元测试……,差的拿ultraedit编辑、ant编译、System.out写调试语句、复制.class/.jsp文件到应用环境调
试。感觉对开发环境的最佳搭建方案讨论不多,有没有必要另开个贴?



元数据写在源代码还是配置文件引起 概念的视角 确实不一样,个人觉得各有优点,需要看情况权衡。



AspectJ了解不多,感觉是不是以前太静了,只是给它加点动的成份(运行时),没有"改成动态"这么严重吧,不然太可惜了。

==============


gigix 写道:
robbin 写道:

个帖子中的annotation声明事务和XML声明事务。一个大型的应用,至少有上千个方法需要声明事务,那么annotation你就需要在代码里面
写@transaction(strategy="required") 至少上千次。而如果用XML,只需要在XML统配一次。这就是XML的优势。




那么这个配置根本就不应该出现。我是说,它就应该是一个缺省配置,只有遇到特殊情况的时候才重载它。这就是为什么Rails开发效率高过J2EE的原因。





在试RadRails,呵呵~


又是题外话,提到脚本,我了解的python和Ruby都支持元数据标记,可以参考她们的应用范围,不过,脚本语言用元数据,天然就能避免java的一些问题,如布署~。


python表达方式与java类似,是一种decorator wrapper的模式。


ruby是通过module mixin的方式(rails大量使用)表达,不过与上下文无关。


相关资料:


http://www.python.org/doc/2.4.2/whatsnew/node6.html


http://www.python.org/peps/pep-0318.html


ruby网站怎么访问不了了 Sad

=================


zkj_beyond 写道:
引用:
在source中写annotation 进行系统配置,相对于XML中配置来说,效率要高得多




其实是一样的。都需要ide,或工具的支持。如果没有好的工具,XML与annotation都让人疼痛。





我姑且认为annotation是OO角度,xml是AO角度,这两个视角我都不喜欢。


我还是想充分利用IDE,假如有这么一种模式:


制定annotation与xml配置 双向映射 的表示标准(mapping schema?)。


在IDE编辑器中 输入annotation,显示效果跟现在一样,IDE在后台不是把这些annotation存于源码中,而是按指定的"映射规则"(mapping rule?)存到相应的配置文件中。同理,当IDE打开源文件,也会按规则查到对应的配置文件,正常显示annotation。


在定义annotation时,可以利用IDE的向导生成"映射规则"文件。


在生产环境,可以用vi直接打开配置文件修改。


annotation的service端代码,是分析xml配置文件而非利用反射机制生效。


这种情况,与使用xdoclet比较,不同的是元数据存放位置的天然脱离源代码、语法级上支持、映射标准的制定、IDE的标准制定。


这样,原先不支持annotation的库,制定它的mapping rule就可以了。


即使大家一致认为这样确实好,我想m$完成这个目标也一定比java快。


这个设想存在两个可能的问题:


1. IDE显示效果与配置文件格式差异太大,以致于如果两种方式都要查看的话,都要学习,还要熟悉其对应关系。


2. 复杂情况可能只想通过反射,不想(或不能?)通过加一层xml来做


即使这两个问题都很严重,起码这个设想作为一个可选的方案,或某个IDE以一种非标准的方式支持也好啊,呵呵~



另:AspectJ5支持含有注释的pointcut通配,找时间学习下


http://www-128.ibm.com/developerworks/cn/java/j-aoplib/

前几天开始做某个项目,看到流畅的原型为了编码的需要被改的面目全非,俺真个心疼啊。


于是反思保护web原型的问题,看到buaawhl老大 的讲解,不胜喜悦,俺想要的老大差不多都做好了,还外送了不少好东东。


下面是俺的观感和原先的一些想法,夹杂着独门术语,卖弄一二。


(不知何时得闲开始学习一下fastm呢)




引用:
编程即配置




关于作者对于脚本与配置的论述十分认同,附一点对xml的漏述:xml可以反向解析,脚本就十分难了。比如我想做个可视化的配置界面,如果配置信息是脚本实现的,大概只能单向生成配置脚本了(用velocity一类很容易)。




3.页面资源



映射Css、JavaScript文件类型,对于它们的链接,参考zope,即:相对路径下找不到,就到上一级目录,直至context根。实现页面外部资源查找的面向对象方式。


应用场景:


在context根目录放置全局`默认`css,对要定制的子web模块,在相应目录建立同名文件即可实现css定制。


引用:
Zope Object Publishing




这个是不是我前面的说的?Zope Object Publishing没看过



引用:
后面的关于Web各层开发的论述,主要就按照这个“应对复杂、让复杂更简单”的思路展开。




引用:
设计思路也是同时应对简单和复杂




引用:
级列设计思想




目标:简单的方案应对简单的需求,完善的方案应对复杂的需求。即遇简则简,遇繁则繁。


方式:方案的`默认`实现应对简单,开放的架构应对复杂。


重在`三态`中`默认`态的实现。



4.页面模板层



引用:
这一层也是著名的脏乱差楼层。




严重同意!



包括三个内容:


1. 模板(页面模板、UI组件装饰器):sitemesh起作用的地方。


2. UI组件(通用组件、数据敏感组件):有人称之为macro的东东,服务器端与客户端统一模板,可以注册服务器端事件。


引用:
如果完全避免Server Side Template Engine,那么所有的包含动态部分的页面装载(URL变化、刷新等),都需要和服务器进行两次通信。




UI组件的服务器端事件激活时,引起一次客户端请求(当然也可以是ajax型请求)。对于UI组件的服务器端初始化事件,考虑无通信消耗的优化。


引用:
Nihongye说


衡量值得组件化的ui结构 then make it.




3. 控制逻辑(分页、循环项、分支)



欣赏的实现方式:


页面`元数据`:页面标签的自定义属性(类tapestry、zope page template),标记数据源名、UI类别,可以包含简单的逻辑代码(Ognl的应用)。



(X)HTML DOM在服务器端解析及改动带来的便利:


引用:
Dlee写道:


同样,我从来也不喜欢在服务器端处理 HTML DOM 的解决方案,例如 XMLC、Echo 等等。




not so bad。除却服务器端DOM的执行效率问题,其可带来的价值是可观的(这方面的常见应用还是太少了)。


一般思路是用个FilterServlet解析返回的原始(X)HTML,对可见的DOM注入页面模板、UI组件(及其模板、数据),执行针对DOM的控制逻辑。


可能的应用场景:


1. 避免二次提交:向form标签内自动注入hidden域存放令牌


2. url修饰:有些状态往往需要在用户操作流的连续页面内传递(`page flow`),如公文的ID号,放在session中既占资源,又不符合需要(假想用户登录一次,打开两个浏览器窗口处理不同的公文)


3. model属性值自动注入页面



引用:
我现在主要在这个方面下功夫。比如,提供了类似于OGNL的支持,为了大数据量情况下节省空间,提供了Iterator,ResultSet的支持,等。


你说的那些功能,都可以在fastm的外围API做。fastm也提供了类似于SAX
Callback的机制,是一个IValueInterceptor, 匹配引擎每处理一个fastm template DOM
Node的时候,都会调用这个IValueInterceptor。

特殊的需求,可以在这个IValueInterceptor里面实现。


比如,可以专门定义一个 FuncInterceptor处理{call.a.func(c, d)} 这样的东西。可以专门定义一个 FormatInterceptor处理{a.date@yyyy-mm-dd} 这样的格式处理。


其实,fastm的这种格式处理可以非常强大,可以根据 对象属性的名字、类型、值等,进行各种处理。


比如,beginDay, endDay, 就显示 yyyy-mm-dd; beginDay, endDay, 就显示 yyyy-mm;
beginYear, endYear就显示 yyyy; beginTime, endTime 就显示 yyyy-mm-dd hh:mi:ss.
等。



这个我称为显示逻辑AOP。


fastm支持对象图。类似于OGNL。POJO可以直接在template中引用。





我们是不是可以称之为页面生成上的AOP和IoC 


如果逻辑比较复杂,可以用服务器端脚本作为datamodel和DOM的粘合剂,保持对复杂的适应。例如:覆写默认行为,复杂表现逻辑。


同样,`默认`是如果存在脚本,则用脚本粘合,否则是默认粘合。


默认行为的制定参考css查找规则。



以上方案试图力保原始(x)html的纯洁性,保证`原型友好`,理想状态是这样的:


在没有应用服务器的情况下,原型是最新的可以展示的版本,对用户和美工都是友好的。


放在应用服务器下,它就是一个跑得很好的完整应用。



达到这个理想虽然很难,但我们可以逼近。


原型页面和普通的应用一点大的不同是link和form
action的指向,往往改成了*.jsp,*.do等对原型不友好的形象。是不是可以保留原型中的原始htm链接,用个Servlet映射*.htm,
接管客户端请求,并以默认规则确认action名称,构建实例,并自动根据request参数初始化属性(差不多就是XWork)。



这里,`默认`要forward到的view就是用户请求的html。



表单验证也可以用`页面元数据`表达,最终可被server-side DOM(服务器端脚本验证器)转译处理和client-side DOM parser(javascript验证库)处理。如果server-side验证不通过,`默认`forward到原页面。



引用:
fastm的完全“推”模式的优势就体现在 HTML和Code可以完全剥离。





暗合,呵呵~


后面还有:



引用:
fastm的DOM分为两个部分,Template DOM is Read Only, shared among all theread.





引用:
关于Ajax(XMLHttp),我的意见是必要时才用,而且最好采用粗粒度的用法 — JavaScript发出一个URL请求,返回一整段HTML,直接替换到页面的某一块,而不是用JavaScript来做这样的把数据填充到HTML DOM中。




十分同意!


称之为`提交form到某html UI`,很爽的样子。



7.O/R



引用:
A a = new A();


IMapper aMapper = MapperService.getMapper(A.class);


While(rs.next()){


aMapper.populate(a, rs);


businessLogic(a);


}




超级不赖的lightweight o/r切入,学习ing!


用反射就行了,性能不会太大吧~(或者两种实现,开发时和布署时两套方案?反正开发时不爽就是不叫俺爽~)



Pager



引用:
Canonical说


到底是预先把所有变量都计算出来,还是将计算时刻延迟到执行的时刻(采用lazy evaluation其实是function programming最擅长的)。


我想fastm强调页面中没有复杂逻辑是正确的方向,但是也不必绝对排斥在页面中调用函数。


支持对象图或者对象函数调用的一个额外好处是可以需要命名的变量数,即减少需要创造的概念数,在对象数比较多的复杂情况下还是有用的。





引用:
这些URL是分段的。每一段代表 一级子模块。后面的段属于前面的段。

Lightweb是这么定义的。除了最后一级,前面的各级子模块,都对应一个 Channnel
(其实就是Dispatcher);最后一级子模块,可以对应 Channel (Dispatcher), Controller
(类似于SpringMVC的Controller), Action(类似于WebWork的Action)等三种编程模型。





是不是说:Channel是模块级(module),Controller是实体级(action instance),Action是方法级(action method)?



对于WW2的Action,每种请求对应一个Action(的execute方法)。


是不是有面向Entity(pojo)的,像ruby on rails,把Entity类的某些方法暴露出来,作为http请求的目标。(暴露的粒度,模板的适用对象)


是不是也有Entity类的`默认`模板(比如实例属性、对应方法的参数自动转成html form表单或link参数,一个Entity类提供CRUD四个模板页面),可以针对某Entity类定制模板,并提供override模板某部份的能力?



=========
buaawhl老大的回复:

多谢liusong1111的深入分析探讨。


前面的 Ajax, Form Post等意见都很好,是有益的补充。我现在的框架中,主要针对 Stateless Link。



关于Lightor 的那段特殊用法里面,为什么不用Reflection.


因为那段特殊用法是用来处理 Long Transaction的。也许有几十万条记录批量处理。那节省的时间就很多了。



liusong1111 写道:

引用:
这些URL是分段的。每一段代表 一级子模块。后面的段属于前面的段。


Lightweb是这么定义的。除了最后一级,前面的各级子模块,都对应一个 Channnel
(其实就是Dispatcher);最后一级子模块,可以对应 Channel (Dispatcher), Controller
(类似于SpringMVC的Controller), Action(类似于WebWork的Action)等三种编程模型。





是不是说:Channel是模块级(module),Controller是实体级(action instance),Action是方法级(action method)?






对. 可以这么说。Smile


也可以说,Channel 是 Dispatcher, Controller, Action 是 Service。



liusong1111 写道:


对于WW2的Action,每种请求对应一个Action(的execute方法)。


是不是有面向Entity(pojo)的,像ruby on rails,把Entity类的某些方法暴露出来,作为http请求的目标。(暴露的粒度,模板的适用对象)


是不是也有Entity类的`默认`模板(比如实例属性、对应方法的参数自动转成html form表单或link参数,一个Entity类提供CRUD四个模板页面),可以针对某Entity类定制模板,并提供override模板某部份的能力?





Lightweb 主要暴露Service,不暴露Entity. Smile


暴露的最低级别就是WebWork的Action 级别了。


CRUD还是需要自己包装。

借宝地俺对server side也YY一下:


server side css,


server side script,


server side include,


server side component(server side tag,server side annotation,server side event,server side property)


server side template,


server side html dom parser,


server side data binding,


server side logic/data injection,


server side state transfer,


server side continuation……

age0 写道:
用hashmap
的好处是不言而喻的,这才象是真正建立了一个正统的运输系统,正如我们的海陆空运输系统一样,运送的是货柜,内容则可以是任意的货物。有人会质疑货柜不是
透明的,因此难以跟踪、维护货物,这就有点庸人自扰了。收货方和发货方当然必须自行保证双方是按协议好的契约收发货物,运输系统是不会承担运输以外的任何
义务。举个例子,有人认为直接传送对象就万无一失了,这是不正确的,对象显式声明了货物的构成,但这只能保证不会放错货物,而不能保证发货方没有遗漏货
物,收货方依然要按照协议检查货物内容。直接传送对象的好处是相当有限的,坏处则显而易见:运输系统被绑架了,变成只能为现有的对象服务,一旦情况发生了
变化,你还得去改造运输系统。这正是OOer们经常犯的经典错误,所谓的类型安全及结构透明其实是以牺牲系统的适应性为代价的。





我对这句话的理解:运输过程中,一种是设置N个关卡层层检查,每层关卡只检查一种特性(如卫生否、易燃易暴否、超重否..);另一种是没有关卡直接发送,
在目的地开箱统一检查。前者优势是每个关卡都有专业的自动化检测设备,高品质的保证了货品构成的有效性。后者优势是快,最后一股脑验收的效果怎样,由于很
多专业设备用不上要靠手工做,人就成了决定因素。



后者如果合理分工不一定比前者差。因为机器也要人调节才能适应货物,尤其当货物参数变动或新出一种货物时,对各个关卡冲击很大。后者由于地点和工作模式统一,人较之机器应变能力又强,所以更占优势。



但是,对一个固有 "关卡验收" 体制的运输系统,实行黑箱式运输,难说会怎样~



也许对楼主来说理想的运输系统就是铁轨

http://alex.dojotoolkit.org/shrinksafe/

起因是这样的:
产品中prototype.js从1.4升到了1.5.0rc0(buffalo目前版本不兼容,所以去掉了),升级后发现prototype.js这个文件访问时出错,貌似套用了sitemesh的模板,于是查了decorators.xml配置,跟别的js一样啊,后来发现sitemesh会抛一个异常:IllegalStateException:getOutputStream已经调用了云云,很怪异。于是查看sitemesh的JIRA,发现宣称2.2版本已经fix掉这个bug了,而我正是用的2.2。碰碰运气吧,升到了2.2.1(基本是bug fix版本)。发现这个异常没了,但还会有NoSuchMethodError:org.apache.naming.resources.ResourceAttributes.getCanonicalPath()Ljava/lang/String;的异常,于是又查,似乎是tomcat的bug,没有详细的资料,只好试,因为只有这一个文件跟别人不一样,最初它的格式回车跟别人的不一样,改了也不好使。后来试着把它的代码减半,发现竟然没异常了! 最终结论是对于体积超大的js,tomcat5.5.9这个版本(在使用sitemesh时)会抛异常。

所以才想到javascript compressor!

google了下,发现形形色色不少,要找安全的!于是就用了上面链接的那个。

做java程序员真是苦啊~