Tomcat/Tomee の WAR ファイルのアップロードのサイズ上限

これまで動作確認程度の小さな war を GUI マネージャー経由でデプロイすることがもっぱらだったんだが、もうちょっとエンティティ増やして・・とかやっているうちにファイルが大きくなり、デプロイ時に OK は出るものの管理画面に反映されないようになった。

ログ見たら、ファイルサイズの上限超えていてデプロイできないとかなんとか。

上限解放は

/webapps/manager/WEB-INF/web.xml

<multipart-config>
<max-file-size>52428800</max-file-size>
<max-request-size>52428800</max-request-size>
<file-size-threshold>0</file-size-threshold>
</multipart-config>

を適当な数値に書き換える。

<multipart-config>
<!– 100MB max –>
<max-file-size>104857600</max-file-size>
<max-request-size>104857600</max-request-size>
<file-size-threshold>0</file-size-threshold>
</multipart-config>

にしておけば、100 MB 程度まではアップできる。

ただ、これ面白いのは、この数値はあくまで GUI マネージャーを介してのファイルサイズ上限で、同じやつを埋め込みで起動していた時には、まったく問題なく動いていた。

 

TomEE をソースコードからビルド&デプロイする

ビルド

GitHub からソースコードを持ってくる。

maven で管理されているプロジェクトなので、以下のコマンドでクイックビルド。

mvn -Pquick -Dsurefire.useFile=false -DdisableXmlReport=true -DuniqueVersion=false -ff -Dassemble -DskipTests -DfailIfNoTests=false clean install

これが長い(笑)。

ビルドする環境にもよると思うのだが、ワイの環境では余裕の 50 分越えw

成功すれば、tomee -> apache-tomee フォルダ内に target フォルダが生成されているはずだ。

以下の図のように各種 TomEE (フレーバーなどというようだ)ができている。

フレーバー云々に関しては『Tomcat 魔改造 vs TomEE』の TomEE WebProfile, TomEE Plus, TomEE MicroProfile, TomEE Plume を参照してください。

 

デプロイ

各種フレーバーのうち、今回は tomee-plus をチョイス。

zip か tar.gz を解凍。

このフォルダを適当に改名して /usr/local 内に配置。

 

テスト実行

実行ファイルなどのパーミッションを適宜変更。

手を抜くなら

chmod -R u+x tomee

で。

bin フォルダに移動して

./startup.sh

で起動。

ブラウザで http:localhost:8080 にアクセス。

Tomcat でお馴染みの GUI 管理画面が見えていれば OK。

 

ハロワ

何も考えずにハローワールドw

問題ないようです。

 

 

 

 

 

2022-08-25 ウマ娘スピード1600問題など

25日ということもあって、給料日でほくほくしている人も多いんじゃないでしょうか。

それは、置いておいて、憂さ晴らし?的な日記的な記事。

? ウマ娘 ステータス反映詐欺?疑惑

twitter ウマ娘界隈で、現在、最も話題にされているのがこれ。

実際の歩行動物の速度を考えてみれば、こういう仕様になってもおかしくはないと思っていたので、ワイはそんなに憤ってはいない。

ステータスの値が最高速度にリニアに反映されるってシミュレーション系ではありえんと思う。

リアルとゲームをごっちゃにするのもどうかと思うが、大谷の潜在ステ(みたいなのがあるとしてだが)が倍になったら、球速も倍になるかっていうとそんなことはないでしょう。

今までのチャンミにしても A+ くらいのデバッファーが SS 勢あたりには勝つことは度々あったわけで、ガチキレっぽい人を見ると、そういうのをどう思ってたんだろうと思う。

 

ワイだったら、運営責めるより、それまで解析を怠ってきたことを恥じるな。

ああ、そうそう憂さ晴らしっていうのは、そういう風にゲームやっている層への違和感を吐き出したかったから。

? TomEE

まだ、はっきり記事化してないけど、「TomEE = Tomcat の上位互換」と考えると多分イタい目にあう。

tomcat をちょっと EE っぽく使おうとすると何らかの手を入れている場合が多い。
そのアプリを TomEE にそのまま持ってきたところで正常動作するわけはない。

