yamicha.com's Blog - Presented by yamicha.com
Blog yamicha.com's Blog - 2017/11 の記事
[1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19] [20] [21] [22] [23] [24] [25] [26] [27] [28] [29] [30]

yamicha.com's Blog
 諸事情により、現在更新休止中。ご了承ください。もし今後ブログを再開することがあるとすれば、その際にはこのブログスクリプトではなく、新しく開発したものによるかもしれません。
 当ブログ管理者についてはこちらをご参照。
開発魔法(737)
社会問題(733)
お知らせ(11)
質問・バトン回答(15)
ゲスト出演(8)
経済・知的財産(150)
ゲーム開発(182)
[Ada] 勝手に補足
- Note
- 金配りの次の一手


- Endless Ultimate Diary
- 銃世界

漢字バトン
- うるる雑記帳
- 漢字接力棒

ツキアイゲノムバトン
- ブログ@うにうに画像倉庫
- あぶ内閣

縺イ縺セ縺、縺カ縺励ヰ繝医Φ
- 月夜のボヤキ
- 騎士サーラバトン
パスワードを使う
名無し (2012/02/27)


開発者解放裁判
yamicha.com (2010/03/14)
Winnyに関しては、私も「純白」とまでは考えておりませんし、使用し..

開発者解放裁判
通りすがり (2010/03/08)
winnyに関しては「ダウンロードソフト板」なんてところを拠点に開発..

新型インフルエンザの恐怖
いげ太 (2009/11/03)
> C#などの「int Some(int , int)」は、F#では「(int * int) ->..

