JBoss/Seam の@In がOverrideできない

@In
public void setXXX(CCC ccc){...}

のインジェクションを子クラスで
@override
@In(required = false)
public void setXXX(CCC ccc){...}

としてみたが、効果なし？？

Solaris/sparc での64bitJVM

32bit版をまずインストールし、次に64bit版を入れる；
JAVA_HOMEは共通にする；
例） JAVA_HOME => /usr/jdk1.6.2
64bitで動かす時はOptionとして”-d64”を指定
例） JAVA_OPTS="-d64 ....."

Tomcatのオプション

-Xmx などの指定をJAVA_OPTSにしろと指示している情報が多く見られるが、これには問題がある。
１）このOPTSはtomcatに関連する全Javaプロセスに適用されてしまう
２）stopや、statusなどのメモリフラグが意味をなさない場合にも適用されてしまう
３）JMX_AGENTなどのListenPortを使う指定をここで行うとstopなどの場合に競合してしまう

正しくは、CATALINA_OPTSでやる。このOPTSはstartの時だけに効き目があるので、起動するtomcatのプロセスのみに適用したいオプションはここに書くとよい。
　また、catalina.sh と同じ階層に、setenv.sh という名前のファイルを置いておくと自動的に読み込んでくれます。形式はbashの変数指定の形式。
例）
CATALINA_OPTS="$CATALINA_OPTS -Xmx2048m"

Java Swing Event のキャンセル

Event処理の途中で、後続する処理をキャンセルしたい場合は、以下のようにする。

evt.consume();

Java Swing MouseEvent DoubleClick の醜悪

Swingでのダブルクリック判定は、MouseListenerの中で MouseEvent#getClickCount() の数を見て判定するのだが、以下のようにSingleイベントとDoubleイベントの２つが発生する仕様となっている。

1) Event : ClickCount=1
2) Event : ClickCount=2
3) ......

つまり、ダブルかどうかは自分で判定ロジックを作れとのことであり、これだったらClickCountなどあまり無意味と言える。

実装例）
　タイマーを仕掛けて N miliSec以内にクリックが連続した場合をDoubleと判定し、そうでない場合はSingleとしてタイマータスクの内部から処理を実行する

Swing 文字列を傾けて描画

参考ページはここ
要は、Font自体にAffinTransformをかけてから描画すること。

Java:ui:役立ちリンク集

Java Swing Tips てんぷらメモ　： Java6を標準とた１画面JWS完備のサンプル集
プログラマメモ2　：開発やIT系のメモ集、Swingのもあり
Java examples (example source code) Organized by topic　：多岐にわたるサンプル集
Java Category. - java.itargs.org　：Q&A集や資料類
Javaの学習ならJavaDrive　：学習資料とサンプル
Swing-Threadの解説　：Sunの解説
SMG-Java トルぶるシューティング(Javaのトラブルシューティングはこちら)
Easy Learn ava: Programming Articles, Excmples and Tips　：学習教材とサンプル

javax.swing Component preferredSize の罠

Swingでの部品のサイズは、sizeでも、maximumSizeでも、minimumSizeでもなく、preferredSizeが使われるため、ここを設定することが多いのだが、サイズが可変になる場合にはむしろ「null」にしておいた方が吉である。

そもそも、Swingでは、サイズはLayoutManagerの管理下にあり、上記のサイズ指定は参考値という扱いのようだ。とはいっても最大の参考値は「preferredSize」であり、初期表示はこの値が使用される。

■状況：
JPanelにBorderLayoutを設定し、NorthにJToolBarを配置、Centerにはイベントに応じて異なるJPanelが挿入され、サイズも動的に変化するという画面を開発していた。始めはJDialogを継承したクラスでうまく動作したものをJPanelに変更し、別に作成したJFrameに埋め込んで使用する形に変更したら、内部の部品変更でサイズが変わらなくなってしまった。

■調査：
最初は、pack()やvalidate(),invalidate()などの呼び方や対象が間違っているのではと、何種類もコードを追加、削除をしてみたが一向に変化がなかった。ネットや資料を見ているうちに、そういえばサイズは「preferredSize」を見ていて、これが固定値だと、、、ということでnullにしてみたらという考えに思い至った。

■判明：
nullに指定すると、見事にサイズが内部部品に応じて変化するようになった。もともとJDialogで試していた時にはgetContentPane()で取得できるContainerのpreferredSizeにはnullが入っていたいようで、内部に応じて変化する場合にはこの指定が正しいようだ。

