その後にX68000のリセットボタンを押して再起動。起動時のログにD:ドライブが追加された、という下記のようなメッセージが出れば成功。1.42ドライブE:を登録しましたRaSCSIのRASDRV.SYSをHuman68kのconfig.sysに設定してみた。2018あとは起動完了後にEドライブを覗いてみれば・・・あら不思議、X68000からRaspberryPiの全てが見える!!RASDRV.SYSヤバい。ドライブの直下として見えるので、そのようにしても良いだろう。いやむしろそうした方が良いかもしれない。お好み・用途に応じて。あと片づけこのまま使ってもらっても良いのだが、RASDRIVER.HDMのBドライブへの登録が残った状態になっている。Raspbian側に戻り、登録を外す。/etc/systemd/system/rascsi.serviceサービス定義からRASDRIVER.SYSを外す。BRIDGETimeoutStopSec=5StandardOutput=null[Install]WantedBy=multi-user.targetリロードし、念のためドライブ状況を確認しておこう。RASDRIVERの行が無くなってれば成功。BRIDGE---+------+---------------------------------------最後にX68000を再起動させる。RASDRVがDドライブに変更されたはずである。前記「E:」で書いた箇所は全てD:に変更されているので読み替えを。HDSイメージを何個もマウントするとこのドライブ名が後ろにどんどんズレていくことになるのでご注意を(これは恐らくHuman68Kの仕様)。2017の23日目です。Sessionで1枠と、3枠の公演をしてきました。8での差分について、改めてこちらにまとめておきます。類似の話は恐らく各所にあると思うので、読み込んでいるプロな方には今更感が満載だと思います。Calendarはそういう趣旨では無いと思いますので、まあこういう記事があってもいいじゃないですかね。8がリリースされました。EEは特定の製品でも何でもなく「アプリケーションサーバーの標準仕様」となります。8仕様に準拠したアプリケーションサーバーはこれから登場します。EE仕様策定に参加している会社・コミュニティー間で合意が取れ、標準仕様が決まったばかりですので。5がリリースされています。1がリリースされています。※当然ですが、実稼働システムを検討する場合、Glassfishは絶対に選ばないで下さい。セキュリティーパッチが出ません。これは旧4系でも同じです。速やかに商用版であるPayaraもしくは別の製品に移行しましょう。EEの開発はこのあとEE4Jというプロジェクトに移管されることになっていますが、この件は本記事とあまり関係ないので飛ばします。1.2仕様から数えて6回目のメジャーバージョンアップとなります。メジャーバージョンアップなので各種の改善と非互換が出ています。本記事の要旨はここになります。EE仕様の暗黙のルールとしては、「過去の技術は二つ前の仕様までサポートする」となります。6は2009年末に出ていますので、約8年間以上は大丈夫、という実績があります。古いアプリケーションサーバーを使えばもっと行けるので、10年ちょいは間違いなく大丈夫でしょう。EE仕様でアプリケーションを作成する場合は、できるだけ最新仕様を使うようにしましょう。5仕様のアプリケーションが動かなくなります。5仕様自体は2010年頃まで普通に使われていましたので、移行を検討しましょう。商用アプリケーションサーバーによっては、ひょっとしたらサポートしてくれるものがあるかも知れませんが分かりません。5が動くアプリケーションサーバーを後生大事に取っておくか、です。EOLの後でも数百万~数億となる大量のお金を投入すれば可能でしょう。EEの項目を見たところ壮絶に古い記載で今となっては不適切だったりするので、そのうち書き換えます。7との差分がどれだけあるかというと、然程ありません。7仕様が優れていたということでもあるのですが、要は明らかに足りなかった機能を追加しました、という感じのメンテナンスリリースと捉えてもらえれば間違いないかなと思います。8で未来が変わる!」というような感じになっていないのは正しい反応です。2016で発表予定だったのですが、急遽延期になってしまった経緯があります。Proposalに応募していた末席の私はもちろん、その界隈で著名な方々(Oracle社員除く)も丸ごと落とされてしまい、人知れず枕を涙で濡らしたのでした。8への視線は更に厳しいものになったのですが、実に余談なのでこれ以上は止めておきましょう。次からは技術記事らしく、中身を見ていきましょう。2系以前に必須であったDDであるejb-jar.xmlを思い出して拒絶反応を示す人が未だに多いですが、それだけではなくWARの中にあるweb.xmlも、JPAで使うpersistence.xmlも立派なDDなので、混同しないようにしましょう。ちなみに、ejb-jar.xmlはEJB用としてまだ使えますが、アノテーションで代替出来るため不要となりました。あれば、アノテーションより優先して扱われるものとなっています。SchemaのXSDを指定するようになっています。EE仕様に則って作られているのか」を判断しています。EE仕様で動作してしまうということです。新機能を使おうと思ったんだけど呼び出されない、等々で何日も悩む羽目に陥らないよう、まず最初に書き換えましょう。metadata-complete="true">...</web-app>[/code]例えば上記のような感じです。一覧はこちらにありますのでどうぞ。APIの追加これは大きい変更です。Webシステムでログオン有無の管理は従来自前で処理するものでしたが、他のプラットフォームではあって当たり前な感じにもなっています。securityContext.authenticate(httpServletRequest,httpServletResponse,params);[/code]プログラム上のAPIを呼び出すコードは上記の感じで簡単ですが、問題はこのコードがどう動くべきか、をカスタマイズなり設定なりが必要となります。そりゃぁ、企業システムのID管理なんて千差万別な訳ですよ。Directoryだったり生LDAPだったりデータベース+JSONだったりと。対象が社員だったり顧客だったりするとまあ更にバリエーション豊かになります。いうのを吸収するAPIとして制定されているようです。データベースへ問い合わせする場合は、このようなアノテーションをAppliationConfig.java辺りに書く感じです。{...}[/code]なお、標準機能としてはLDAP接続とデータベース接続辺りがサポートされていて、更にカスタムで接続を実装することが可能となっています。どんな認証でもこのAPIで吸収することが理論的に可能と考えられます。このあと実装例が多々出てくると思いますので、それを待っててもいいかもですね。APIが街にやってきた!」でもっと詳しくありますので、気になる方はそちらへどうぞ。JSON-Bの追加つぎ、JSONとJavaプログラムを相互に変換するAPI、通称JSON-Bが追加されました。いう感じではあるかもですが、正式な単独仕様として追加されました。JavaオブジェクトからJSONへの変換は特にRESTの呼出し元側で必要となったりするので、この仕様は特にJavaFXや単独Javaアプリケーション辺りで特に使えるのではと感じます。false}[/code]こんなコードだけで行けちゃいます。Dog.class);}[/code]便利ですねぇ。便利すぎてアホになっちゃいそうです。入出力の細かい制御をしたければ更に色々出来ますが、通信相手側のの謎仕様JSONに合わせねばならない場合以外にはあまり使い道が無さそうではあります。Injection)がメジャーバージョンアップしました。要は昔流行ったDI(依存性注入)やアスペクト指向です。バズワードの一種ではありましたが、一部便利になったことは間違いないでしょう。EE内の位置づけとしてはポストEJBという感じで徐々にEJBの機能を絶賛移植中です。ドバーと一気に移植しちゃえばいいのにと思わなくも無いですが、そこまで重量級のものも要らないよね、ってことなのかも知れません。追加されたのが、非同期イベントが使えるようになりました。EJBの@Asynchronous相当と思えばいいですが、もうちょっとややこしい感じです。EJBのように呼ばれ側で書くんじゃなくて、呼び元で書くという感じで、逆になってます。いうメソッドを使います。次に、EJBTimerに相当するスケジューラーをCDIからも使えるようになりました。ついでにEJBの@Startupも使えるようになりました。これはCDIコンテナーが初期化するタイミングで最初に呼ばれるメソッドです。初期化処理はここでやりましょう。SE環境でCDIが使えるよう仕様として公式にサポートされました。これまでも実装側で対応してたと思いますが、公式サポートは大きい。SE環境で自己起動するような軽量なバッチ処理や、クライアント系アプリケーション、例えばJavaFX環境などでCDIを思う存分使いこなせるでしょう。http://xmlns.jcp.org/xml/ns/javaee/beans_2_0.xsd"bean-discovery-mode="annotated"></beans>[/code]こんなコードで動きます。SOMETHING.}}[/code]一回CDIを呼び出しちゃえばその先はCDIワールドなので@Injectでインジェクションしまくっちゃって良い感じかと。上記のコードだと、myBean.doWork()の先からめくるめくCDIワールドです。4.0これは純粋にベース技術の更新であるHTTP/2にやっと追随しました、というものですね。他のプラットフォームは早々と対応していたので、「今頃!?」という感じでもあります。周回遅れ感が辛いところではありますが、もっと早く仕様が決まるような新体制になってくれればなぁと祈念致します。2.3これは最もデカい更新です。書くのが多すぎてどれから書くべきか悩むくらいありますが、順番に。Beanが遂にDeprecatedになりました。今や何のメリットも無いので、それらはCDIに書き換えましょう。一対一で書き換えられるので、特に悩むこともないですし、一気にスクリプトで書き換えるのもありかも知れません。JSFのイベント内やFacesServletの前にFilterを置いて、仕様に無いようなハッキングに近い処理をやっていた場合は、その部分の全面書き直しになります。いずれにせよ、移行には充分なテストを行うようにしましょう。追加され、遂に最後のイベントが拾えるようになりました。これは画面描画が終わった後のイベントなので、何か後処理が必要だったりする場合限定です。なくても困らないですが、ないより有る方が良いですね。細かな改善系だと、セッション周りとの相性が最悪だったAjax関連機能の改善があります。壮絶に頭の悪い仕様だったラジオボタンもレイアウティングに対応し、やっと使えるようになってくれました。他にもInjectできる数が増えたという嬉しい話があります。使用頻度の高いと思われるExternalContext辺りがこんなコードで拾えるようになりました。(<f:websocket>、PushContextあたり)もあります。8にもようやく対応しました。APIに対応した、何故か対応していなかったExternalContext#getInitialParameterMapやらConverterやらValidatorやら。そんなこんなで大量改善があったJSFで、これだけで1冊本が書けそうです。Web系は動きが速いので、この調子でガンガン更新していって欲しいものです。激しくてもいいくらい。2.2、つまりデータベースとのやりとりの場所です。した改良に止まっています。APIに対応しました。1.1~1.2頃に整備されたカビの生えたようなjava.sql.Dateやjava.util.Timestamp辺りともおさらばです。OffsetDateTime辺りが日付型カラムとの自動マッピング先として使えるようになりました。annotationに対応しています。これはひとつのメソッドに同じアノテーションを複数書けるようにしました、というちょっとした小改良に追随したものです。ConverterでCDIがインジェクト出来るようになったとか、ちょっとしたメソッドが追加されたとか、その程度です。まとめさて、ここまでざーっと見てきました。華々しいJSFの改良と比較して、それ以外は実質的に小改良に留まっています。8対応、でもいいんじゃないかな、と思います。