時効に関する思考
yamicha.com (2009/08/31)
>いげ太さんコメントありがとうございます。手元にドキュメントが少..
Homepage
Blog Top
Normal View
List View
Search
Calendar
Comment List
Trackback List
Blog RSS
Send Trackback
Phone Mode
Administrator
yamicha.com
Blog
るううるる。
Source
法令データ提供システム
FindLaw
Development
Java2 Platform SE 6
Java EE 6 API
MySQL Developer Zone
PHP Reference
MSDN Library
Ada Reference Manual
Objective Caml
Python Documentation
Erlang
Prolog Documents
おおむね裁判
2007/05/26(Sat)21:40:01
 どういうわけか、このところ裁判系の話題が多いです。
 まずは少年法改正。これまで14歳以上が少年院送致でしたが、今回「おおむね12歳」に改められました。この「おおむね」がポイントで、法律上は意味を持たない言葉です。
 法律上で何らかのあいまいな言葉を用いる場合、それには定義がなされるのが普通です。例えば道路交通法では「直前」を「30メートル手前」としており、「交差点の直前で合図」とは「交差点の30メートル手前で合図」と読み替えることができます。また、「こどもがひとりで歩いている」とは、子どもが物理的に1人しかいない状態なのではなく、「近くにそれを監督する保護者がいない」という意味です。すなわち、子どもが実に30人いたとしても、保護者がいなければ「こどもがひとりで歩いている」のです。
 その他、「○○等」といった表現も良く見かけますが、「等」の内容があいまいでは後で無用なトラブルを招くため、最初に「AやB、C(以下、A等と記述する)」のように明確化されている場合が少なからずあります。こうした点が明確でなければ、「灰色」の事例については裁判で争われた末、その後は判例に基づいて判断される(判例主義)ことが多いようです。
 ところで、法律はこの辺りの考え方が極めて厄介なのですが、上記の例における「A等」とは「A及びそれに類するもの」ではありません。あくまで「AやB、C」へのリファレンスなのです。要するに「A等」は単なる道しるべなのですから、言葉自体には何の意味もありません。道しるべの名前は「A等」でも「ア-2」でも「X」でも何でも構わないのですが、全く脈絡のない名前では混乱を招くため、「A等」としているに過ぎません。これを世間一般の「A等」という言葉の定義で考えるから意味が分からなくなります。
 しかし、改正少年法の「おおむね」には明確な定義がないようです。明確な定義がないということは、「おおむね12歳」を「0歳〜12歳程度」と解釈し、0歳児を少年院に入れたとしても、ただちに違法ではないことになります。さすがに0歳児が作為的に犯罪を犯すことはないでしょうが、「少年院は16歳で十分だろう」と考えたところで神戸の連続通り魔・タンク山事件、「それなら14歳にすれば」と改正されたところで突き落とし事件と同級生殺害事件です。今後「おおむね」がどこまでの年齢と解釈されるかなど、誰にも分かりません
 後は14歳未満への警察の調査権限拡大(強制調査及び任意調査の権限付与)ですか。これで警察が14歳未満の犯罪にも深く食い込めるようになりますが、これ自体は必ずしも悪いことではありません。しかし、権力の乱用がなされないために十分な対策が必要であることは言うまでもありません。
 自白が存在するにもかかわらず、無罪判決が出る例は少なからず存在しています。「灰色無罪」の他、新証拠が明らかに被告人を犯人でないと証明していたり、実際に真犯人が捕まったりと、被告人が犯人ではあり得ない「潔白無罪」も多々あります。脅迫や拷問まがいの取り調べで無理やり自白を取り、それを使って強引に起訴したがために起こった冤罪です。
 こうした取り調べを受けることで、無実の大人でさえ自白してしまうのに、果たして無実の少年が自白をせずにいられるでしょうか。また、少年は大人よりも法知識やその他様々な知識に乏しく、それを良いことに警察側が甘い言葉を使って自白させるかもしれません。大人の場合でも、「自白しなければ死刑確実だが、自白すれば死刑にならずに済む」などとそそのかされる例があるといいますが、時として大人でも策略にハマってしまうのに、少年がそれを見抜くことができるでしょうか。「罪を認めれば家に帰れる」などと言われれば、それが大人から見れば明らかなウソであったとしても、少年は自白してしまうのではないでしょうか。
 警察の調査権限を強化するのであれば、セットで少年を保護する方策も講じなければなりません。警察の誘導で冤罪にされた挙句、少年院に収容され、ろくに弁解のチャンスも与えられないのでは、正義も公正もあったものではありません。しかもマスコミはそれを非常に大きく騒ぎ立て、多くの人が少年を真犯人と思い込み、時として誹謗中傷まで飛び交うのです。
 不適切な調査権限の行使から少年を保護するため、取り調べの録画などの対策は必要でしょう。言うまでもありませんが、録画は少年に限らず一般の取り調べに対しても絶対に導入が必要です。
 ところでその「録画」ですが、先に日本で初めて取り調べ映像が刑事裁判で証拠採用されました。自白の任意性を証明するために検察が証拠として提出したようです。裁判員制度の上では自白の信頼性を不毛に争うのは難しいため、ビデオによって自白の信頼性をはっきりするという思惑が根底にあるようですが、多少は前進といったところでしょうか。
 ただ、ビデオによって「自白主義」が復活しないかが不安ではあります。確かにビデオで「私がやりました」と言い切られていれば、裁判で自白の信頼性が上がるのは間違いありません。しかし、その人は暗示を受けやすい人かも知れませんし、事前に警察・検察にそそのかされているかもしれません。ビデオはあくまで「拷問的取り調べ」や「言った言わないの騒ぎ」を回避するものと考えた方が良いでしょう。
 その裁判員制度ですが、これに絡んで「被告へのスーツ貸与制度」が検討されているそうです。現在、刑務所には武器または自殺の道具となるようなものを持ち込むことが制限されており、ネクタイなどを持ち込むのは困難です。結果、裁判所にはフォーマルではない格好で出ることになり、正装をした周囲の関係者と比べても、被告人の格好が浮いてしまい、裁判員の心象を悪くするというのです。
 実現に向けてさほど問題があるわけでもなさそうですし、おおむね良い制度ではないでしょうか。被告が無罪を主張しているにもかかわらず、服装のラフさのせいで裁判員の心象を損ない、偏見の上で証拠などを検討された挙句、有罪にされるのではたまったものではありません。しかも服装がラフなのは「不真面目」だからではなく「正装は不可能だから」なのですから。
 しかし、この辺りがまた日本らしいといいましょうか。こともあろうに裁判ですら人を服装で判断するわけですか。そのうち「イケメンの無罪率が不当に高い」などとして裁判員制度が廃止にならなければ良いですが。実際、メタボリックだのブランドだの、日本人の「外見思想」にはある意味恐ろしいものがあります。飾り付けるヒマがあったら人格を磨けば良いものを。無論、飾り付けるのは個人の自由ですが、そういう意識を裁判に反映されては困るのです。
 ただでさえ最近は真相を見抜くだけの知識を持った人が減っており、インターネットでは匿名性を良いことに、上っ面で意味不明の誹謗中傷が飛び交ったりしているというのに。正直、日本で裁判員制度がどこまで定着するのかは今のところ未知数でしょう。「イケメン無罪」はもとより、被疑者を犯人扱いするマスコミ報道やそれを信じ込む多くの人々を見る限り、「無罪推定の原則」を守れる人が多いようにも感じられません。

 光市の事件の差し戻し控訴審が始まりました。この事件の判決には私も1審の時から注目していますし、他にも注目しておられる方は多いでしょう。地裁で無期、高裁でも無期、最高裁では「事情なければ死刑が適当」として差し戻され、これが4度目です。果たしてどのような判決になるのでしょうか。
 それにしても、遺族の本村氏はこれで8年間も待たされているわけですか。しかも今回の差し戻しで4度目の裁判とは。その苦痛たるや察するに余りあります。検察側が一貫して死刑を訴える一方、弁護側は、被告人の側は犯行当時18歳1ヶ月であり、死刑を適用できる18歳ギリギリである点、精神的に未熟であった点などを指摘し、死刑は適当でないと訴えています。18歳1ヶ月なら死刑適用可能で17歳11ヶ月なら死刑は不可能、という定義は何か奇妙な気もしますが、まさか死刑を「おおむね18歳以上」とするわけにもいきませんし、どうしてもどこかで線引きをする必要があり、その結果として出てきた哲学問題が今回の裁判なのでしょう。犯行の様態を考えても、死刑か無期懲役かはギリギリのラインでしょうが、こちらも「おおむね死刑」などはありませんから、どうしてもいずれかの判決を出さなければなりません。
 ただ、この事件についての私の個人的見解は「死刑やむなし」です。弁護側は「傷害致死」を主張しているようですが、証言能力もなければ罪もなく、抵抗もできない赤ん坊を殺害するなどいかなる理由があっても不要なはずであり、明らかな殺人で死刑に相当します。しかし、「被告は18歳の上に精神的に未熟」ということは、25歳なら迷わず死刑になっていたのでしょうか。これまでの例からしても、かなり死刑に近い犯行であることは間違いなさそうですが。
 死刑制度そのものについての異論もあるでしょうが、少なくとも日本は現状で死刑制度を持っており、被告人にはそれを適用することができます。死刑そのものの是非については死刑制度見直しの際に論じるべきことです。今回の裁判では冤罪の事実なども争われておらず、犯行の様態やこれまでの判例を考えれば、日本に存在する様々な刑罰の中で今回最も適用すべきものは死刑である、というのが私の結論です。
 しかし、この凄惨な事件を「例」にするのは大変申し訳ないのですが、このような事件の時こそ「無罪推定の原則」などを十分頭に置いておかなくてはなりません。この事件では犯罪の事実については争われていませんが、時に事実そのものが争われる場合もあります。残虐な犯罪において市民が被疑者に怒りを持つのは当然の感情ですが、もし怒りを持つべき相手が別にいるとしたら。あなたが「こんな奴は死刑にすべき」と怒りを向ける相手は「河野氏」かもしれないのです。裁判員制度や市民感覚が叫ばれる現在、これは非常に重要なことです。

 EJB Timer問題で悩み続けて[0-9]日。一体何がどうなっているのでしょうか。以下に示すのは、私とEJB Timerの激戦を示すドキュメントです。
 チュートリアルによれば、EJB 3.0ではEJB Timerが非常に簡単に使用できます(ただしStatelessもしくはMessage-Driven Beanのみ)。TimerService型のフィールドに@Resourceをつけるか、あるいはEJBContextからTimerServiceを取得すれば良いのです。後はそれに対してcreateTimerなどを呼び出せば、指定時間経過後に@Timeoutでアノテートしたメソッドが呼ばれることになります。
 しかし、これが上手くいかないのです。実際にEJBを作成してデプロイしてみると、@Resourceアノテーション自体は有効らしいのですが、TimerServiceを@ResourceアノテートしているとEJB作成時にエラーが発生します。「javax.ejb.CreateException」です。ログを見てみると、どうやら正しくDIが行われていないらしいことが分かります。
 それならとEJBContextからTimerServiceを取得しようとすれば、何とその時点で例外を投げてきます。EJBContextでもDIでも、とにかくTimerServiceを取得しようとするとエラーになるようです。DIの場合は(実行時にTimerServiceが存在することが担保されなければならないため)CreateExceptionなのですが、EJBContextを使う場合はTimerServiceを取得しない限りエラーにはなりません(TimerServiceを使わない限りは正しく動作する)。
 EJB Timerに似たコールバックはMessage-Driven Beanで簡単に作ることができ、EJB Timerは機能限定版のMessage-Driven Beanに近いと考えることができます。ですから、Message-Drivenさえ使えればEJB Timerを使えなくても絶対的に困ることはありませんが、ちょっとした処理にいちいちJMSを使うのは非常に大げさで、余計なオーバーヘッドも生じ、ファクトリを得たりキュー(またはパブリッシャー)を得たりと非常に厄介で面倒なのです。また、事前にJMSリソースをJNDIに登録しなくては使うことさえできません。チューリップの球根を植えるのにブルドーザーを使う必要などありません
 それは建造物を作るならブルドーザーも使うでしょうが、チューリップを植えるならスコップを使いたいところです。単なるタイマーによるコールバックにJMSを使う必要などなく、何とかEJB Timerを使いたいのですが、どうしたものでしょうか。というのがこれまでのあらすじです。
 とはいっても、タイマーが使えない原因は全く分かりません。インストール直後に確かめても動作しなかった、すなわち初期状態ですら動作しないことが分かっているのが唯一のヒントでしょうか。とにかくしらみつぶしにでも調べるしかないでしょう。しかし、何が原因か分からないのでは検索することもできません。
 あれこれ試して再起動を繰り返しているうちに、どうやらAppServerの起動時に「__ejb_container_timer_app」なるEJBが起動失敗していることが分かりました。Adminコンソールからはその影も形も見ることができないのですが、ログにはしっかり残っていました。このEJBが何なのかは分かりませんが、EJB Timerに関係している可能性はあります。
 起動に失敗している理由は例外のスタックを追えば分かります。といっても、AppServerは山のように例外を出してくるため、これを突き止めるだけでも一苦労なのですが。どうやら例外は「ClassNotFoundException」らしく、「TimerMigrationBean649625130_ConcreteImpl」なる意味不明な名前のクラスが見つからないらしいのです。この変な番号といい、訳の分からない名前といい、一体何なのでしょうか。
 Google検索してみたところ、どうやらこの奇妙な名前のクラスは私の環境以外にも存在するらしいのです。しかし、このような珍妙な名前の検索結果が山のように見つかるわけもなく、何とか引っかかったいくつかの検索結果の中にもヒントになりそうな文言は見つかりません。名前を見る限り、EJB Timerに関係がある可能性は高いのですが。
 このクラスの正体はつかめませんし、ClassNotFoundExceptionであるからにはAppServer内には存在していないのでしょう。しかし、「__ejb_container_timer_app」が起動失敗しているのは気になります。しかも失敗している理由が「TimerMigrationBean649625130_ConcreteImpl」と、これまたEJB Timerに関係しそうな名前ではありませんか。
 まさか、このEJBがTimerを巻き込んで起動に失敗しているせいで、EJBでタイマー自体が使えなくなっているのでしょうか。それなら、このEJBが起動時にロードされなければ問題は解決するのでしょうか。しかし、このEJBはAdminコンソール上には表示されません。すなわち、AdminコンソールでこのEJBを有効にするかを決めることはできません。確か9.0のAdminコンソールには表示されていた気がするのですが、9.1からは表示されなくなっているようです。
 こうなればdomain.xmlを扱うしかありません。domain.xmlはdomains\domain_name\configに格納されています。これを開き、「__ejb_container_timer_app」らしきノードを見つけた後、enabledアトリビュートをfalseにするだけです。これでAppServerの起動時にこのEJBがロードされることはなくなるでしょう。
 実際に試したところ、ログにエラーが書き込まれることはなくなりました。どうやらClassNotFoundExceptionは回避できたようです。しかし、やはりTimerを動作させることはできないのです。「__ejb_container_timer_app」を無効化し、エラーを回避したにもかかわらず、なぜTimerは動作しないのでしょうか。すなわち、EJB Timerが使えない理由は「__ejb_container_timer_appがエラーを起こすから」ではなく、「__ejb_container_timer_appが起動できないから」である可能性が高いものと考えられます。言い換えれば、このEJBはEJB Timerを管理するためのものであると考えられるのです。
 それならenabledアトリビュートをfalseにしておくのはまずいでしょう。また、通常のクラスであればどこかのJARに入っている可能性もありますが、これがEJBであるからには実体があるはずであり、その実体を探れば問題の原因がつかめるかもしれません。ディレクトリデプロイ以外の方法でデプロイされたEJBはapplicationsディレクトリに格納されますので、早速その中を探してみることにしました。
 ありがたいことに、「__ejb_container_timer_app」はすぐに見つかりました(j2ee-appsディレクトリ内)。しかし、その中にあったのはすべてデプロイメントディスクリプタやそれに類する設定ファイルのようなものであり、「実体」らしきものは全く見当たりません。これでは何の解決にもなりません。
 しかし、少なくともapplicationsのサブディレクトリ内には__ejb_container_timer_appが存在するのです。他のEJB関連ディレクトリも調べてみなければ分かりません。そこで次に調べてみたのが「generated」でした。ここには(ディレクトリデプロイされた場合を含む)自動生成物が格納されるようです。ディレクトリデプロイしたEJBの名前のディレクトリを見てみると、Persistenceのテーブル生成及び削除用のクエリが格納されていました。ちなみに自動生成されたデプロイメントディスクリプタはxmlディレクトリに格納されます。
 それはともかく、generatedのサブディレクトリを調べてみたところ、こちらにも__ejb_container_timer_appディレクトリは存在しました。そして、中身を調べてみたところ、実際に実体らしきソースが存在したのです。しかも「TimerMigrationBean649625130_ConcreteImpl.java」という名前のソースまで存在するではありませんか。とはいっても、何が悪いのかすらはっきりしていない以上、これらのソースを修正しようなどとは無理な話です。せっかく実体を見つけたというのに、手を出すことができないのでしょうか。
 そういえば、以前に使っていたAppServer 9.0では__ejb_container_timer_appが正しく動作していたような気がします。実際にEJB Timerを使うプログラムを組んではいないため、本当に動作していたのかは分かりませんが、少なくともAdminコンソールには表示されていた記憶がありますので、起動に失敗していたということはなさそうです。
 そこで、9.0の同じディレクトリを開き、内容物を比較してみることにしました。その結果、9.0と9.1ではファイルの数が違うことが分かりました。9.1の方がソースファイルが増えているのです。しかし、違いはそれだけではなく、9.0のディレクトリにはソースファイルに対応したclassファイルがあるにもかかわらず、9.1にはソースと設定ファイルらしきものしか存在しないのです。
 まさかClassNotFoundExceptionの正体はコレでしょうか。クラスローダがこれらのクラスを読みに行くにもかかわらず、実際にはソースがコンパイルされていなければ、確かにクラスは見つからないでしょう。
 そこで、私はこれらのファイルをコンパイルしてみることにしました。ところが、エラーが100個出てコンパイルを停止してしまいました。そのほとんどが「シンボルを見つけられません」エラーです。
 こうなれば仕方ありません。片っ端からJARファイルをクラスパスに指定してコンパイルしてみることにしました。具体的には以下のファイルを指定することでコンパイルできました。以下のファイルのうち、いくつか余分なものがあるかもしれませんが、最悪でも以下のすべてを指定すればコンパイルは通ります。
