1.涓嬭澆
http://activemq.apache.org/download.html
2.瑙ｅ帇
灝嗕笅杞戒笅鏉ョ殑apache-activemq-5.2.0-bin.tar.gz鏀劇疆浜?usr/local
cd /usr/local/
tar xvfz apache-activemq-5.2.0-bin.tar.gz
鍒橝ctiveMQ鐨勫畨瑁呯洰褰曚負錛?usr/local/apache-activemq-5.2.0
3.淇敼activemq榪愯鏂囦歡鐨勬潈闄?br /> cd /usr/local/apache-activemq-5.2.0/bin
chmod 755 activemq
4.榪愯
(1).鏅氬惎鍔?br /> bin/activemq
(2).鎸囧畾鏃ュ織鏂囦歡鐨勫惎鍔ㄦ柟寮?br /> bin/activemq >/tmp/smlog 2>&1 &
(3)鍚庡彴鍚姩鏂瑰紡
nohup bin/activemq >/tmp/smlog 2>&1 &
榪欓噷闇瑕佹敞鎰忥細鍓嶄袱縐嶅惎鍔ㄦ柟寮忓湪linix鍛戒護琛屾垨鑰呴氳繃ssh瀹㈡埛绔惎鍔ㄦ椂鍦ㄥ叧闂搴旂殑紿楀彛鏃禷ctivemq浼氬叧闂紝鐢氳嚦鐩存帴ctrl+c涔熶細瀵艱嚧activemq閫鍑猴紱絎笁縐嶅垯涓嶄細鍑虹幇榪欑鎯呭喌銆?br />
5.楠岃瘉鏈嶅姟绔槸鍚﹀紑鍚紝鏈夊嚑縐嶆柟娉?br /> (1).鏌ョ湅鎺у埗鍙拌緭鍑烘垨鑰呮棩蹇楁枃浠?br /> (2).鐩存帴璁塊棶activemq鐨勭鐞嗛〉闈細http://localhost:8161/admin/
6.鍏抽棴activemq
濡傛灉寮鍚柟寮忔槸浣跨敤(1)鎴?2)錛屽垯鐩存帴ctrl+c鎴栬呭叧闂搴旂殑緇堢鍗沖彲
濡傛灉寮鍚柟寮忔槸(3),鍒欑◢寰夯鐑︿竴鐐癸細
鍏堟煡鎵懼埌activemq瀵瑰簲鐨勮繘紼嬶細
ps -ef | grep activemq
鐒跺悗鎶婂搴旂殑榪涚▼鏉鎺夛紝鍋囪鎵懼埌鐨勮繘紼嬬紪鍙蜂負 168168
kill 168168
]]>
鍦–XF鏈嶅姟绔厤緗甒EB SERVICE鏃訛紝閫氬父浼氬寘鍚竴浜涙潵姝xf.jar閲岄潰鐨刋ML鏂囦歡錛岀敤浜庤嚜鍔ㄩ厤緗渶瑕佷嬌鐢ㄥ埌鐨凚EAN
渚嬪錛?/p>
1
<import resource="classpath:META-INF/cxf/cxf.xml" />
2<import resource="classpath:META-INF/cxf/cxf-extension-soap.xml" />
3<import resource="classpath:META-INF/cxf/cxf-servlet.xml" />
<import resource="classpath:META-INF/cxf/cxf.xml" /> 2
<import resource="classpath:META-INF/cxf/cxf-extension-soap.xml" /> 3
<import resource="classpath:META-INF/cxf/cxf-servlet.xml" /> 浣嗘槸鍦ㄥ鎴風閰嶇疆鐨勬椂鍊欒繖浜涙枃浠舵槸涓嶉渶瑕佺殑錛岀敋鑷抽厤緗細寮曞彂閿欒錛岃緇嗙殑緇忚繃瑙佷笅鏂囥?/p>
緇忚繃錛?/font>
浠婂ぉ鍦ㄩ厤緗鎴風鐨勬椂鍊欙紝姝ラ鍜屽唴瀹歸兘鏄拰寰甯鎬竴鏍風殑錛屼絾鏄?/p>
鍑虹幇涓涓狽ullPointerException 鐨勯敊璇紝鍙煡閬撹繖涓敊璇槸鍦ㄥ垱寤哄鎴風service鐨勬椂鍊欏嚭鐨勯敊錛屼絾鏄師鍥犳壘涓嶅埌銆?/p>
閿欒鍫嗘爤錛?/p>
Caused by: java.lang.NullPointerException at org.apache.cxf.frontend.AbstractWSDLBasedEndpointFactory.createEndpointInfo(AbstractWSDLBasedEndpointFactory.java:160) at org.apache.cxf.frontend.AbstractWSDLBasedEndpointFactory.createEndpoint(AbstractWSDLBasedEndpointFactory.java:102) at org.apache.cxf.frontend.ClientFactoryBean.create(ClientFactoryBean.java:51) at org.apache.cxf.frontend.ClientProxyFactoryBean.create(ClientProxyFactoryBean.java:97) at org.apache.cxf.jaxws.JaxWsProxyFactoryBean.create(JaxWsProxyFactoryBean.java:89) at com.itravel.cxf.client.JaxWsProxyFactoryBean.create(JaxWsProxyFactoryBean.java:25) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.springframework.beans.factory.support.SimpleInstantiationStrategy.instantiate(SimpleInstantiationStrategy.java:115) 鐩村埌鍚庢潵鎴戝崟鐙姞杞戒簡鍒涘緩瀹㈡埛绔痵ervice鐨刟pplicationContext鏃訛紝鍒濆鍖栨槸姝ｅ父鐨勶紝鎵浠ュ氨鎬鐤戦厤緗枃浠跺嚭浜嗛棶棰橈紱
褰撲笂闈㈡彁鍒扮殑鍑犱釜琚寘鍚繘鏉ョ殑鏂囦歡鐨勯厤緗鍒犻櫎鍚庯紝涓鍒囧氨姝ｅ父浜嗐?/p>
鐜拌薄錛?/p>
鍦╓eb harvest涓嬌鐢╤ttp璇鋒眰鍘昏幏鍙栨煇涓繙紼嬬殑XML錛屾XML鐨勭壒寰佹槸鏃犳枃浠跺ご(鍗蟲病鏈夌紪鐮佹弿榪扮瓑鍏抽敭淇℃伅)錛岄噰鐢ㄤ簡澶氱鍔炴硶鍘昏幏鍙栵紝鍑虹幇涔辯爜錛屾棤娉曡В鏋愭垚鎴戜滑闇瑕佺殑鏁版嵁銆?/p>
鍔炴硶錛?/p>
(1)鏈鍘熷鍔炴硶錛?/font>浣跨敤Java涓殑URLConnection錛孖nputStream絳夌被璇誨彇瀛楄妭嫻侊紝鏋勯犲瓧絎︿覆錛?/p>
(2)鏈濂界殑鍔炴硶錛?/font>鐩存帴浣跨敤dom4j涓殑SAXReader 闈炲父綆鍗曪紝榪炵紪鐮侀兘涓嶇敤綆★紒 鍏朵腑錛歭ink涓洪渶瑕佽幏鍙朮ML鐨勫湴鍧
Java浠ｇ爜
Java浠ｇ爜
]]>
鏈榪戣繖鍑犲ぉ閮藉湪浣跨敤CXF浣滀負webservice鐨勭粍浠訛紝璇曞浘灝嗗叕寮鐨剋ebservice鍔犲叆鍒頒繚鎶ょ殑鑼冨洿鍐呫?/p>
娣誨姞鍒頒繚鎶ょ殑鏂規硶鏈変笁縐嶏細
(1)鎸囧畾鍦板潃璁塊棶錛屽嵆鎸囧畾涓浜汭P鍦板潃錛屽彧鏈夎繖浜涘湴鍧鐨勮姹傛垜浠殑鎺ュ彛鎵嶅鐞嗐?/font>
榪欑鏂規硶鎴戝湪寮鍙戜腑鏈変嬌鐢ㄥ埌錛屽彲浠ラ氳繃WEB瀹瑰櫒涓殑Filter綾繪潵瀹炵幇錛?/p>
鍙渶瑕佹鏌ヨ姹傜殑鍦板潃鏄惁鍦ㄦ垜浠寚瀹氱殑鍦板潃鍒楄〃涓氨鍙互浜嗐?/p>
浼樼偣:澶勪簬璇鋒眰鍝嶅簲閾劇殑鍓嶇錛屽搷搴旈潪甯歌繀閫燂紝鎵浠ユ秷鑰楃殑璧勬簮寰堝皯銆?/p>
緙虹錛?/font>浣跨敤榪欑鏂規硶鍙兘媯鏌ユ寚瀹氬湴鍧鐨勮姹傦紝閫氬父鍙兘搴旂敤鐨勫皬鑼冨洿鍐咃紝濡傚眬鍩熺綉銆?/p>
鍙﹀浣跨敤榪欑楠岃瘉鏂規硶錛屾棤娉曡繘琛屾潈闄愮殑媯鏌ワ紝涓鏃﹂氳繃楠岃瘉灝嗗彲浠ユ墽琛屾墍鏈夊叕寮鐨勬帴鍙ｃ?/p>
(2)鐢ㄦ埛鍚?瀵嗙爜瀵歸獙璇侊紝浣跨敤鎸囧畾鐨勭敤鎴峰悕瀵嗙爜榪涜楠岃瘉
榪欑鏂規硶閫傚悎浜庡叿浣撶敤鎴風殑媯鏌ワ紝榪涜屽彲浠ユ鏌ュ叾鏄惁鏈夋潈闄愭墽琛屽叾璇鋒眰鐨勬搷浣?
浼樼偣錛?/span>鍙互鍙噯紜湴媯鏌ョ敤鎴鳳紝鐢氳嚦楠岃瘉鏉冮檺銆?/p>
緙虹偣錛?/span>榪欑鏂瑰紡涓嶈兘鍜學EB搴旂敤鐨勭櫥褰曚竴鏍鳳紝鍙渶瑕侀獙璇佷竴嬈″氨鍙互浜嗭紱蹇呴』 姣忎釜璇鋒眰閮芥鏌ワ紝濡傛灉闇瑕佷嬌鐢ㄨ繖縐嶆柟娉曞幓鍋氾紝榪橀渶瑕佸鐞嗗ソ綾諱技鐧誨綍/閫鍑烘満鍒躲?/p>
(3)浣跨敤HTTPS榪涜楠岃瘉錛岃繖縐嶆柟娉曞簲璇ヤ篃鍙互鍏蜂綋鐨勯獙璇佽瘉涔︽潵鑷摢涓敤鎴鳳紝榪涜屾鏌ュ叾鏉冮檺銆?/font> 浼樼偣錛?/font>瀹夊叏鏇存湁淇濊瘉 緙虹偣錛?/font>閰嶇疆澶嶆潅錛屽瀹㈡埛绔▼搴忓憳瑕佹眰寰堟瘮杈冮珮銆?/p>
娉ㄦ剰浜嬮」錛?/font> 浣跨敤CXF榪涜WEBService浜や簰鏃訛紝鐗瑰埆鏄繘琛屽鎴風宸ヤ綔鏃訛紝鏈濂藉皢鏈嶅姟绔拰瀹㈡埛绔殑鐜鍓ョ寮鏉ャ?/p>
榪欏嚑澶╃殑宸ヤ綔鏁欎細浜嗘垜榪欎釜浜嬫儏(浠婂ぉ涓婂崍鍦ㄦ祴璇曞鎴風浠ｇ爜鏃跺嚭鐜拌帿鍚嶅叾濡欑殑閿欙紝鏈鍚庡彂鐜版槸JAR鍖呭啿紿侊紝 鍦ㄦ湇鍔″櫒鐨勭幆澧冧腑榪愯瀹㈡埛绔▼搴忔椂錛岀▼搴忓姞杞戒簡榪囨椂鐨凧AR)銆?/p>
linux浣跨敤ANT緙栬瘧java綾誨茍閮ㄧ講鍒癟omcat涓嬶紝鐒跺悗浣跨敤鑴氭湰(deploy.sh)寮鍚疶omcat,鑴氭湰濡備笅:
deploy.sh(鍏剁粷瀵硅礬寰勪負錛?usr/local/myapp/deploy.sh)
1/usr/local/apache-tomcat-5.5.20/bin/shutdown.sh
2ant
3/usr/local/apache-tomcat-5.5.20/bin/startup.sh
4
鍏朵腑鍚勮鐨勬剰涔夛細/usr/local/apache-tomcat-5.5.20/bin/shutdown.sh2
ant3
/usr/local/apache-tomcat-5.5.20/bin/startup.sh4
(1)鍏抽棴tomcat
(2)緙栬瘧java綾誨茍閮ㄧ講鍒皌omcat
(3)寮鍚痶omcat
榪欓噷浣跨敤鐨勫懡浠ら兘鏄粷瀵硅礬寰勮繍琛岀殑銆?br />
闂鏉ヤ簡錛?/strong>
(1)鍦ㄩ」鐩腑瀹夋帓浜唋og4j鐨勬棩蹇楄緭鍑哄埌myapp.log,鍏惰礬寰勫啓娉曪細../log/myapp.log;鍚姩鏈嶅姟鍣ㄧ殑鏃跺欏湪catalina.out涓緭鍑洪敊璇俊鎭紝璇?./log/myapp.log娌℃湁鎵懼埌銆?br /> (2)鍦ㄧ▼搴忎腑浣跨敤浜唎utput/files/錛岀▼搴忓畬鎴愬悗寰堥毦鎵嶆壘鍒版枃浠訛紝鍥犱負鍏朵綅緗茍涓嶅儚鍦╳indow涓嬭皟璇曟椂涓鏍鳳紝鏈鍚庝嬌鐢?find -name output -type d鍛戒護鎵嶆壘鍒幫紝鍙戠幇鍘熸潵榪欎釜鏂囦歡澶規墍鍦ㄧ殑浣嶇疆灝辨槸鍦細/usr/local/myapp/涓嬮潰銆?br />
鍊鍒濈幇錛?/strong>
鍙錛屼嬌鐢ㄨ剼鏈紑鍚痶omcat鏃跺鏋滀互緇濆璺緞鐨勬柟寮忓幓寮鍚殑璇濓紝閭ｄ箞鍦ㄧ▼搴忎腑鐨勭浉瀵硅礬寰勫氨浼氫互鑴氭湰鐨勫綋鍓嶇洰褰曚綔涓鴻礬寰勭殑璧峰鐐廣傝繖鏍峰氨瀵艱嚧浜嗗湪鏂囦歡鐨勪綅緗笂鍑虹幇鍙樺寲錛屼嬌寰楁枃浠剁鐞嗗嚭鐜板洶闅劇敋鑷沖宸叉湁鐨勬枃浠墮犳垚鐮村潖銆?br />
闂瑙ｅ喅錛?br /> 瑙ｅ喅璺緞鐨勯棶棰樻湁寰堝錛屽湪榪欓噷涓昏璇翠竴涓嬩互涓嬩袱涓濊礬錛?br /> (1)浣跨敤鍙厤緗殑緇濆璺緞錛屽湪ANT閮ㄧ講鐨勬椂鍊欙紝鍙互灝哤indow涓嬬殑璺緞鏇挎崲鎴怢inux涓嬬殑緇濆璺緞錛岃繖鏍峰氨寰堟柟渚跨鐞嗭紝姝や負涓婄瓥銆?br /> (2)浣跨敤鐩稿璺緞鏃訛紝寮鍚疶omcat鏃朵竴瀹氳鍒囨崲鍒皌omcat鐨刡in鏂囦歡澶瑰紑鍚紝榪欐牱鐩稿璺緞鎸囧悜鐨勪綅緗氨鍜學indow涓嬬殑涓鑷翠簡錛屾涓轟笅絳栦篃銆?br /> 浣跨敤鐩稿璺緞鐨勮剼鏈涓嬶細
1/usr/local/apache-tomcat-5.5.20/bin/shutdown.sh
2ant
3cd /usr/local/apache-tomcat-5.5.20/bin/
4./startup.sh
鍏朵腑鍚勮鐨勪綔鐢細/usr/local/apache-tomcat-5.5.20/bin/shutdown.sh2
ant3
cd /usr/local/apache-tomcat-5.5.20/bin/4
./startup.sh(1)鍏抽棴tomcat
(2)緙栬瘧java綾誨茍閮ㄧ講鏂囦歡
(3)鍒囨崲鐩綍鍒皌omcat鐨刡in鏂囦歡澶?br /> (4)寮鍚痶omcat
浼拌鍏朵粬搴旂敤鏈嶅姟鍣ㄤ笅浣跨敤鑴氭湰鍜岀浉瀵硅礬寰勪篃鏃朵篃浼氶亣鍒頒竴鏍風殑闂錛屾柟娉曚及璁′篃鏄被浼肩殑銆?br />
]]>
鍋囪闆嗘垚鐜涓紝瑁呮湁apache2鐨勬満鍣ㄥ湪灞鍩熺綉涓殑鍦板潃涓?92.168.1.55錛屼笅闈㈢畝縐?5錛涜鏈塼omcat5鐨勬満鍣ㄧ殑鍦板潃涓?92.168.1.66錛屽悗闈㈢畝縐?6
閭ｄ箞鍦?5涓渶瑕佹彁渚涚殑鏄疦FS鏈嶅姟錛?br />
鍦?etc/exports涓坊鍔犲涓嬭鍙ワ細
{apache2_home}/htdocs 192.168.1.*(ro,no_root_squash)
鍏朵腑
{apache2_home}/鏄寚apache2鐨勫畨瑁呯洰褰曪紱
192.168.1.*鏄寚鍙闂殑鍩?br /> ro閫夐」鏄寚璁塊棶鐨勬潈闄?br /> no_root_squash閫夐」鏄寚55鐨剅oot鍦ㄨ繖涓枃浠跺す涓嬫病鏈夊啓鐨勬潈闄?br />
寮鍚疦FS鏈嶅姟鐨勫懡浠わ細
service nfs start
鐒跺悗鍦?6涓繍琛屽彟澶栦竴涓懡浠わ細
mount -o nolock 192.168.1.55:{apache2_home}/htdocs {tomcat_home}/webapps/ROOT
PS:濡傛灉淇敼浜?etc/exports鐨勮瘽闇瑕侀噸鏂板紑鍚痭fs鏈嶅姟錛岄偅涔堝叧闂殑鍛戒護鏄細service nfs stop銆?br />
]]>
鏈鍚庢洿鏂版椂闂?:2008-09-03
閰嶇疆綾?
杞繪澗瀹炵幇Apache,Tomcat闆嗙兢鍜岃礋杞藉潎琛?/a>
java涓殑璺緞闂
鏁版嵁搴撶被:
oracle 鍒嗗尯琛ㄧ殑寤虹珛鏂規硶
鍔卞織綾?
]]>
鍙夐」璇存槑錛?
1) assigned
涓婚敭鐢卞閮ㄧ▼搴忚礋璐ｇ敓鎴愶紝鏃犻渶Hibernate鍙備笌銆?
2) hilo
閫氳繃hi/lo 綆楁硶瀹炵幇鐨勪富閿敓鎴愭満鍒訛紝闇瑕侀澶栫殑鏁版嵁搴撹〃淇濆瓨涓?
閿敓鎴愬巻鍙茬姸鎬併?
3) seqhilo
涓巋ilo 綾諱技錛岄氳繃hi/lo 綆楁硶瀹炵幇鐨勪富閿敓鎴愭満鍒訛紝鍙槸涓婚敭鍘嗗彶
鐘舵佷繚瀛樺湪Sequence涓紝閫傜敤浜庢敮鎸丼equence鐨勬暟鎹簱錛屽Oracle銆?
4) increment
涓婚敭鎸夋暟鍊奸『搴忛掑銆傛鏂瑰紡鐨勫疄鐜版満鍒朵負鍦ㄥ綋鍓嶅簲鐢ㄥ疄渚嬩腑緇存寔
涓涓彉閲忥紝浠ヤ繚瀛樼潃褰撳墠鐨勬渶澶у鹼紝涔嬪悗姣忔闇瑕佺敓鎴愪富閿殑鏃跺?
灝嗘鍊煎姞1浣滀負涓婚敭銆?
榪欑鏂瑰紡鍙兘浜х敓鐨勯棶棰樻槸錛氬鏋滃綋鍓嶆湁澶氫釜瀹炰緥璁塊棶鍚屼竴涓暟鎹?
搴擄紝閭ｄ箞鐢變簬鍚勪釜瀹炰緥鍚勮嚜緇存姢涓婚敭鐘舵侊紝涓嶅悓瀹炰緥鍙兘鐢熸垚鍚屾牱
鐨勪富閿紝浠庤岄犳垚涓婚敭閲嶅寮傚父銆傚洜姝わ紝濡傛灉鍚屼竴鏁版嵁搴撴湁澶氫釜瀹?
渚嬭闂紝姝ゆ柟寮忓繀欏婚伩鍏嶄嬌鐢ㄣ?
5) identity
閲囩敤鏁版嵁搴撴彁渚涚殑涓婚敭鐢熸垚鏈哄埗銆傚DB2銆丼QL Server銆丮ySQL
涓殑涓婚敭鐢熸垚鏈哄埗銆?
6) sequence
閲囩敤鏁版嵁搴撴彁渚涚殑sequence 鏈哄埗鐢熸垚涓婚敭銆傚Oralce 涓殑
Sequence銆?
7) native
鐢盚ibernate鏍規嵁搴曞眰鏁版嵁搴撹嚜琛屽垽鏂噰鐢╥dentity銆乭ilo銆乻equence
鍏朵腑涓縐嶄綔涓轟富閿敓鎴愭柟寮忋?
8) uuid.hex
鐢盚ibernate鍩轟簬128 浣嶅敮涓鍊間駭鐢熺畻娉曠敓鎴?6 榪涘埗鏁板鹼紙緙栫爜鍚?
浠ラ暱搴?2 鐨勫瓧絎︿覆琛ㄧず錛変綔涓轟富閿?
9) uuid.string
涓巙uid.hex 綾諱技錛屽彧鏄敓鎴愮殑涓婚敭鏈繘琛岀紪鐮侊紙闀垮害16錛夈傚湪鏌愪簺
鏁版嵁搴撲腑鍙兘鍑虹幇闂錛堝PostgreSQL錛夈?
10) foreign
浣跨敤澶栭儴琛ㄧ殑瀛楁浣滀負涓婚敭銆?
涓鑸岃█錛屽埄鐢╱uid.hex鏂瑰紡鐢熸垚涓婚敭灝嗘彁渚涙渶濂界殑鎬ц兘鍜屾暟鎹簱騫沖彴閫?
搴旀с?
鍙﹀鐢變簬甯哥敤鐨勬暟鎹簱錛屽Oracle銆丏B2銆丼QLServer銆丮ySql 絳夛紝閮芥彁
渚涗簡鏄撶敤鐨勪富閿敓鎴愭満鍒訛紙Auto-Increase 瀛楁鎴栬匰equence錛夈傛垜浠彲浠ュ湪鏁?
鎹簱鎻愪緵鐨勪富閿敓鎴愭満鍒朵笂錛岄噰鐢╣enerator-class=native鐨勪富閿敓鎴愭柟寮忋?
涓嶈繃鍊煎緱娉ㄦ剰鐨勬槸錛屼竴浜涙暟鎹簱鎻愪緵鐨勪富閿敓鎴愭満鍒跺湪鏁堢巼涓婃湭蹇呮渶浣籌紝
澶ч噺騫跺彂insert鏁版嵁鏃跺彲鑳戒細寮曡搗琛ㄤ箣闂寸殑浜掗攣銆?
鏁版嵁搴撴彁渚涚殑涓婚敭鐢熸垚鏈哄埗錛屽線寰鏄氳繃鍦ㄤ竴涓唴閮ㄨ〃涓繚瀛樺綋鍓嶄富閿姸
鎬侊紙濡傚浜庤嚜澧炲瀷涓婚敭鑰岃█錛屾鍐呴儴琛ㄤ腑灝辯淮鎶ょ潃褰撳墠鐨勬渶澶у煎拰閫掑閲忥級錛?
涔嬪悗姣忔鎻掑叆鏁版嵁浼氳鍙栬繖涓渶澶у鹼紝鐒跺悗鍔犱笂閫掑閲忎綔涓烘柊璁板綍鐨勪富閿紝涔?
鍚庡啀鎶婅繖涓柊鐨勬渶澶у兼洿鏂板洖鍐呴儴琛ㄤ腑錛岃繖鏍鳳紝涓嬈nsert鎿嶄綔鍙兘瀵艱嚧鏁版嵁
搴撳唴閮ㄥ嬈¤〃璇誨啓鎿嶄綔錛屽悓鏃朵即闅忕殑榪樻湁鏁版嵁鐨勫姞閿佽В閿佹搷浣滐紝榪欏鎬ц兘浜х敓
浜嗚緝澶у獎鍝嶃?
鍥犳錛屽浜庡茍鍙慖nsert瑕佹眰杈冮珮鐨勭郴緇燂紝鎺ㄨ崘閲囩敤uuid.hex 浣滀負涓婚敭鐢熸垚
鏈哄埗銆?nbsp;
]]>
Whether you program regularly in Java, and know it like the back of your hand, or whether you're new to the language or a casual programmer, you'll make mistakes. It's natural, it's human, and guess what? You'll more than likely make the same mistakes that others do, over and over again. Here's my top ten list of errors that we all seem to make at one time or another, how to spot them, and how to fix them.
10. Accessing non-static member variables from static methods (such as main)
Many programmers, particularly when first introduced to Java, have problems with accessing member variables from their main method. The method signature for main is marked static - meaning that we don't need to create an instance of the class to invoke the main method. For example, a Java Virtual Machine (JVM) could call the class MyApplication like this :-
MyApplication.main ( command_line_args );
This means, however, that there isn't an instance of MyApplication - it doesn't have any member variables to access! Take for example the following application, which will generate a compiler error message.
public class StaticDemo
{
public String my_member_variable = "somedata";
public static void main (String args[])
{
// Access a non-static member from static method
System.out.println ("This generates a compiler error" +
my_member_variable );
}
}
If you want to access its member variables from a non-static method (like main), you must create an instance of the object. Here's a simple example of how to correctly write code to access non-static member variables, by first creating an instance of the object.
public class NonStaticDemo
{
public String my_member_variable = "somedata";
public static void main (String args[])
{
NonStaticDemo demo = new NonStaticDemo();
// Access member variable of demo
System.out.println ("This WON'T generate an error" +
demo.my_member_variable );
}
}
9. Mistyping the name of a method when overriding
Overriding allows programmers to replace a method's implementation with new code. Overriding is a handy feature, and most OO programmers make heavy use of it. If you use the AWT 1.1 event handling model, you'll often override listener implementations to provide custom functionality. One easy trap to fall into with overriding, is to mistype the method name. If you mistype the name, you're no longer overriding a method - you're creating an entirely new method, but with the same parameter and return type.
public class MyWindowListener extends WindowAdapter {
// This should be WindowClosed
public void WindowClose(WindowEvent e) {
// Exit when user closes window
System.exit(0);
}
});
Compilers won't pick up on this one, and the problem can be quite frustrating to detect. In the past, I've looked at a method, believed that it was being called, and taken ages to spot the problem. The symptom of this error will be that your code isn't being called, or you think the method has skipped over its code. The only way to ever be certain is to add a println statement, to record a message in a log file, or to use good trace debugger (like Visual J++ or Borland JBuilder) and step through line by line. If your method still isn't being called, then it's likely you've mistyped the name.
8. Comparison assignment ( = rather than == )
This is an easy error to make. If you're used other languages before, such as Pascal, you'll realize just how poor a choice this was by the language's designers. In Pascal, for example, we use the := operator for assignment, and leave = for comparison. This looks like a throwback to C/C++, from which Java draws its roots.
Fortunately, even if you don't spot this one by looking at code on the screen, your compiler will. Most commonly, it will report an error message like this : "Can't convert xxx to boolean", where xxx is a Java type that you're assigning instead of comparing.
7. Comparing two objects ( == instead of .equals)
When we use the == operator, we are actually comparing two object references, to see if they point to the same object. We cannot compare, for example, two strings for equality, using the == operator. We must instead use the .equals method, which is a method inherited by all classes from java.lang.Object.
Here's the correct way to compare two strings.
String abc = "abc"; String def = "def";
// Bad way
if ( (abc + def) == "abcdef" )
{
......
}
// Good way
if ( (abc + def).equals("abcdef") )
{
.....
}
6. Confusion over passing by value, and passing by reference
This can be a frustrating problem to diagnose, because when you look at the code, you might be sure that its passing by reference, but find that its actually being passed by value. Java uses both, so you need to understand when you're passing by value, and when you're passing by reference.
When you pass a primitive data type, such as a char, int, float, or double, to a function then you are passing by value. That means that a copy of the data type is duplicated, and passed to the function. If the function chooses to modify that value, it will be modifying the copy only. Once the function finishes, and control is returned to the returning function, the "real" variable will be untouched, and no changes will have been saved. If you need to modify a primitive data type, make it a return value for a function, or wrap it inside an object.
When you pass a Java object, such as an array, a vector, or a string, to a function then you are passing by reference. Yes - a String is actually an object, not a primitive data type. So that means that if you pass an object to a function, you are passing a reference to it, not a duplicate. Any changes you make to the object's member variables will be permanent - which can be either good or bad, depending on whether this was what you intended.
On a side note, since String contains no methods to modify its contents, you might as well be passing by value.
5. Writing blank exception handlers
I know it's very tempting to write blank exception handlers, and to just ignore errors. But if you run into problems, and haven't written any error messages, it becomes almost impossible to find out the cause of the error. Even the simplest exception handler can be of benefit. For example, put a try { .. } catch Exception around your code, to catch ANY type of exception, and print out the message. You don't need to write a custom handler for every exception (though this is still good programming practice). Don't ever leave it blank, or you won't know what's happening.
For example
public static void main(String args[])
{
try {
// Your code goes here..
}
catch (Exception e)
{
System.out.println ("Err - " + e );
}
}
4. Forgetting that Java is zero-indexed
If you've come from a C/C++ background, you may not find this quite as much a problem as those who have used other languages. In Java, arrays are zero-indexed, meaning that the first element's index is actually 0. Confused? Let's look at a quick example.
// Create an array of three strings String[] strArray = new String[3]; // First element's index is actually 0 strArray[0] = "First string"; // Second element's index is actually 1 strArray[1] = "Second string"; // Final element's index is actually 2 strArray[2] = "Third and final string";
In this example, we have an array of three strings, but to access elements of the array we actually subtract one. Now, if we were to try and access strArray[3], we'd be accessing the fourth element. This will case an ArrayOutOfBoundsException to be thrown - the most obvious sign of forgetting the zero-indexing rule.
Other areas where zero-indexing can get you into trouble is with strings. Suppose you wanted to get a character at a particular offset within a string. Using the String.charAt(int) function you can look this information up - but under Java, the String class is also zero-indexed. That means than the first character is at offset 0, and second at offset 1. You can run into some very frustrating problems unless you are aware of this - particularly if you write applications with heavy string processing. You can be working on the wrong character, and also throw exceptions at run-time. Just like the ArrayOutOfBoundsException, there is a string equivalent. Accessing beyond the bounds of a String will cause a StringIndexOutOfBoundsException to be thrown, as demonstrated by this example.
public class StrDemo
{
public static void main (String args[])
{
String abc = "abc";
System.out.println ("Char at offset 0 : " + abc.charAt(0) );
System.out.println ("Char at offset 1 : " + abc.charAt(1) );
System.out.println ("Char at offset 2 : " + abc.charAt(2) );
// This line should throw a StringIndexOutOfBoundsException
System.out.println ("Char at offset 3 : " + abc.charAt(3) );
}
}
Note too, that zero-indexing doesn't just apply to arrays, or to Strings. Other parts of Java are also indexed, but not always consistently. The java.util.Date, and java.util.Calendar classes start their months with 0, but days start normally with 1. This problem is demonstrated by the following application.
import java.util.Date;
import java.util.Calendar;
public class ZeroIndexedDate
{
public static void main (String args[])
{
// Get today's date
Date today = new Date();
// Print return value of getMonth
System.out.println ("Date.getMonth() returns : " +
today.getMonth());
// Get today's date using a Calendar
Calendar rightNow = Calendar.getInstance();
// Print return value of get ( Calendar.MONTH )
System.out.println ("Calendar.get (month) returns : " +
rightNow.get ( Calendar.MONTH ));
} }
Zero-indexing is only a problem if you don't realize that its occurring. If you think you're running into a problem, always consult your API documentation.
3. Preventing concurrent access to shared variables by threads
When writing multi-threaded applications, many programmers (myself included) often cut corners, and leave their applications and applets vulnerable to thread conflicts. When two or more threads access the same data concurrently, there exists the possibility (and Murphy's law holding, the probability) that two threads will access or modify the same data at the same time. Don't be fooled into thinking that such problems won't occur on single-threaded processors. While accessing some data (performing a read), your thread may be suspended, and another thread scheduled. It writes its data, which is then overwritten when the first thread makes its changes.
Such problems are not just limited to multi-threaded applications or applets. If you write Java APIs, or JavaBeans, then your code may not be thread-safe. Even if you never write a single application that uses threads, people that use your code WILL. For the sanity of others, if not yourself, you should always take precautions to prevent concurrent access to shared data.
How can this problem be solved? The simplest method is to make your variables private (but you do that already, right?) and to use synchronized accessor methods. Accessor methods allow access to private member variables, but in a controlled manner. Take the following accessor methods, which provide a safe way to change the value of a counter.
public class MyCounter
{
private int count = 0; // count starts at zero
public synchronized void setCount(int amount)
{
count = amount;
}
public synchronized int getCount()
{
return count;
}
}
2. Capitalization errors
This is one of the most frequent errors that we all make. It's so simple to do, and sometimes one can look at an uncapitalized variable or method and still not spot the problem. I myself have often been puzzled by these errors, because I recognize that the method or variable does exist, but don't spot the lack of capitalization.
While there's no silver bullet for detecting this error, you can easily train yourself to make less of them. There's a very simple trick you can learn :-
- all methods and member variables in the Java API begin with lowercase letters
- all methods and member variables use capitalization where a new word begins e.g - getDoubleValue()
If you use this pattern for all of your member variables and classes, and then make a conscious effort to get it right, you can gradually reduce the number of mistakes you'll make. It may take a while, but it can save some serious head scratching in the future.
(drum roll)
And the number one error that Java programmers make !!!!!
1. Null pointers!
Null pointers are one of the most common errors that Java programmers make. Compilers can't check this one for you - it will only surface at runtime, and if you don't discover it, your users certainly will.
When an attempt to access an object is made, and the reference to that object is null, a NullPointerException will be thrown. The cause of null pointers can be varied, but generally it means that either you haven't initialized an object, or you haven't checked the return value of a function.
Many functions return null to indicate an error condition - but unless you check your return values, you'll never know what's happening. Since the cause is an error condition, normal testing may not pick it up - which means that your users will end up discovering the problem for you. If the API function indicates that null may be returned, be sure to check this before using the object reference!
Another cause is where your initialization has been sloppy, or where it is conditional. For example, examine the following code, and see if you can spot the problem.
public static void main(String args[])
{
// Accept up to 3 parameters
String[] list = new String[3];
int index = 0;
while ( (index < args.length) && ( index < 3 ) )
{
list[index++] = args[index];
}
// Check all the parameters
for (int i = 0; i < list.length; i++)
{
if (list[i].equals "-help")
{
// .........
}
else
if (list[i].equals "-cp")
{
// .........
}
// else .....
}
}
This code (while a contrived example), shows a common mistake. Under some circumstances, where the user enters three or more parameters, the code will run fine. If no parameters are entered, you'll get a NullPointerException at runtime. Sometimes your variables (the array of strings) will be initialized, and other times they won't. One easy solution is to check BEFORE you attempt to access a variable in an array that it is not equal to null.
Summary
These errors represent but some of the many that we all make. Though it is impossible to completely eliminate errors from the coding process, with care and practice you can avoid repeating the same ones. Rest assured, however, that all Java programmers encounter the same sorts of problems. It's comforting to know, that while you work late into the night tracking down an error, someone, somewhere, sometime, will make the same mistake!
| We'd like to thank the readers of the comp.lang.java.programmer newsgroup for their suggestions for the top ten. Regrettably, due to the number of submissions, not every error could be featured - but we think this "Top Ten" list represents the most popular and frequent errors people make. |
]]>
javadoc command:搴旇閫夋嫨jdk鐨刡in/javadoc.exe
destination:涓虹敓鎴愭枃妗ｇ殑淇濆瓨璺緞錛屽彲鑷敱閫夋嫨銆?br /> 鎸塮inish(瀹屾垚)鎻愪氦鍗沖彲寮濮嬬敓鎴愭枃妗ｃ?br /> 2錛岀敤鑿滃崟閫夋嫨錛欶ile->Export(鏂囦歡錛?gt;瀵煎嚭)錛?br /> 鍓╀笅鐨勬楠ゅ拰絎竴縐嶆柟娉曟槸涓鏍風殑銆?br /> 3錛岄変腑瑕佺敓鎴愭枃妗ｇ殑欏圭洰錛岀劧鍚庣敤鑿滃崟閫夋嫨錛?br /> Project->Generate Javadoc鐩存帴榪涘叆Javadoc Generation瀵硅瘽妗嗭紝鍓╀綑鐨勬楠ゅ氨鍜岀涓縐嶆柟娉曞湪Javadoc Generation瀵硅瘽妗嗗紑濮嬫槸涓鏍風殑銆?nbsp;
]]>
]]>
http://propsorter.sourceforge.net/veloeclipse
Properties Editor
http://propedit.sourceforge.jp/eclipse/updates/
]]>
CAS鐢ㄦ潵鏍囧織鐢ㄦ埛鐨則oken鏄瓨鍦ㄥ畠鑷繁鐨勫煙鍚嶄笅鐨?涓嶆槸瀛樺湪web搴旂敤鐨勫煙鍚嶄笅鐨?CAS鍒ゆ柇鐢ㄦ埛鐧誨綍鐢盿gent鍐沖畾,agent楠岃瘉鐢ㄦ埛淇℃伅鏈変袱縐嶅鐞?
1.濡傛灉榪欎釜鐢ㄦ埛鏄互鍓嶆病鐧誨綍榪囩殑,涔熷氨鏄榪欎釜web搴旂敤鐨勫煙鍚嶄笅娌℃湁涓涓猘gent棰佸彂鐨剆essionid(鍦╟ookie閲?鐨勮瘽,閭ｄ箞瀹冧細璺寵漿鍒癈AS server鐨勭櫥褰曠晫闈?榪欓噷鐢盋AS server鍐沖畾鏄惁鏄劇ず鐧誨綍鐣岄潰,榪樻槸鐩存帴灝辮煩杞洖鏉?涔熷氨鏄笉鏄瘡嬈￠兘瑕佹眰杈撳叆瀵嗙爜鐧誨綍鐨?.
2.CAS鐨勭櫥褰曠晫闈細鏈変袱縐嶅鐞?濡傛灉浠ュ墠娌＄櫥褰曡繃,涔熷氨鏄湪CAS server鑷繁鐨勫煙鍚嶄笅,娌℃湁鐢ㄦ埛鐨則oken鐨勮瘽,灝辮姹傜櫥褰?濡傛灉鏈塼oken鐨勮瘽,灝辮繑鍥炰竴涓猼icket(涔熷氨鏄笉鏄劇ず鐧誨綍鐣岄潰鐩存帴閲嶅畾鍚戣繑鍥炰簡).
鐒跺悗鎺ョ涓姝ラ噷闈?agent鏀跺埌ticket浠ュ悗灝辨彁浜ょ粰CAS server楠岃瘉,騫跺彇寰楄繑鍥炰俊鎭?鏄釜xml,cas鐨勫崗璁瀹氱殑,涔熷彲浠ョ敤saml涔嬬被鐨?榪欎釜鍦版柟鍙互鍙栧緱闄や簡鐢ㄦ埛濮撳悕浠ュ鐨勪俊鎭?榪欐牱灝卞彲浠ュ仛鍚屾浜?鏉冮檺鐨勯棶棰樺彲浠ヨ繖涔堣В鍐?.鐒跺悗agent灝變繚瀛樻鏃剁殑session,鎶妔essionid鏀懼埌璇eb搴旂敤鍩熷悕涓嬬殑cookie閲?
浠ヤ笂閫昏緫璇存槑浜?鏍囧織鐢ㄦ埛韜喚鐨則oken鍦–AS server鐨勫煙鍚嶄笅,姣忎釜web搴旂敤涓嶄繚瀛樼敤鎴瘋韓浠?鍥犳璺ㄥ煙鏄粷瀵規病闂鐨?鍙槸single sign off灝遍渶瑕丆AS server鐨勯厤鍚堜簡,瑕佹妸閭ｄ釜token鍒犳帀.
涓嶈繃濡傛灉鏍囧織韜喚鐨則oken涓嶅瓨鍦?鑰宻essionid瀛樺湪,閭ｈ繕鏄璁や負鏄櫥褰曠殑,鍙笉榪囨槸鍦ㄧ瓑寰呴偅涓猻ession timeout鑰屽凡.
]]>
!-----------------------------------------------------------------------------!
! PATTERN FORMATS GLOSSARY !
!-----------------------------------------------------------------------------!
! %n - newline !
! %m - your log message !
! %p - message priority (FATAL, ERROR, WARN, INFO, DEBUG or custom) !
! %r - millisecs since program started running !
! %% - percent sign in output !
! !
!-----------------------SOME MORE CLUTTER IN YOUR LOG-------------------------!
! %c - name of your category (logger), %c{2} will outputs last two components !
! %t - name of current thread !
! %x - Nested Diagnostic Context (NDC) (you supply it!) !
! !
!-------------------------SLOW PERFORMANCE FORMATS----------------------------!
! %d - date and time, also %d{ISO8601}, %d{DATE}, %d{ABSOLUTE}, !
! %d{HH:mm:ss,SSS}, %d{dd MMM yyyy HH:mm:ss,SSS} and so on !
! %l - Shortcut for %F%L%C%M !
! %F - Java source file name !
! %L - Java source line number !
! %C - Java class name, %C{1} will output the last one component !
! %M - Java method name !
! !
!------------------------------FORMAT MODIFIERS-------------------------------!
! %-any_letter_above - Left-justify in min. width (default is right-justify) !
! %20any_letter_above - 20 char. min. width (pad with spaces if reqd.) !
! %.30any_letter_above - 30 char. max. width (truncate beginning if reqd.) !
! %-10.10r - Example. Left-justify time elapsed within 10-wide field. !
! Truncate from beginning if wider than 10 characters. !
!-----------------------------------------------------------------------------!
]]>