Month: January 2009

基于AXIS实现的ServletEndpointSupport在每次请求时都会产生一个新实例

ServletEndpointSupport AXIS 在每次请求时都会产生一个新实例,每次都会调用onInit()方法 这是底层的代码:   JavaProvider.class     protected Object makeNewServiceObject(MessageContext msgContext,                                              String clsName)         throws Exception     {         ClassLoader cl     = msgContext.getClassLoader();         ClassCache cache   = msgContext.getAxisEngine().getClassCache();         JavaClass  jc      = cache.lookup(clsName, cl);         return jc.getJavaClass().newInstance();     } ==================================================================== 要想使用singleton模式 的ServletEndpointSupport,必须自定义一个 provider,并覆盖上面的方法

部署j2ee 应用的基本规范

   1.基本过程:creation -> assembly -> deployment    2.基本结构       若干个同类的 java ee component(如 web, ejb)   组成 一个 java ee module( 可以有,也可以没有 deployment descriptor 。 可独立部署)       几个java ee module 再组合成 一个 ee applcation ( 有 deployment descriptor, META-INF/application.xml )    3.把库加入到类路径       a.ear包里的库.可选方法为以下之一:           i.在manifest.mf中指明Class-Path          ii.deployment descriptor 器指明 library-directory,或者直接把库都放到 lib目录下         另外,web app中的库应放到 WEB-INF/lib …

部署j2ee 应用的基本规范 Read More »

spring + axis集成开发(服务器端)

   1.用POJO写的service: 接口 +  实现类,并通过spring 注册为 业务bean    2.为上面的业务bean定义一个decorator,并让它继承ServletEndpointSupport类。      除了装饰原来的业务方法外,还要重载ServletEndpointSupport的onInit()方法.      在 onInit()里,把业务bean从ApplicationContext中取出来    3.最后写一个wsdd文件,定义web service 的名字,并使它与上面定义的decorator挂钩

我对文档的要求:必要的、最小的冗余

    软件文档究竟应该怎么写?写多细?要不要写?有很多不同的看法。有人认为文档应该完备和优雅,并且总是应该用作下一个阶段的驱动;有人认为文档是要写的,但不必区分文档性质,文档间的组织结构也无所谓;有人则认为文档除了浪费时间之外没有任何意义,尤其在中国这个以“中档质量低档价格”的营销环境下,文档只会影响快速交付,降低竞争力,最终让股东很不高兴。      我个人的观点是: 文档应该用作代码的 必要的、最小的冗余。也就是说,          1.文档是代码的冗余,因为文档里有的东西,代码里其实都有          2. 这个冗余是必要的,否则无法保障软件质量          3. 冗余应该是最小的,否则它会项目进度,并且让项目成员很不快乐           首先,文档里的东西代码里都有,这个不必说。      既然文档是冗余的东西,是不是应该去掉? 如果项目成员能够牢记功能和代码的对应关系,并且能够飞速地扫描代码找到自己所需要的东西,那文档的确可以去掉;否则,还是应该把某些东西成文归档,记个笔记,尤其是需求文档,它是软件产品的最终参考,并且充当了需求人员和开发人员之间的契约,必须做的完备。      但是,中国的软件公司都有普遍现状:文档超乱!最主要的原因有:         1.项目太紧,没时间写         2.文档格式很臃肿,不想碰它         3.文档评审很麻烦         4.我习惯在编码的过程中把设计做好,不想先写文档         5.更新文档,有一种返工的感觉,超烦      所以,要尽量在质量和进度以及烦恼指数上达到平衡。我的建议是,只写“最小的”文档。它包括:         1. 文档工作量尽量地少。我只觉得三个文档是必须的:需求规格说明书,概要设计文档和测试用例。而且,概要设计文档没必要太细致。         2. 抛弃文档模板,只写有必要写的东西。现在很多设计文档里都喜欢把“需求背景”复述一便,换了我写一个“略”字带过         3. 确立开为人员作为文档的主导者,改了代码后自己迅速修改文档,由于自己熟悉文档,在评审时也可以与业务分析人员迅速沟通。         4. 完全可以在开发完成后再补充文档。你完全可以在快速编码的过程中通过调试实现最优设计,这种设计往往比预先的设计要少很多漏洞。         5. 文档不要再建副本。一个组织就一份文档,其版本通过版本工具来维护,不要用邮件发来发去,副本太多是引发混乱的前奏。