(ファイルはいずれも AppServer\lib 内)
javaee.jar
j2ee.jar
appserv-rt.jar
appserv-ee.jar
appserv-cmp.jar
 後はAppServerを起動してみるのみです。
 実際に起動してみたところ、ログにClassNotFoundExceptionは書き出されなくなりました。やはりカンが当たったようです。しかし、代わりにSQLExceptionが書き出されるようになってしまったのです。何でも「EJB__TIMER__TBLが見つからない」そうで。そのようなことを言われても困るのですが。
 仕方がないので、このテーブル名らしき名前をそのまま検索にかけてみました。めぼしい情報は全く見つかりませんでしたが、glassfishプロジェクト内から次のようなファイルが見つかりました。
create table EJB__TIMER__TBL (
CREATIONTIMERAW BIGINT NOT NULL,
BLOB  BLOB(2G), 
TIMERID              VARCHAR(255) NOT NULL, 
CONTAINERID          BIGINT       NOT NULL,
OWNERID              VARCHAR(255),
STATE                INTEGER      NOT NULL,
PKHASHCODE           INTEGER      NOT NULL,
INTERVALDURATION     BIGINT       NOT NULL,
INITIALEXPIRATIONRAW BIGINT       NOT NULL,
LASTEXPIRATIONRAW    BIGINT       NOT NULL,
CONSTRAINT PK_EJB__TIMER__TBL PRIMARY KEY (TIMERID)
)
 なるほど、そういうことですか。
 これでピンと来た私は、EJB Timerでデフォルト使用されるjdbc/__TimerPoolに上記テーブルを作成、しようとも考えたのですが、手元にDerbyにアクセスできるクライアントがありません。適当なJSPでも作成し、そこからjdbc/__TimerPoolのDataSourceをルックアップし、それを使ってテーブルを登録しても良いのですが、それをする必要はあるのでしょうか。
 そこで、Adminコンソールの「Configuration/EJB Container」ノードを開き、そこから「EJB Timer Service」タブを開き、「Timer Datasource」欄にMySQL XADataSourceのJNDI名を指定してやりました(私の場合は「jdbc/MySQLXA」)。つまり、EJB Timerの管理にMySQLを使ってやろうという魂胆です。
 後はMySQLのクライアントからクエリを打つのみです。ただし、上記クエリをそのまま打ってもエラーが出ます。私がMySQL用に編集した次のクエリなら大丈夫です。
