今天客户方服务器上突然有一个功能保存了,查看日志信息后发现,错误信息:
Could not instantiate class XXX from tuple at AliasToBeanConstructorResultTransformer...
Google了很久才发现有可能是HQL语句中别名的问题,具体原因未知,现在处理办法是,将下面的语句中的别名去掉:
StringBuffer hql = new StringBuffer("select new ContractItem(l, "
+ " pi.unitPrice, " + " pi.currencyType, " + "pi.currencyTypeDisplay," + " pi.units, "
+ " sum(pi.quantity + pi.adjQuantity), " + " pp, " + " pi.task) "
+ " from PurchasePlanItem pi " + " join pi.purchasePlan pp"
+ " join pi.priorList l " + " where l.supplierNo = ? "
+ " and pp.id in (");
具体是否可以解决,还要看一会儿的部署情况。
上篇文章中我简单阐述了军工企业信息化遇到的困境,而我们公司(西安融智软件有限公司www.xardmu.com)则主要是面向军工企业进行软件产品的研发和定制项目的开发的。
在产品实施和项目研发过程中,我们的前端技术人员需要做大量的浏览器兼容性的工作。痛苦至极啊~而且,即便完成了兼容性的修改,浏览器端的JS解析又变成了巨大的瓶颈!例如我们有一个项目为了提高用户使用的时的方便性,使用了EXTJS4,结果在IE6下性能极其低下。我们的P8是一个项目管理软件,需要使用到基于EXTJS的Gantt组件,但是此组件在IE6下十分不稳定,而且经常导致IE6崩溃。
介于上面的种种问题,我们开始寻找从浏览器上解决问题的方法,例如使用FireFox或者Chrome,因为军工企业都有域,所以通过域安装一款软件是十分容易的。经过权衡,我们决定使用Chrome做为我们软件的入口。
在企业内部署Chrome其实有三种方式:
1.直接使用Chrome的某一个版本,对此版本进行精简和简单的参数配置,或者内置一些自定义的插件,直接进行部署。
优点:技术门槛较低,只需要简单的精简安装文件和配置参数即可。
缺点:无法通过统一的策略管理局域网内所有的部署情况和策略。
2.使用Google提供的Chrome商业版,通过Google提供的商业版可以轻松定制自己企业内部的Chrome,并生成分发文件,同时可以通过配合域策略完成对局域网内的客户端的行为进行限制。
优点:此版本是11年放出的,一直和多个大型企业紧密合作,相信不久将会形成更加完善的方案,从而在企业级应用市场站稳脚跟。
缺点:需要在线安装。
3.使用Google的Chrome Frame,一个让披着IE外壳的Chrome,拥有Chrome的所有性能,只是披着IE的外壳而已。
优点:对于较老一些的企业,而且企业内部又拥有大量的IE时代产物的企业,绝对是一个好选择。
缺点:需要在线安装。原有软件代码需要修改,才能在用户浏览时使用Chrome模式。
看到痛苦了吧?都需要在线安装。看来下一步只能开始研究Chrome的源码,修改并编译属于自己的浏览器了。。。
最近在做项目的过程中,有些时候需要用Oracle的BLOB/CLOB类型存储一些很长的文章,一直不知道怎么来进行相关的检索,经过不懈的努力,终于能够解决这个问题了。查询语句如下:
select count(*) from 表名 where dbms_lob.instr(表名.列名, utl_raw.cast_to_raw(convert('关键词','utf8')), 1, 1) > 0;
需要注意的是,这个解决方案只能查询BLOB/CLOB中存储的是经过处理的字符串。
本方法在Oracle 10g上测试通过
转自http://commandos.blog.51cto.com/154976/128732
作为一个技术人员,谁不知道构架?
前一段时间公司找开发人员谈心,有位领导问一位开发人员,大致对话如下:
A:“你了解咱们现在产品的构架吗?能不能谈谈你对构架的看法?”
B:“… …”
A:“说说看吧~”
B:“我不懂构架!构架是什么?咱们现在的产品还有构架呢?”
作为一个有3年工作经验,2家公司经历的VC程序员来说,我觉得,这几年的积累是白做了!这样的思想永远都只能停留在写程序上~
一个产品没有构件,就如同一个人没有灵魂一样!他不是没有,只是你没有去思考,没有去发现他而已!
我记得袁洪刚说过,“一个伟大的产品背后一定有一个伟大构架师!”,我坚信这一点~产品好坏一方面决定于对现实问题的解决程度,另一方面是构架的好坏!
几年前,中国的软件公司里面很少出现构架师/架构师这样的角色,这几年开始有改观了,越来越多的人开始认识到很多错误的问题,其实从一开始就是错的。很多事情并没有谋定而后动。一味的追求简单,到最后变成了下线很简单了!
说自己不知道构架的开发人员有两种,新手和没有思想的新手,拼命的同时我们也应该停下脚步想想,抬起头看看天空。别总把经验的缺失都归结于时间的长短,更应该想想自己是否真的积累过。
Wazaabi 2.0 基于 Eclipse3.4/EMF/GEF 的动态界面设计和现实组件,依赖EMF进行界面描述,依赖GEF进行界面显示。
比较起XUI,XSWT,它的设计器更加的完善,功能比较1.0版本也有很大的提高,而且作者也提出了使用EMF进行数据绑定的思路和实现。
麻烦的是它本身只提供了Fill和Row两种布局,Button、Text、List、Label这些基本控件。还好作者的文档功底不错,简单几张图就把自己的设计思路描述的清清楚楚,高手所为,赞一个!
在它基础上可以很简单的进行扩展,而且比扩展VE要简单的多~这是我喜欢的!现在对它的使用本人还是处于观望态度,一方面等待它的持续更新,另一方面等待E4的激动人心的放出!
有兴趣的朋友可以看看http://www.wazaabi.org/index.php?title=Main_Page
明显第一种构架比第二种构架好很多,但是我们偏偏在第二种构架上面挣扎了半年的时间。
总是有各种各样的接口和推辞说业务太复杂,客户催的太紧,没办法把业务放到服务器上,成本太高了!已经是2009年了,10年前大家就意识到维护是关键,业务一定要封装,不能分散于客户端… …10年后的今天我们竟然还在挣扎!完全没有思想,完全没有设计,完全没有接口,完全没有OO… …!!!
项目告一段落我要拼命的重构,彻底抽离公共业务,彻底剥离特殊业务,我要OO,我要接口,我要设计,我甚至还要SOA!
我错了!我认错!可是为什么公司还有那么多的人还是不认错呢?做了10年的产品,10年前的东西竟然比10年后的东西还好用!做了10年还是死缠烂打在10年前的原型之上~他们比我更悲哀~
粗心大意,老犯错!
今天上午在调试EJB3调用WebService时一直遇到MySQL报出的这个问题。郁闷坏了,只是执行了一句update而已,就导致这样错误… …
经过半个小时排查,终于找到问题所在了。原因是分布式事务引起的。
场景描述:
EJB3操作A表-->调用WebService-->WebService操作B表
在操作A表的时候需要等待WebService的调用,如果没有异常,则可以提交事务,如果出现异常,则不能提交事务;
在操作B表的时候需要处理异常;
一个简单的分布式事务,一般情况下是没有问题的~但是由于我的粗心大意,做成了EJB3也在操作B表,这样就导致了表被锁死的情况出现~真是郁闷啊!
以前我们的产品重启RCP应用程序的时候都是找到本地路径的EXE程序,然后使用:
1Runtime runtime = Runtime.getRuntime();
2runtime.exec("cmd.exe /c " + excuteStr );
重新启动应用程序,太复杂,而且上次打开的参数都会丢失。
今天早上翻看了一下Eclipse的org.eclipse.update.ui CVS,找到了:
PlatformUI.getWorkbench().restart();
使用这个重新启动RCP应用程序,非常的方便,而且参数都在,即使在开发环境下也一样没有问题!