ウマ娘関連のネタが多いでしょうか
公開鍵暗号あたりを勉強していたとき、巡り合ったのが JCA なるターム。
調べてみたら Java Cryptography Architecture からきているらしい。
気になる問題は、マイナカードあたりでは、（秘密鍵による）暗号化自体はカードに格納されているアプリで行うので、どうやって外部暗号化モジュールと連携をはかるかってこと。
・・・とタラタラやっていたら、偉大な某氏が、X で調べ始めた。
ええと、実際の JDK のソースにあたるとここら辺の実装が分かってくる。
例えば、XML 署名の際には、sign というメソッドを使うが、そのソースはこうなっている。
XMLsignature クラス自体が abstract なため具体的な実装はなく、やはり暗号化ブロバイダあたりの機能を使っているってことかな。
（適宜情報追加予定）
もうあまり使うことはないかもしれないが、Java のアプリケーションサーバ WildFly の運用のための覚え書き。
レガシーなプロジェクトで、JavaEE ウェブアプリと JakartaEE ウェブアプリが混在するような場合、少なくとも２台のWildFly が必要になる。27 以降の WildFly と 27 より前のバージョンがそれぞれ少なくとも一つは必要。
結論から言うとできる。
ただ、ポートがかち合わないように設定ファイルを変える。
ワイの場合は、各ポート番号に 10000 を足す。
standalone-full.xml
<socket-binding-group name="standard-sockets" default-interface="public" port-offset="${jboss.socket.binding.port-offset:0}">
<socket-binding name="ajp" port="${jboss.ajp.port:18009}"/>
<socket-binding name="http" port="${jboss.http.port:18080}"/>
<socket-binding name="https" port="${jboss.https.port:18443}"/>
<socket-binding name="iiop" interface="unsecure" port="13528"/>
<socket-binding name="iiop-ssl" interface="unsecure" port="13529"/>
<socket-binding name="management-http" interface="management" port="${jboss.management.http.port:19990}"/>
<socket-binding name="management-https" interface="management" port="${jboss.management.https.port:19993}"/>
<socket-binding name="txn-recovery-environment" port="14712"/>
<socket-binding name="txn-status-manager" port="14713"/>
<outbound-socket-binding name="mail-smtp">
<remote-destination host="${jboss.mail.server.host:localhost}" port="${jboss.mail.server.port:10025}"/>
</outbound-socket-binding>
<outbound-socket-binding name="messaging-activemq">
<remote-destination host="${jboss.messaging.connector.host:localhost}" port="${jboss.messaging.connector.port:51616}"/>
</outbound-socket-binding>
</socket-binding-group>ただし、このやり方だと activemq は 71616 となり
A maximum value of 65535 is requiredと WildFly に怒られるので、10000 を引く。
こうしておくと以下のように管理画面も同時に表示できる。
めでたしめでたし。
JBOSS_HOME の docs 以下のフォルダに各種サンプルファイルがあるので、これをうまく活用する。
Ubuntu の場合は、以下のようにそのまま使える。
sudo mkdir /etc/wildfly
sudo cp /opt/wildfly/docs/contrib/scripts/systemd/wildfly.conf /etc/wildfly
sudo cp /opt/wildfly/docs/contrib/scripts/systemd/wildfly.service /etc/systemd/system/wildfly.service
sudo cp /opt/wildfly/docs/contrib/scripts/systemd/launch.sh /opt/wildfly/bin/launch.shこの作業が終わった後、初回起動は
sudo systemctl enable --now wildflyというコマンドで。
なお、サービスが走っている場合のデプロイは jboss-cli.sh を走らせ、そこから
deploy PathTo/hoge.warで投入できる。
Java の慣習でしょうか & を付ける。
standalone.sh -c stanalone-full.xml &Ctrl+C でメッセージを終了させてもプロセスは終わってない模様。
バックグランドで走らせた状態では Ctrl+C では停止できないので以下のコマンドを使う。
jboss-cli.sh --connect command=shutdown
（適宜修正予定）
X などで「わかっているのだが、覚えるには至っておらず、何度も調べてしまうこと」が度々話題になる。
vi の操作方法とかさ。
ワイの場合は WildFly の初期設定もそのうちの一つ。
一体、何度、調べただろう？
いい加減、あちこち調べるのが嫌になってきたので、忘備録的なまとめ。
まずは、管理ユーザーを作成するのがいいだろう。
管理ユーザーなしでも WildFly 自体は起動できるのだが、コンソール画面に入れないので、まず、これをやる。
Linux/Mac などでは bin フォルダ内の add-user.sh を実行。Windows では add-user.bat 。
ほとんどの場合、既存プロジェクトの WildFly のバージョンアップデートに伴う移行だと思うので、管理ユーザー名も同一にしておくと迷わなくてすむ。
ただし、この手の作業が面倒に感じる理由の一つとして、「パスワードの設定方法が変わってしまう」というのもあるだろう。
今回、作業した WildFly27 では、以下のように non-alphanumeric symbol が必要とされた。
The password should contain at least 8 characters, 1 alphabetic character(s), 1 digit(s), 1 non-alphanumeric symbol(s)以前のように「12345678」ではダメである。英数字以外の記号を一つ含める必要がある。
他は、y と答えておいて困ることはない。
デバイスドライバなどをインストールする。
PostgreSQL のドライバをインストールする場合には、以下のようにする。
（ドライバはここから取ってくる）
WildFly 自体を起動した状態で jboss-cli.sh を実行。
You are disconnected at the moment. Type 'connect' to connect to the server or 'help' for the list of supported commands.
[disconnected /]というメッセージが現れるので、connect と打ち込む。
その後
module add --name=org.postgresql --resources=(パス)\postgresql-(バージョン).jar --dependencies=javax.api,jakarta.transaction.api/subsystem=datasources/jdbc-driver=postgresql:add(driver-name="postgresql",driver-module-name="org.postgresql",driver-class-name="org.postgresql.Driver")とタイプ。
上のように success が返ってくればOKです。
なお dependencies=javax.api, jakarta.transaction.api となっている点に注意。
いわゆる JavaEE -> JakartaEE 移行に伴う名前空間の変更の影響を受けています。
思いつくままに。
これも何度検索かけただろう？
jboss-cli.sh --connect --command=":shutdown"だそうです。
（適宜情報追加予定）
『ものぐさ Jersey』的なやつが好評のようなので、その RESTEasy 編。
いきなりで恐縮だが、REST なウェブサービスを作っている際に画像も REST 的に取り扱いたいときがある。
要するに適当なエンドポイントを叩くと画像ファイルが返ってくる、みたいなやつだ。
サーブレットで実現するのが一番簡単なようなんだが、サーブレットを使わない方向でチャレンジする。
リンクした記事は jsp で書いてあるが、ちなみにサーブレットで書き直すとこんな感じ↓になる。
あっさり成功。
で、RESTEasy 。
まずは公式ドキュメントのチェック。
レスポンスを適当に加工すれば、なんとかなるだろうくらいに思って調べてみた。
なんだが…
なんでしょう、この突き放された感じ（笑）。
jakarta.ws.rs.core.StreamingOutput を使って自分で実装しろ的なことが書かれている。
いや、そんなことをするくらいならば、サーブレットのやつそのまま使いたいかなあ（困惑）。
他の人がどうやっているかよくわからないのだが、まずはシンプルに攻める。
（公式ドキュメントのサジェスチョンを尊重して）バイト列を生成して、そいつを ByteArrayOutputStream にセットし、さらにそれを Response の中（Entity とかいうみたいだ）に入れ込んで REST っぽく返す、と以下のような感じになる。
@Path("/octet")
public class OctetServer {
@GET
@Produces(MediaType.APPLICATION_OCTET_STREAM)
public Response sendOctet() throws IOException{
byte[] byteData = "123456789ABCDE".getBytes();
ByteArrayOutputStream output = new ByteArrayOutputStream();
output.write(byteData);
return Response.ok(output.toByteArray(), MediaType.APPLICATION_OCTET_STREAM).build();
}
}これで curl で （コンテクスト）/octet を叩くと、もちろん 123456789ABCDE がバイナリで返ってくる。
ブラウザからアクセスすると octet というファイルを落としてくれるが、中身は当然 123456789ABCDE だ。
これで、第一段階はクリア…
と思っていたが、コード見直すと、バイト列をストリームにセットした後、さらにバイト列に戻す、というバカっぽいことをやっている（苦笑）。
だから、上のサンプルはもうちょっと簡単になる。
具体的には、
return Response.ok(output.toByteArray(), MediaType.APPLICATION_OCTET_STREAM).build();は、
return Response.ok(byteData, MediaType.APPLICATION_OCTET_STREAM).build();としても変わらない。
もちろん、その上の２行は全く不要。
とりあえず、バイナリのデータを返すだけであれば、アウトプットストリーム系は不要で返したいデータのバイト列を response のエンティティにセットすればいいだけのようだ。
指定した画像などを返したければ、path parameter を設定してデータベースから検索して云々とやれば、実現できそう。
使われている割に存在感が希薄な H2 database。（WildFly ではデフォで使える）
調べたら、ホームページもあった。
https://www.h2database.com
使い方はそこの Cheat Sheet にまとまっているので、特に付け加えることもないのだが、サーバーモードというのは知りませんでした。
ちゃんと調べてみるものだね。
H2 console を単体で使いたければ、h2-(version).jar を入手して、ダブルクリックで起動、ブラウザ画面が立ち上がる。
pgAdmin や phpMyAdmin みたいな感じのユーティリティソフトです。