create table EJB__TIMER__TBL (
CREATIONTIMERAW BIGINT NOT NULL,
`BLOB`  MEDIUMBLOB, 
TIMERID              VARCHAR(255) NOT NULL, 
CONTAINERID          BIGINT       NOT NULL,
OWNERID              VARCHAR(255),
STATE                INTEGER      NOT NULL,
PKHASHCODE           INTEGER      NOT NULL,
INTERVALDURATION     BIGINT       NOT NULL,
INITIALEXPIRATIONRAW BIGINT       NOT NULL,
LASTEXPIRATIONRAW    BIGINT       NOT NULL,
CONSTRAINT PK_EJB__TIMER__TBL PRIMARY KEY (TIMERID)
);
 以上の設定を行ってからAppServerを再起動したところ、無事に__ejb_container_timer_appを起動できるようになりました。後はテストしてみるのみです。
 作成したEJBは以下のような構造なのですが、XMLの記載は省きます。application.xmlはこれまでのものを少々変更するだけですし、web.xmlはそのまま流用でも何とでもなります。さらに、EAR化してデプロイすればどちらのXMLも不要です。
/timeout
 /timeout_jar
  /com
   /yamicha
    /timeout
     @Remote TimeoutTest.java
     @Stateless TimeoutTestBean.java
 /timeout_war
  /WEB-INF
   web.xml(*)
  timeout.jsp
 /META-INF
  application.xml(*)