■教訓：
前提を疑え

Tuning for Java on Solaris

SolarisデでJava(Seasar2)を動かすと10倍くらい時間がかかるとの
ことで、その調査。

#!/bin/bash
export JAVA_HOME=/usr/jdk/instances/jdk1.6.0/jre
export ORACLE_BASE=/opt/oracle/database
export ORACLE_HOME=$ORACLE_BASE/product/10.2.0
export LANG=ja_JP.UTF-8
export NLS_LANG=japanese_japan.AL32UTF8
export PATH=/bin:/usr/bin:/usr/ccs/bin:.:/usr/sbin:${ORACLE_HOME}/bin:${JAVA_HOME}/bin
#${HOME}/appserver/bin

export ORACLE_TERM= vt100
export LD_LIBRARY_PATH=/usr/lib
export CONNECTION_FACTORY_PROPERTIES=QueueManager=PlaceAgent01,HostName=*.*.*.*,Port=1616,TransportType=1,CCSID=943

export COMET_HOME=/sbclocal/comet/services
export BAT_HOME=/sbclocal/comet/services/batch
export ORACLE_COMET_USER=UBSCMT02
export ORACLE_COMET_PASSWORD=UBSCMT02
export ORACLE_URL=jdbc:oracle:thin:@*.*.*.*:1521:COMET3
export ORACLE_UBS_USER=UBSCFIF02
export ORACLE_UBS_PASSWORD=******

#java -client -jar Batch-Deb.jar
#$JAVA_HOME/bin/java -client -Xms512m -Xmn256m -Xmx512m -XX:ThreadStackSize=128 -XX:PermSize=64m -XX:MaxPermSize=128m -XX:+UseCompilerSafepoints -XX:+UseOnStackReplacement -Xprof -Xbatch -verbose:gc -jar Batch-Deb.jar

#$JAVA_HOME/bin/java -client -Xms256m -Xmx512m -Xprof -jar Batch-Deb.jar

Ejb On GlassFish 続き

GlassFishのACCでのLoad-Balance/Fail-Overに関して、SUNのForumに質問して分かったこと。
１）クラスタ内のEJBに対するLB/FOの設定はORBの機能
２）GFのORMは、DynamicにLBする機能はなく、初期接続時のLBのみである
つまり、InitalContext を作成して、Lookupした時点でLBされるのであり、それ以後はおなじクラスタメンバにアクセスすることになる。JBOSSやWAS、WebLogicでは、Optionが必要な場合もあるが、複数の方式のLBをサポートしている。たとえば以下のようなもの。
接続時にLB
毎回LB
トランザクションごとにLB
UDS/Forteでは、最初から上記の方式をサポートしていたことを考えると、GFのORBは退化してしまっているように感じる。ただし、EJBの世界ではUDSのようなRouterとなるプロセスやスレッドを持たないため、ベンダー毎の独自拡張となっているようだ。

１つのJVMで異なるライブラリを使用する環境を使う

JBOSSのアプリケーション内から、GlassFishのクライアントコンテナを使用するようなこと。
J2EE関連のライブラリ(JAR)などが競合しそうで、そのままでは使用できそうもない。

アイデア１） GlassFish環境でRMIサーバを立ち上げてRMIベースで連携
そもそも、GlassFishを使用するのはEJBを使うためなので、
RMI->EJB では、ごてごてしすぎだしパフォーマンスも悪くなる
EJB(RMI/IIOP)は単なる接続だけなら製品間のInteroperabilityがあるようだが、
　　LoadBalanceやFailOverがからむと、専用のクライアントコンテナが必要になったりする

アイデア２） JavaModeleSystemを使用する：まだドラフト状態

アイデア３）OSGi を利用する：バンドル毎に異なるライブラリを定義できる
　JBOssなどのAppContainerから使用できるかが問題(要調査)

用語：
・Java Module System : 使用するライブラリの集合をモジュールとして定義できる
JSR 277　　JAM形式のファイルにパッケージしてモジュールを分離
　　　　　　　リポジトリを持ち、動作時に使用するものを判断してロード
　RubyGemやPerlCPAMに似たしくみ

・OSGi Open Services Gateway initiative
JSR 291: Dynamic Component Support for Java SE
　　バンドル毎に異なるライブラリを指定してインストールを動的に行える
　　現状ではMinifestベース
　使用している製品　Apache Felix、Knopflerfish、Eclipse Equinox