Could not instantiate class XXX from tuple at AliasToBeanConstructorResultTransformer 的處理辦法
今天客戶方服務器上突然有一個功能保存了,查看日志信息后發現,錯誤信息:
Google了很久才發現有可能是HQL語句中別名的問題,具體原因未知,現在處理辦法是,將下面的語句中的別名去掉:
具體是否可以解決,還要看一會兒的部署情況。
今天客戶方服務器上突然有一個功能保存了,查看日志信息后發現,錯誤信息:
上篇文章中我簡單闡述了軍工企業信息化遇到的困境,而我們公司(西安融智軟件有限公司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的源碼,修改并編譯屬于自己的瀏覽器了。。。
作為一個技術人員,誰不知道構架?
前一段時間公司找開發人員談心,有位領導問一位開發人員,大致對話如下:
A:“你了解咱們現在產品的構架嗎?能不能談談你對構架的看法?”
B:“… …”
A:“說說看吧~”
B:“我不懂構架!構架是什么?咱們現在的產品還有構架呢?”
作為一個有3年工作經驗,2家公司經歷的VC程序員來說,我覺得,這幾年的積累是白做了!這樣的思想永遠都只能停留在寫程序上~
一個產品沒有構件,就如同一個人沒有靈魂一樣!他不是沒有,只是你沒有去思考,沒有去發現他而已!
我記得袁洪剛說過,“一個偉大的產品背后一定有一個偉大構架師!”,我堅信這一點~產品好壞一方面決定于對現實問題的解決程度,另一方面是構架的好壞!
幾年前,中國的軟件公司里面很少出現構架師/架構師這樣的角色,這幾年開始有改觀了,越來越多的人開始認識到很多錯誤的問題,其實從一開始就是錯的。很多事情并沒有謀定而后動。一味的追求簡單,到最后變成了下線很簡單了!
說自己不知道構架的開發人員有兩種,新手和沒有思想的新手,拼命的同時我們也應該停下腳步想想,抬起頭看看天空。別總把經驗的缺失都歸結于時間的長短,更應該想想自己是否真的積累過。
無狀態會話Bean發布為WebService是非常有意義的,因為如果我們將每一個EJB模塊按照SOA的思想做成一個一個獨立的服務模塊(這里不討論SCA,我認為Apache的SCA框架還不夠強大,文檔還不夠全面),同樣的代碼在JavaEE體系之內的應用程序可以直接使用EJB3直接訪問,JavaEE體系之外的應用程序可以直接使用WebService訪問,這一點是非常有意義的。
下面要考慮的就是如何只寫一份代碼,讓它能做兩樣事情。
網上有大量的使用EJB3發布WebService的教程,但是這些教程都是一個人寫的,基本上沒有太大的參考價值。最重要的是,他寫的元注釋都是寫在實現類上的,接口上沒有做任何描述。這種做法有兩個問題,第一如果你的會話Bean使用了EM,那么麻煩了,JAXB在做綁定的時候不認識接口;第二WSDL文件的描述實際上應該是基于接口的描述,應該和實現類沒有太大的關系。
看看網上流行的代碼:
注意,基于RPC綁定模式下List,Set一類的接口都是不可傳輸的,這點會很麻煩,要用必須用實現類。
看看我的代碼:
接口:
實現類:
這個WebService是針對接口發布出去,而且使用的DOCUMENT樣式,可以直接使用List、Set的接口。
這個WebService生成的WSDL文件很有意思:
里面有import來指引到真正的WSDL文件。這樣很容易將會話Bean變成WS~一樣的代碼兩樣的功能,超值!
Wazaabi 2.0 基于 Eclipse3.4/EMF/GEF 的動態界面設計和現實組件,依賴EMF進行界面描述,依賴GEF進行界面顯示。
比較起XUI,XSWT,它的設計器更加的完善,功能比較1.0版本也有很大的提高,而且作者也提出了使用EMF進行數據綁定的思路和實現。
麻煩的是它本身只提供了Fill和Row兩種布局,Button、Text、List、Label這些基本控件。還好作者的文檔功底不錯,簡單幾張圖就把自己的設計思路描述的清清楚楚,高手所為,贊一個!
在它基礎上可以很簡單的進行擴展,而且比擴展VE要簡單的多~這是我喜歡的!現在對它的使用本人還是處于觀望態度,一方面等待它的持續更新,另一方面等待E4的激動人心的放出!
明顯第一種構架比第二種構架好很多,但是我們偏偏在第二種構架上面掙扎了半年的時間。
總是有各種各樣的接口和推辭說業務太復雜,客戶催的太緊,沒辦法把業務放到服務器上,成本太高了!已經是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程序,然后使用:
重新啟動應用程序,太復雜,而且上次打開的參數都會丟失。
這個問題非常的重要!
做過RCP開發的朋友應該都遇到過,使用AbstractSplashHandler做的登陸界面,在windows的任務欄上面是不會顯示的,這個問題讓客戶用起來很麻煩,總是動不動就找不到登陸界面了!現在有解決辦法了~