(*)今回は中身の記載を省きます
注:EAR 化してデプロイすれば、これらの存在自体が不要です
 完全にテスト用の構成です。EJBアプリケーションをわざわざ書きたくなければ、@Local @Statelessアノテートしたクラスをautodeployに放り込んでデプロイし、適当なJSPでルックアップしてObject型に格納、リフレクトでメソッドを呼び出してみても良いでしょう。私自身は未確認ですが、@LocalされたEJBはPortableRemoteObject.narrow()する必要がなく、そのままキャストして使えるそうです。これをObject型で受け取れば、おそらくリフレクト可能でしょう。@Remoteならnarrow()する必要があり、この操作にビジネスインタフェースが必要ですから、どうしても少々大げさになります。
// timeout_jar\com\yamicha\timeout\TimeoutTest.java
package com.yamicha.timeout;

import javax.annotation.*;
import javax.ejb.*;
import java.sql.*;
import javax.sql.*;

@Remote	public interface TimeoutTest{
	void startTimer();
	void timeout(Timer t);
	String test();
}

// timeout_jar\com\yamicha\timeout\TimeoutTestBean.java
package com.yamicha.timeout;

import javax.annotation.*;
import javax.ejb.*;
import java.sql.*;
import javax.sql.*;

@Stateless(name="TimeoutTest" , mappedName="ejb/TimeoutTest") 
	public class TimeoutTestBean 
	implements TimeoutTest , java.io.Serializable{
	@Resource private TimerService ts;
	@Resource(name="jdbc/MySQL") private DataSource ds;

	public void startTimer(){
		try{
			Connection c = ds.getConnection();
			c.setAutoCommit(false);
			PreparedStatement ps = c.prepareStatement(
"INSERT INTO timeout VALUES(NULL , NOW() , 'Service starting...')");
			ps.executeUpdate();
			c.commit();
			c.close();
		}catch(SQLException e){
		}

		long interval = 30*1000;	// ミリ秒で指定
		Timer timer = ts.createTimer(
			interval , interval , "refresh");

		try{
			Connection c = ds.getConnection();
			c.setAutoCommit(false);
			PreparedStatement ps = c.prepareStatement(
"INSERT INTO timeout VALUES(NULL , NOW() , 'Service started...')");
			ps.executeUpdate();
			c.commit();
			c.close();
		}catch(SQLException e){
		}
	}
	@Timeout public void timeout(Timer t){
		try{
			Connection c = ds.getConnection();
			c.setAutoCommit(false);
			PreparedStatement ps = c.prepareStatement(
			"INSERT INTO timeout VALUES(NULL , NOW() , 'Call')");
			ps.executeUpdate();
			c.commit();
			c.close();
		}catch(SQLException e){
		}
	}
	// Bean が正しく生成されたかを確かめるためのテストメソッド
	public String test(){
		return "Hello World!";
	}
}

