Jetspeed

<Jetspeed>http://issues.apache.org/jira/browse/JS2-325をあげて、ちゃちゃっと修正。まぁ、いままで、誰もバグをあげてこなかったということは、ほとんどこの辺のAPIは使われないんだろうな。ポータルサーバー名を取得して何かするっていうのも少ないだろうし、現在のところ、Portal API も 1.0 しかないので、チェックしなければならない場面は少ないだろうし。まぁ、サーバー名は MyFacesブリッジで必要になるのだけれども。

<Jetspeed日本語版>最新のビルド方法にあわせる。でも、allBuildの後の手順がいろいろあって面倒なので、allDeployに集約。というわけで、いままでj2:quickStartとして配備していたけど、それをallDeployとすれば、配備完了。Apacheにコミットするのにいちいちディレクトリを移動して、ビルドして・・・、という感じじゃ面倒だし。というわけで、Jetspeed日本語版では、 maven initMavenPlugin allClean allBuild allDeploy を実行すれば、すべてが完了する。作業の手間が増えずにすんで、よかったよかった。

<MyFacesブリッジ>ポータルブリッジにJSFポートレットの質問が出ていた。コミュニティはポータルブリッジでJSFブリッジを保持するか、MyFacesのものを使うべきか決めるべきだという感じのコメントがDLSから出ていた。うーん、MyFacesに入れろというコメントが出そうな気がして、ちょっと提案しにくくなった。MyFaces の方に提案するのは、ポータルブリッジに比べて、ほとんど知らん人たちだから、少々敷居が高い気がするな・・・。しかも、MyFacesに入れちゃうと、自由にコントロールできないのが最大の問題。やっぱり、ポータルブリッジ路線で、うまいもって行き方を考えないと・・・。はて、どうしたものか・・・。

MyFacesブリッジ

<MyFacesブリッジ>更新して、コミットした。プロパティファイルから、インスタンスを作る方法で、コンストラクタにパラメータを渡して初期化するか、コンストラクタでは何もせずにセッターで与えて、initを呼び出すのがいいか、についてどちらがよいかを検討した。一応、この部分に関しては、何度も呼び出されることはないので、どちらが良いパフォーマンスかを検討する必要はないと思う。次に、将来的に受け渡すパラメータが変わったときにどうかを考えると、コンストラクタにパラメータを渡しておくと、既存のものまで変更しないといけない可能性が高い。それにくらべ、セッターで渡して、initとしておけば、受け渡すパラメータが増えても、既存の部分への影響は少ないと思う。というわけで、コンストラクタで何もせず、セッターで与えて、initを採用。一応、変更があったときの影響を最小限に抑えるために、抽象クラスを導入して、パラメータの受け渡しを担当させることにする。あとは、javadocのコメントの整理かな・・・。

MyFacesブリッジ

<MyFacesブリッジ>今日もMyFacesブリッジの修正。どうやって、クラスを取得するのがよいのかを考える。やっぱり、Class.forName()でリソースバンドルにから取得するのがいいかね。一応、Class.forNameの良い使い方などないかを確認するべく、springを眺めてみる。ClassUtilsというのがあるので、それでやっているのかね。細かくは見ていないので、もしかしたら、別なところでもっと良いやり方をしている可能性もあるが、MyFacesブリッジでは普通にClass.forNameを使うことにしよう。クラスローダーも同じクラスのを使えば問題ないと思うから、特に特殊なことをする必要もない気もするし。あとは、動作確認をしていこう。

<Jetspeed>今日は、Ateがブランチに入れていた変更のマージをかけていた。また、ビルド方法が変更になるようなコメントがあったから、確認しないとな・・・。そんで、PortletContext#getServerInfoを修正しないと。一応、今日、MajorVersionとMinorVersionが2.0を返すことを確認。だめじゃん。

<選挙>解散か・・・。いつものことだが、誰に投票すべきか悩むんだよね・・・。誰になっても、対して変わらん気がするから・・・。そもそも議員年金はどうなったんだ・・・。