変奏現実

パソコンやMMORPGのことなどを思いつくまま・・・記載されている会社名・製品名・システム名などは、各社の商標、または登録商標です。

この画面は、簡易表示です

JBoss

JBoss。
Javaのボスみたいな名前だが、
Wikipediaによると
当初はEJBossだったが、商標との権利問題でJBossになったそうだ。
EJBoss か、EJB遅 と読めてしまうな。(大笑
つまり、細々としたレイヤーを作っては悦に浸るエンタープライズ(つまりマヌケ)なSE向けのJava Web Server である。
そうEJBするなら、ネットワークで横のつながりとして使うのが筋だ。
しかしSerice層、Logic層、DAO層、DTO層と上下にEJBを重ねるのがエンタープライズSE達である。
今も(去年も)たった一枚の画面を出すのに、ウンザリするほど待たされているのはそのせいだ。
だが、この無駄に長~い待ち時間こそがエンタープライズの伝統である。
単刀直入に云えば・・・

シャキーーーーンっと素早く起動すると

開発費を値切られてしまう

という身も蓋もない話である。
この辺はもうどうしようも無いのだろう。
何しろ

顧客満足度の第一の世界だからね。(大笑

とは云え、Jbossは他よりは速かったらしいが、Resinの方がずーっと速い、ソースを書き換えてリスタートも楽だった。当初はEJBがサポートされていなかったが、有償のものは付いてたハズだ。ただ、EJBを使うと、初期設定(EJBインジェクションのやり直し)が重いので、営業的な意味しかない。
さて、JBOSSをDLしようとしたらアカウントを作らないといけないらしいのでパス。
 



OpenJDKとjdk7

まずは気まぐれでyumでデフォのJavaをインストしてみる。
# yum install java
Loaded plugins: downloadonly, fastestmirror, priorities, security
Loading mirror speeds from cached hostfile
 * base: www.ftp.ne.jp
 * epel: ftp.kddilabs.jp
 * extras: www.ftp.ne.jp
 * rpmforge: ftp.kddilabs.jp
 * updates: www.ftp.ne.jp
94 packages excluded due to repository priority protections
Setting up Install Process
Resolving Dependencies
–> Running transaction check
—> Package java-1.5.0-gcj.x86_64 0:1.5.0.0-29.1.el6 will be installed
–> Processing Dependency: sinjdoc for package: java-1.5.0-gcj-1.5.0.0-29.1.el6.x86_64
–> Running transaction check
—> Package sinjdoc.x86_64 0:0.5-9.1.el6 will be installed
–> Processing Dependency: java_cup >= 0.10 for package: sinjdoc-0.5-9.1.el6.x86_64
–> Running transaction check
—> Package java_cup.x86_64 1:0.10k-5.el6 will be installed
–> Finished Dependency Resolution
Dependencies Resolved
================================================================================
 Package               Arch          Version                  Repository   Size
================================================================================
Installing:
 java-1.5.0-gcj        x86_64        1.5.0.0-29.1.el6         base        139 k
Installing for dependencies:
 java_cup              x86_64        1:0.10k-5.el6            base        197 k
 sinjdoc               x86_64        0.5-9.1.el6              base        705 k
Transaction Summary
================================================================================
Install       3 Package(s)
Total download size: 1.0 M
Installed size: 3.0 M
Is this ok [y/N]: y
Downloading Packages:
(1/3): java-1.5.0-gcj-1.5.0.0-29.1.el6.x86_64.rpm        | 139 kB     00:00
(2/3): java_cup-0.10k-5.el6.x86_64.rpm                   | 197 kB     00:00
(3/3): sinjdoc-0.5-9.1.el6.x86_64.rpm                    | 705 kB     00:00
——————————————————————————–
Total                                           1.1 MB/s | 1.0 MB     00:00
Running rpm_check_debug
Running Transaction Test
Transaction Test Succeeded
Running Transaction
Warning: RPMDB altered outside of yum.
  Installing : java-1.5.0-gcj-1.5.0.0-29.1.el6.x86_64                       1/3
  Installing : 1:java_cup-0.10k-5.el6.x86_64                                2/3
  Installing : sinjdoc-0.5-9.1.el6.x86_64                                   3/3
  Verifying  : 1:java_cup-0.10k-5.el6.x86_64                                1/3
  Verifying  : sinjdoc-0.5-9.1.el6.x86_64                                   2/3
  Verifying  : java-1.5.0-gcj-1.5.0.0-29.1.el6.x86_64                       3/3
Installed:
  java-1.5.0-gcj.x86_64 0:1.5.0.0-29.1.el6
Dependency Installed:
  java_cup.x86_64 1:0.10k-5.el6           sinjdoc.x86_64 0:0.5-9.1.el6
Complete!
# java -version
java version “1.5.0”
gij (GNU libgcj) version 4.4.7 20120313 (Red Hat 4.4.7-3)
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
もし
# java -version
-bash: /usr/bin/java: そのようなファイルやディレクトリはありません
と冷たくアシラワレたら、
# alternatives –config java
で見てみよう。
多分、過去の残骸が残っているせいだ。間違いは正してあげよう。
 
JDK7を入れてみる。
OracleのページからDL。
鯖にWinFTPで転送。
# rpm -ivh jdk-7u40-linux-x64.rpm
準備中…                ########################################### [100%]
   1:jdk                    ########################################### [100%]
Unpacking JAR files…
        rt.jar…
        jsse.jar…
        charsets.jar…
        tools.jar…
        localedata.jar…
        jfxrt.jar…
# java -version
java version “1.5.0”
gij (GNU libgcj) version 4.4.7 20120313 (Red Hat 4.4.7-3)

Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
どうやら切り替えないとダメらしい。
# ls -l /usr/bin/java*
lrwxrwxrwx 1 root root 22 10月 11 00:12 2013 /usr/bin/java -> /etc/alternatives/java
lrwxrwxrwx 1 root root 27 10月 11 00:15 2013 /usr/bin/javac -> /usr/java/default/bin/javac
lrwxrwxrwx 1 root root 29 10月 11 00:15 2013 /usr/bin/javadoc -> /usr/java/default/bin/javadoc
lrwxrwxrwx 1 root root 28 10月 11 00:15 2013 /usr/bin/javaws -> /usr/java/default/bin/javaws

やはり残骸が残っている。
# alternatives –install /usr/bin/java java /usr/java/default/bin/java 17040
でjdk7を登録して
#  alternatives –config java
2 プログラムがあり ‘java’ を提供します。
  選択       コマンド
———————————————–
*  1           /usr/java/default/bin/java
 + 2           /usr/lib/jvm/jre-1.5.0-gcj/bin/java
Enter を押して現在の選択 [+] を保持するか、選択番号を入力します: 1
とか出るだろう。
# java -version
java version “1.7.0_40”
Java(TM) SE Runtime Environment (build 1.7.0_40-b43)
Java HotSpot(TM) 64-Bit Server VM (build 24.0-b56, mixed mode)
これでいいはず。
# alternatives –display java
java – ステータスは手動です。
リンクは現在 /usr/lib/jvm/jre-1.5.0-gcj/bin/java を指しています。
/usr/java/default/bin/java – 優先項目 17040
スレーブ keytool: (null)
スレーブ rmiregistry: (null)
スレーブ jre_exports: (null)
スレーブ jre: (null)
/usr/lib/jvm/jre-1.5.0-gcj/bin/java – 優先項目 1500
スレーブ keytool: /usr/lib/jvm/jre-1.5.0-gcj/bin/keytool
スレーブ rmiregistry: /usr/lib/jvm/jre-1.5.0-gcj/bin/rmiregistry
スレーブ jre_exports: /usr/lib/jvm-exports/jre-1.5.0-gcj
スレーブ jre: /usr/lib/jvm/jre-1.5.0-gcj
現在の「最適」バージョンは /usr/java/default/bin/java です。

と出るので多分大丈夫。
とは云え、keytoolなどが(null)なのは気味が悪い。
 # keytool
-bash: /usr/bin/keytool: そのようなファイルやディレクトリはありません
だからね。
OpenJDKに切り替えればまた使えるようになるが・・・

# alternatives --remove java /usr/java/default/bin/java
で一旦消して
# JDK=/usr/java/jdk1.7.0_40
# alternatives \
    --install /usr/bin/java java $JDK/bin/java 17040                \
    --slave /usr/bin/keytool keytool $JDK/bin/keytool              \
    --slave /usr/bin/rmiregistry rmiregistry $JDK/bin/rmiregistry  \
    --slave /usr/lib/jvm-exports/jre jre_exports $JDK/lib          \
    --slave /usr/lib/jvm/jre jre $JDK/jre

で再登録。
# alternatives –display java
java -ステータスは自動です。
リンクは現在 /usr/java/jdk1.7.0_40/bin/java を指しています。
/usr/java/jdk1.7.0_40/bin/java – 優先項目 17040
 スレーブ keytool: /usr/java/jdk1.7.0_40/bin/keytool
 スレーブ rmiregistry: /usr/java/jdk1.7.0_40/bin/rmiregistry
 スレーブ jre_exports: /usr/java/jdk1.7.0_40/lib
 スレーブ jre: /usr/java/jdk1.7.0_40/jre
/usr/lib/jvm/jre-1.5.0-gcj/bin/java – 優先項目 1500
 スレーブ keytool: /usr/lib/jvm/jre-1.5.0-gcj/bin/keytool
 スレーブ rmiregistry: /usr/lib/jvm/jre-1.5.0-gcj/bin/rmiregistry
 スレーブ jre_exports: /usr/lib/jvm-exports/jre-1.5.0-gcj
 スレーブ jre: /usr/lib/jvm/jre-1.5.0-gcj
現在の「最適」バージョンは /usr/java/jdk1.7.0_40/bin/java です。
これでkeytoolなんかも使えるようになったハズ。
 



リビジョン

真っ先に思いつくのがsvn。こいつはよく壊れるというかリビジョン・デストロイヤーだ。
いつソースが消えるか改ざんされるか判ったものではない。
不味いことにsvnのクライアントのうちでsubclipseが一番最低。長く使うとアチコチと壊れてくるEclipse。その配下にworkspaceを配置するほど愚かなやり方はないくらいだが、そのWorkspaceにそのまんま.svnを配置してうごくsvclipseは独自の管理方法で自己流にやってくれるから、他のクライアントから他のsvnクライアント(亀さんなど)でsvclipseが使っているリポジトリィをいじると、変テコな履歴ができてしまい、クライアント上でクリーンナップしても意味がなく、リポジトリィ上でクリーンナップしても破綻する。こうなったらリポジトリィをエクスポートして作り直すしかない。
さてそんな苦労をしってか、法条 遥の「リビジョン」も現在・過去・未来のリライト合戦になっている。もっとも、時系列は一直線のハズだったのが途中から分岐が始まり、最後には無茶な結末が待っている。
svnでは、thunk(作業机)、branch(パッケージング)、tag(要約)と大雑把なまとめができるようになっているが、小説の方は波瀾万丈。
元々、リビジョンとは改訂の意味で、rev.1.1 で作った。rev1.2で取りまとめて修正、rev 1.3はちょっとしたミス直し、rev2.1は結構手直ししてみた。な感じに纏めるものだ。
しかし、現実は、そんな改訂とは程遠い。
そして、小説は もっともっと遠い結末だった。
 
 
 



タイムパラドクス

たった今、『リライト』著:法条 遥を読み終えた。
筒井康隆の「時を翔る少女」をベースに激痛タイムパラドクスをしかけてくる。が、後半はちょっとアレだった。
さて、題名の「タイムパラドクス」だが、実際の「タイムライン」に「パラドクス」は存在しない。はちゃめちゃだろうが、結果が出れば、すべて真実なのが「タイムライン」である。
そうなっては困るので、「パラドクス」というものが発生する。
それは「人間にとって望ましい結果を求める願望」にとっての「障害」であり、「正しい結果には容易にたどり着けない」ということを意味する。
「頭にぶつかったボールを誰が投げたのか判らない」ことは現実にはよくあり「原因」はあるはずだが容易には見つけることができないことが多い。その「判らない原因」を探る必要があるのは「治療費」を請求するのが目的であり、純然たる人間の欲求が「原因調査」の「原因」である。要するに「人間」はヒマなのである。
あえて言おう。
「原因」という実在は「結果」だけを残して消えるものだ。
ただ、その「原因」らしきものを「結果」を結びつけることはできる。
そう「言いがかり」である。
もっと明確に云えば、
初版の「タイムライン」の成分は99%の「パラドクス」と1%の「妄想」でできているのが現実だ。
故に、「リライト」で引き起こされる「SF史上最悪のパラドクス」はとても現実味のある内容となっている。(大笑
 
※以下、ネタバレ。
未来の人間が本に興味を持ち、過去に遡る。
そこで本に書かれている内容に自分が登場することを知る。
その後、未来に戻ろうとするが戻れない。
色々策を練り、行動し、望ましい結果を得る。
但し、未来に戻ることはできなかった。
 
素ネタの筒井康隆版では、タイムパトロールによって、強制送還される。(のハズ)
 
最後の結末は時代の要望によって変わるようだ。(大笑
 



原子・素粒子・クォーク

固体や液体は分子や原子の集合体で出来ているというのが定説だが、『物質を無限にどこまでも小さく分割できる訳では無い。なぜなら無限に分割できるなら無から有が生じることになり、どこかで限界つまり最小単位(アトム)があるハズだ。』と云う哲学的な考察から生まれた原子論がそのまま受け入れられた訳では無い、なぜなら最小単位が充分に小さいなら無限に分割可能と考えても差支えないからだ。
近年の原子論は物質にX線をあてるとその反射の具合が一様ではなく、小さな粒がかなりの間隔を置いて配置されているかのような結果だったことに始まる。人間の物質の感触からはX線を反射する小さな粒が大きな間隔を置いて並んでいるという構造は感じられない。(笑
この違和感を埋めたのが素粒子論だった。つまり原子は独特な構造(小さい原子核と周囲の電子雲)を持っているが、この小さな原子核が遥かに大きなサイズの力場を形成し、原子同士はこの力場が作用するため、人間(つまり原子の集合体)には、その隙間を感じることができないとしたのだ。

その原子の構成要素である素粒子はその後結構な数が発見された。素粒子論では素粒子=力場を形成するもの=力場を伝達するものと考えているため、力場即ち、素粒子同志の新しい反応が発見されると、新しい素粒子が自動的に生まれることになるからだ。余りにも数が多いので、実際には原子同様に素粒子も内部構造があると考えられた。つまり原子レベルでの原子核のようなものと考えていい。それはクォークと名付けられた。
その意味では原子も素粒子も同じ様な構造(力場とその中に極小さい素粒子がある)もので、実際、水素なぞは陽子とその周囲を電子が回っている様なモデルであり、素粒子のよくあるペア構造と云ってよく、よくよく考えれば原子も素粒子も境界線は結構曖昧だが、素粒子なのに物質にタメ口を吐くのが水素といってよい。物質たる人間はそんな素粒子なら感じられる。
しかし感じるものは何でも物質と人間は思っているので、水素は物質として扱われてる。
物質として扱う都合上、水素はH2と表記され、2つの水素原子が結合した状態であるとされる。
これは、1個の電子が原子核の周囲を回ると、原子核が電子を振り回すような恰好になり、反動で原子核はふらつき不安定だが、2つの原子核を2個の電子の雲が覆うと電子が周回軌道の反対側に位置すれば、原子核の位置が安定するし、2倍のクーロン力で電子が原子核に引き寄せられるため、電子の持つエネルギー量はH×2個よりも高くり、その分他の原子核の影響度は低くなり疎遠になり何かのはずみで大気中の放出されやすいと云える。
一方、クォークは厄介な概念になっている。力場=素粒子と云うそれまでの素粒子論の考え方が安易だったと反省することもなクォークがあるハズだとく突っ走っているからだ。さらにクォークは素粒子の実態(素粒子の素+力場)と考えるとクォーク単体での力場は素粒子の力場より強力でそれ故に素粒子同志の衝突でも容易に正体を現さないと考えられている。さらに原子サイズでは素粒子の力場が原子の反応に関与していた様に、素粒子サイズではクォークの力場(=クォークのサイズ)が素粒子の反応そのものに影響を与えるため、素粒子の力場よりクォークの力場の方が大きくなければならず、それではなぜ原子の反応に直接クォークの力場が介在しないのか不明のままであり、原子・素粒子・階層モデルは概念としてかなり破たんしている。
単純に云えば、地球を構成する物質はどんな圧力でも壊れない原子で構成されているのではなく、それなりの圧力を加えれば原子も壊れてしまうが、そんなレベルでは素粒子は壊れない。しかしもっと圧力を加えれば素粒子も壊れるが、クォークは壊れない。そう考えると、物質は実際にはとんでもなく頑強で絶大な力場を持った何かで構成されているハズだが、実際にはそれを感じることができないからだ。
それを解決したのが力場理論である。
素粒子(あるいはクォーク)はいくつかの力場を持ち、それぞれの力場には力場の到達限界距離があり、地球に例えるなら、表層、マントル層、外核、内核という感じで各力場が目立った働きをする距離(間合い)があるとした。
それも最近では11階層以上あるらしく、雲行きはかなり怪しく、大方の力場は素粒子よりかなり小さいサイズの到達距離しか持たないとされ、物質に関与しそうな力場は4大力場(重力、クーロン力、核力、弱い核力)とされ、他はビックバンなど非常に高密度で高エネルギー状態でないと反応することはないとされる。
さて、最近話題になってるヒッグス粒子は、質量の力場を構成する素粒子である。他の素粒子の行く手を阻む赤信号の様な陰湿な性格の持ち主である。何だったら今話題の消費税8%と同じと云ってもよく、ヒッグス粒子は素粒子世界の大不況の元凶なのである。どの素粒子も光速度で移動できハズなのだがコイツのせいで一気にスピードダウンし、まごまごしているうちに原子になったりしてしまったらしい。
そうなればヒッグス粒子は見えないし感じることもできないが空間に充満しているはず。否、ヒッグス粒子がぎっしりと詰まっているのが物質界での空間と云えることになる。宇宙には十分なヒッグス粒子がない領域もあるだろう。そこでは素粒子は自由に移動しており、物質なぞないだろう。ただヒッグス空間は広がり続けているらしい。他の素粒子に慣性質量の属性(あるいは力場)を生成するヒッグス粒子がある方向に移動するとそのヒッグス粒子はあらゆる方向に偏在しつつ移動することになる。なぜなら、そうならないと他の素粒子の慣性質量を維持できないつまり運動量を保存できないからだ。そうなると、自らの影武者の影響を受け止めどない自己増殖が始まる。まずいことにヒッグス粒子自体は質量を持たず、他の力場も持たないため、自己増殖に要するエネルギーは理論上0で一度勢いが付けば、際限なく増殖していく。まだヒッグス粒子が増殖していない空間では光速度で移動する素粒子が乱舞する世界。そこに不気味な真っ黒なヒッグス球状空間。まるでブラックホールの内側の世界みたいだ。
しかし、宇宙誕生直後から宇宙空間にヒッグス粒子があった訳では無い。かなり出遅れて出現し、今現在もまき返しの真っ最中。
 
 
 
 
 



定期的にパスを変える

定期的にパスワードを変えているが
面倒くさくなるとやばい
無線LANのパスワードを変えたら・・・
あっちもこっちも
 
そして無線LANにしかぶら下がっていないこの鯖のパスを事前に変更するのを忘れていたので
パスワードの変更の仕方もすっかり忘れていた。
 
キーボードとマウスとモニターを繋いで・・・
本当に面倒だった。
 
次は簡単に
 
怪しいのが、無線LANにつながろうとしている
まだ何か忘れている
 
暫くしてその正体が判明。
 
それは・・・
 
寝室のテレビに繋がっている無線LANのアダプターだった
 
youtubeが観れなくて気が付いた
orz



JavaのBean

実体は、
private なプロパティにSetter/Gettorを付けただけのもの。

class  xxxBean {

private int aaa;

int getAaa(){ return aaa; }

void setAaa( int aaa) { this.aaa = aaa; }

}

これが美味しいのは、
ちょこっとコードを付け加えると、容易に似たものがいっぱい作れるからだ。
例えば、
void setGMT(Date gmtTime) { this gmt = gmtTime; }
で時刻をセットしたら、
Date getJst() /* 日本 */         { return gmtTime  + 9 hour; }

Date getEst() /* アメリカ西部*/{ return gmtTime  –  9 hour; }

Date getEt() /* アメリカ東部*/{ return gmtTime  –  5 hour; }
で判れば便利だからだ。
でも、全世界分のメソッドを作っても、賞味期限は不明なので、別のやり方(Locale)で延命している。
Localeでも新しい標準時刻が規定されれば、新しいstatic Locale を追加しなければならないが、メソッドそのものを追加する必要はない。
だが、50歩100歩なので、実際は大きな差は無い。
新しいメソッドを追加しないと国際問題になるが・・・
新しいstatic Localeを追加しなくても
代用で済むならOKな世の中の情勢によるところが大きい。
このBeanを使うと全てのメソッドは大雑把に

XxxBean   aMethod (YyyBean)

に纏めることができる。
が、それはC言語どころかCOBOLでもBASICでも同じで、できないのは古い版のFORTRANぐらいなものだ。
※構造体の概念が欠落しているからね。
しかし、JavaだけBeanとか言っているところが、幼い感じがする。
そう、今のJavaは幼い。
見の丈が足らない。
例えば、インターフェースのための、ヘッダーファイルを定義できない。
インターフェースとして外殻だけだがクラスとしての実態を持たなければいけないので、
インジェクションによる初期化が必要なクセにそのコードの実装は実に巧みに隠しているため、
ソース上は丸く収まっても、実行してみれば・・・インターフェースのオブジェクトの実体はnullポインターなので、Exceptionが容易に発生する。
つまり、一通り出来上がっている振りをしているが、実は使い物にならないのだ。
そのため、jarをいくつもクラスパスに記述しないと、executeすらできない
ボロクソなものになってしまっている。
なぜこうなってしまったのかと云えば
java  xxxxx  -jar zzzzz.jar
と手軽に実行できるので、null pointer exceptionが起きたら・・・
足りない何かをくっ付けて
java  xxxxx  -jar zzzzz.jar -jar yyyyy.jar
とすれば済んでしまうので、
Javaコードの集合体はセキュリティ的には非常に危ない作りになっている。
java  xxxxx  -jar virus.jar -jar zzzzz.jar -jar yyyyy.jar
で簡単に乗っ取ることができる。
しかしサーバー内の話なのでOKということになっている。
ま、侵入されるなら、それ以前の出来事と云うところなのだろう。
 
 



Javaのインジェクションと節操のない初期化の山

簡単に書くと
ドコの
xxxDao   dao; /* 実は普通のクラスではなくinterfaceクラス */
なソースに
dao.selectXXXX(dto);
すれば、
簡単にNullPointerExceptionが起きて使えないが、
どこかでコッソり
dao = new xxxDaoBean();
してしまえば使える様になるたったそれだけのこと。
@EJB    ejb.jarのどこかのクラスのstatic Mainメソッド
とか
@Resource   ibatis.jarのどこかのクラスのstatic Mainメソッド
とか
アノテーションを書いておけば、誰かがやってくれる。
ハズ。
え?勝手にどうやって動くのか?

class   xxxx{

static {

/* スタティックの無名領域で初期化を無意識に恣意的に実行 */

initialize();

}

void  static initialize () {

/* 沢山の初期化処理 */

}

}

 で、いいじゃないですかね?
簡単でしょ?
※同じことはC++でも出来ます。
 
実は、環境に応じて、
dao = new batchDaoBean();
とか
dao = new onlineDaoBean();
とか
dao = new androidDaoBean();
とか
dao = new iosDaoBean();
とかに差し替えが効くところが良いのだが、
 
実際にはそんな使い方をすることは・・・
 
アリエナイ話。(爆
 
 
実にJavaは、何かのjarのMainが勝手に初期化するので、どんな動きになるか、判ったものではない。
当然のことだが、安易なインジェクションはソースレベルデバッグを困難にさせる。
strutsもそうだが、ソースが無いclassを跨いでワークフレームを作ることが多いからだ。
 
競合が起きて当たり前だし、上記の初期化処理に膨大な時間がかかるのも当然の話。
 
で、なんでそんなものを使うのか?
一つにはモジュールの差し替えがしやすい点があるものの。
 
そんなものはワークフレーム側の話で、それにぶら下がるクラスは普通に作ればいいはず。
でも、過去のインジェクションのデザインは、その上下関係が間違っていて、ワークフレームに作り込む方が
自動的にインタフェースじの変数にオブジェクトがインジェクションされることを前提にしている。
これは、ワークフレーム側がインジェクションの仕組みをカスタマイズする手法を勘違いして作ってしまったためだろう。
というかサンプルでサクっと作ったら、出回ってしまったと考えた方がいいだろう。
だって
/*  フレームワークのソース */

for(Class class :  all_class_list ) {

if(   class.isClass() ) {

for(Method method :  class.getMethodList() ) {

if( method.class.isInterface ) {

if(method.value == null) {

Object object = classMap(method.getClassName());

if( object != null ) {

method.value = object.getInstance();

}

}

}

}

}

}
な感じでnullにオブジェクトを挟んでくれたら楽そうに思える。
でも、その実態は・・・
 
interface  xxx = new XxxBean();
XXX.method()

@xxxInjection
interface  xxx;
XXX.method();
と書いて、全ソースのインジェクションを巡回する長~い初期化に時間を費やすことになり、
デバッグも面倒なので、
何も得るものはない。
ま、失敗なのだが、駄作であれ、悪貨であれ、出回ってしまったものが勝ちな世の中。
強いて云えば、
自分で作るつもりが無い部分をinterfaceとしてコードし、
その実装を外注に出せばいいだけだが
interfaceをclassに書き換えらる。(自分のコードを書き換えられるのが嫌)なら、
先のEJB手法が必要だ。
もっとも、
java   -jar 自分のソース.jar   -jar interface.jar

java   -jar 自分のソース.jar   -jar interfaceの処理を実装したクラス.jar
で実行すれば済む話でしかないのがEJBだ。
もちろん、自分のソース.jar にinterfaceの処理を実装したクラス.jarを使ってコンパイルしておかないとうまく動かない気がする。
ので、やっぱりEJBがいい。と思ってしまうのだろう。
だが、そんなEJBの動作テストはどうやるのか?
実装.jarができるまで放置しておくのか?
その辺の考慮がごっそりと抜け落ちているのが
やはりJavaerの幼さなのだろう。
 
でも、世の中どんどん変なものが残っていくのも仕方がないことだよね。(大笑 



X-FRAME-OPTIONSの「その後」

X-FRAME-OPTIONS

を設定すると、
WordPressの「画像の編集」の画面が真っ白になる。
と云うことは、「画像の編集」は別ドメインということになるのか?
実は、URL無しで中身を書いても、やはり真っ白になるようだ。
なので有害な設定でしかないので

X-FRAME-OPTIONS

は外すことにした。
でも気になるので、
Header always append X-Frame-Options SAMEORIGIN
で妥協。
ところが、FF14用のサイトは変化なし。
IEで見てみると設定がまだどこかに
Header always append X-Frame-Options DENY
が、残っているらしい?
# find /****/****/****  -type f | xargs grep -i x-frame-options
で、検索してみると、ココもFF14も
function send_frame_options_header() {
@header( ‘X-Frame-Options: SAMEORIGIN’ );
}
が出てきた。バージョンアップでWordPressが自発的に付ける様になったらしい。
だが設定は同じハズ。(謎
 



CPGPUでウイルススキャンしない謎

ありそうで無いのが、CPGPUでウイルススキャンを高速化するウイルスセキュリティソフト。
これができたら、セキュリティ向上のためにグラボが必須になるのは間違いない。(大笑
思うに、X86ベースで構築してしまってGPUに手を出すのがメンドクサイのだろうが、
ユーザからすればCPUを使いながら空いているGPUでスキャンしてくれた方がいい。
マルチコアが主流だが、大多数は2コアしかないので、意外とヒマが無い。
しかしGPUの方は動画やゲーム以外は結構ヒマな時間が多く使わない手は無い。
第一、同じようなことを延々と処理するなら

パイプライン処理がしやすいGPUの方が

長時間に及ぶウイルスのフルスキャンに向いているのだ。 

INTELあたりは渋い顔をしている気もするが、
APUを持っているAMDは推進してくれそうな気がする。
ウチならグラボなしでもCPGPUでウイルススキャン速いっすよ!(笑
な調子で・・・(爆
 
もっともグラボなんて付けてないPCが多いハズだが、
この際!

セキュリティ強化のためにグラボを買いましょう!

ってキャンペーンを貼れば良いではないか!
一つだけ問題があるとすれば消費電力。
ウルトラ・ハイエンド・グラボをフルパワーで実行すれば困るくらい燃費が悪いが
発熱がほどほどな程度に使えば、格安グラボより燃費が良いし、煩くも無い。
格安グラボとウルトラ・ハイエンド・グラボ比較で、
ウイルスフルスキャン・ベンチマーク・イベントでもやればはっきりとした結果が出るだろう。
何となくCPUはi5でいいけどGPUはTITANにする
とか変なことを言い出す会社も出てきそうな気がするけどね。(大笑
 
ps.
後、数日でカウンタが30万。
つまり、DBに30万レコードある訳だ。
そろそろ+30万にしてレコードを削除した方がいいような気もする。




top