// timeout_war\timeout.jsp
<%@ page import="javax.servlet.http.* , javax.annotation.* , 
javax.ejb.* , javax.naming.* , java.rmi.* , javax.rmi.* , 
java.io.* , java.util.* , com.yamicha.timeout.*" 
contentType="text/plain;charset=UTF-8" pageEncoding="Shift_JIS" %>

<%
Context ct = new InitialContext();
Object ejb = ct.lookup("ejb/TimeoutTest");
TimeoutTest tt = (TimeoutTest)PortableRemoteObject.narrow(
	ejb , TimeoutTest.class);

tt.startTimer();
out.println(tt.test());
%>
 テスト用のテーブルは次のクエリで作成します。
CREATE TABLE timeout(number INT AUTO_INCREMENT , dated DATETIME , 
note VARCHAR(32) , PRIMARY KEY(number));
 後はこのJSPを実行すれば、EJB Timerの呼び出しがセットされ、30秒ごとに新しいデータが登録されていきます。テストらしい適当なプログラムにつき、途中で止めることはできませんので、動作を確認できたらアンデプロイしてください。
 これでようやくEJB Timerが使えるようになりました。Message-Driven Beanまで扱っている現状においては、EJB Timerでは少々パンチ不足でしょうが、何か作ってみたいものです。