つまり tomcat アプリを TomEE に移植しようとすると何らかの調整が必要なんだが、問題なのは、それにまだワイが慣れてないってことなんだな。

今しばらくは基礎的なトレーニングを続けるしかないようだ。

ところで、Java といえば、実はワイはこの言語はそんなに好きではない。

言語の仕様自体はどちらかといえば好みなんだが、JAVAer っていうのか? Java 特化型のプログラマー・SE の物事の考え方や立ち居振る舞いがどうしても受け付けない。

例えば、寺◯って人が Java 界隈では有名っぽいんだが、この人の書いたものを読んでも全然ピンとこない。

かなり乱暴だが言葉にすれば

・説明が冗長でポイントが掴めない

・なぜかややこしいサンプルコードを書く

というのがその特徴。

これはこの人だけの特徴ではなくて、Java に何らかのアイデンティティを置いている人に割と共通してみられる特徴だ。
実際、一昔前のサラリーマンのようにしんねりむっつりとコード書いている人が多い。

ああいうの楽しいのか。

あと、(当時は駆け出しもいいところでピンとこなかったんだが)Java が移管された時に大騒ぎしてた連中の言い分は何だったんだあれ?

? 渡部愛さんの白い服

将棋はそんなにやらないんだが、アベマの聞き手女流棋士くらいは知っている。


服のセンス良くない?

 

 

 

(まだまだ続きそう)

 

TomEE 使ってみての雑感

いくつかのサンプル作成してみての雑感などをあれこれ。

Tomcat に JavaEE(JakartaEE) の機能が追加された、というのを額面通りに受け取ると、あたかも TomEE は Tomcat の上位互換のような印象を受けるが、ちょっと違うかな?と思わないでもない。

埋め込みで使うのが苦手かもしれない(裏技的解決法あり)

今、ちょっと取り組んでいるのが embedded (埋め込み)で使う場合。
tomcat では方法論が確立されているが、tomee ではサンプルすら見つけられない。

それっぽいライブラリはあるのでできなくはないと思うんだが?

ただ、以下のような点は気になる。

少々古い記事になるが、RedHat の中の人が、こんな記事を書いていた。

In summary, of course Spring Boot is cool, but with really simple steps you can start having the same in JavaEE world. We (Apache TomEE contributors) are going to start to work on this and expand this idea.

So don’t underestimate Java EE because of Spring Boot.

 

underestimate (過小評価)しないでくれ、とは言っているが、そこで挙げられたソースコードはあまり実用的とはいえないシロモノで、それで信用しろと言われてもねえ。。。

Spring Boot との比較をしているが、tomcat でできることができないとなると、もはや戦っている土俵が違うという感じだ。

なお、tomcat を埋め込みで使い、さらに heroku にデプロイした例が heroku のサンプルにある。

実は、これを参考にして試行錯誤(まあ、今回も周囲の方々に訊きまくりましたが…orz)していたら、できてしまった。

Tomee を埋め込みで使う場合の裏技?

tomee 本家提供の maven plugin を使うのではなく、通常の maven plugin を使えばよかったのですね。

後で問題は出てくるのかもしれないが、とりあえずは動いた。

なお、railway でも同様のやり方でデプロイ可能。

煮詰まった時の打開策は、経験ある人とちょっとまだ差があるなあ(嘆息)。

同じ Java でしょ?

しかし、コミュニティの運営方針に若干違和感を感じた。

今回の件もそうだが、tomee 純正というか独自仕様に拘り過ぎという気がしないでもない。

通常 maven plugin が EE の仕様に従っていれば、そりゃ tomee でも動く(はず)。

なぜ、それを先に言わない???

そりゃ tomee 用の Application Runner があればそれに越したことはないが、現状だと all features are not yet supported だそうなので、本格的に採用するわけにいかない。

だから、「それが完成するまでは、伝統的な maven plugin を使っていてね」でいいんじゃない?

それを明言しないものだから、取っ付き辛さ→使用者がそれほどいない、という事態の一因になっている気がする。