カテゴリ [開発魔法][社会問題] [トラックバック 0][コメント 2]
<- 前の記事を参照 次の記事を参照 ->

Comments(2)
yamicha.com - 2007/05/27(Sun)10:38:18
>H.Mさん
「ジャマイカ」とは何ですか?私はこの記事でFTA交渉の話など書いていなかったはずですが。
適当な言葉遣いをして欲しいという再三のご注意にもかかわらず、「じゃないか」という表現を「ジャマイカ」などという「俗語」で表しているのでしょうか。
攻撃の意図がおありなのか、ご注意差し上げたのをお分かりいただけなかったのかは分かりませんが。
無論、これまで再三ご注意差し上げているのには理由があります。
人間の書くものですから誤認もありましょうが、当ブログは「ブログ」というメディアの信頼性を最大限尊重しようと努力しています。署名記事と考えていただいても構いません。
また、これだけ内容がハードにもかかわらず、少ないながらも閲覧者の方がいらっしゃいますので、そうした方にはこの路線が支持されているのではないかと考えています。
しかし、コメント欄などで不正確あるいは極端なまでに主観に基づいたデータが発信され、それが日常化してしまえば、ブログの信頼性自体に疑問符がつきかねません。
言葉遣いも同様で、いくらまじめなことを書いていても、例えば「私はこのように思います」と書くのと「ゎたしはこのょぅ|こぉもぃます」と書くのでは、信頼性が変わってきます。他の利用者の方に不快感を与えないためにも、最低限マナーのある言葉遣いをお願いしています。
以前、イラク人質を証拠もなく自作自演と中傷した末、そのような事実がないと分かっても訂正も謝罪もなかったブログをいくつか見つけましたが、当ブログをそのようなものにするわけにはいきません。
アリの巣から堤も崩れると申しますが、どこかで線引きをせずになし崩し的にぞんざいなコメントを受け入れてしまうと、それが日常化し、多くのコメント投稿者、最終的には閲覧者までそうした人々で占められるようになる恐れがあります。そうすれば、そのブログの信頼性は地に落ちます。
当ブログを新聞社の社説並み、またはそれ以下の品位にするわけにはいかないのです。情報の信頼性を担保するためには、コメントは歓迎されるべきものですが、前提となるマナーを守った上、少なくとも極端な主観によらないコメントでなくては意味がありません。ご理解願います。
申し訳ございませんが、しばらく冷却期間を置かせていただきます。その後については、エチケットとマナーを十分に守られる限り、コメントは歓迎されます。
PS.皆々様へ。そんなこんなでブログ実装の改変が必要になり、仕事が増えてしまいました。久しぶりのPerlです。とはいっても、このブログでも2日付の記事でPerlを書いていたりするのですが。
次のブログが遅れてもご容赦くださいませ。これも修行のうち、私の糧となってくれましょう。

H.M - 2007/05/26(Sat)23:45:14
日本がやろうとしてる裁判員制度が「“有罪か無罪か”だけではなく“有罪の際の裁量”までの決定権がある」のがそもそもアウトじゃないかと…
法の番人が役立たずに成ってきている中、推定無罪を知らない人間に裁量なんか決めさせたら無茶苦茶な事になるんジャマイカ?

- Blog by yamicha.com -