ラベル Java の投稿を表示しています。 すべての投稿を表示
ラベル Java の投稿を表示しています。 すべての投稿を表示

2017年3月24日金曜日

【技術メモ】SpringCloudAWS が ECS TaskRole を使わない問題を突破する

サーバー運用っていいですよね。(1ヶ月20日ぶり2回目)

最近作っているサービスはその性質も相まってコンテナでの動作と相性が良さそうなので、基本的には Docker Container として動くことを前提に環境周りを構築しました。

すいません。うそです。適当に言いました。

実際の運用はご多聞に洩れず AWS ECS を使っています。
が、あまり情報が無いのも事実で何か起こる度に調査やら前に進まない試行錯誤やらで MP aka 精神力 を激しく削られるのも事実ではあります。

なにより日本語の情報が「とりあえず動かしてみた」的なものしかなく、実際ハマった内容なんかは大体 StackOverflow あたりを探すか SpringBoot 関連の issue 漁るかくらいしか方法がない。

とはいえ、実務上での利用が増えてこないとこういう事例自体出てこないと思うので、では実務上で使ってハマったのだから公開していこう、とそんな感じです。

さて。

今回は Spring Cloud AWS を利用していてある機能が動かなかったことから始まりました。
Spring Cloud for Amazon Web Services

どうやってその現象の理由を探したのか、結局どういう方法をとって解決したのかを遡ってみたいと思います。

2016年8月24日水曜日

【Kotlin】Java から Kotlin への移植中に起きた private メンバ参照エラー

とある既存の Java の (SplingBoot) プロジェクトを Kotlin に移植中、突如 build が通らない現象が起こりまして。

なんでかなー?
Kotlin 的には Getter を class に差し込むし、この記述で Private な訳ないんだけどなー?

という現象に引っかかったので久々の技術メモを。

結論としては、 Gradle の Java plugin と Kotlin plugin と Lombok の中がよろしくないということのようで


  • Kotlin は compileJava が dependsOn されているので先に compileJava が走る。
  • その後に compileKotlin される。
  • 結果、参照している Lombok で実装しているクラスのメンバは Delombok される前なのですべて Private なので当然エラーになる。


という流れでした。

状況を説明するためのテストコードとしてはこんな感じです。



ことの発端になったログはこんな感じでした。
$ ./gradlew build
:compileKotlin
e: /home/hoge/repos/LombokConflict/src/main/kotlin/Application.kt: (3, 15): Cannot access 'id': it is 'private' in 'DataModel'
e: /home/hoge/repos/LombokConflict/src/main/kotlin/Application.kt: (4, 15): Cannot access 'description': it is 'private' in 'DataModel'
:compileKotlin FAILED
FAILURE: Build failed with an exception.
@Data 指定してあるし、Getterいるしなんでだろう?

と思ったので、 DeLombok したコードの状態で build すると

$ ./gradlew build
:compileKotlin
:compileJava
:processResources UP-TO-DATE
:classes
:jar
:assemble
:compileTestKotlin UP-TO-DATE
:compileTestJava UP-TO-DATE
:processTestResources UP-TO-DATE
:testClasses UP-TO-DATE
:test UP-TO-DATE
:check UP-TO-DATE
:build 
BUILD SUCCESSFUL 
Total time: 8.041 secs

BUILD SUCCESSFUL!!!

Google翻訳「成功したビルド」




Compile が通るんですよ。

で、こりゃ gradle の流れがおかしいか?と思って調べてみた結果。


http://stackoverflow.com/questions/35517325/kotlin-doesnt-see-java-lombok-accessors

唯一の回避策としてはコンパイル順序を制御することだ、とありますが上のとおり Gradle の pulugin 経由だともはやどうしようもなさそうです。

公式でも同じ内容があって、


なんか似たようなこと言ってますね。
module を分けるなどをすれば問題ない。
論理的根拠は Kotlin はバイトコードからそれらを参照するが Lombok は On the fly でそれらを生成する。
だそうで。

PreCompiler と PostCompiler の違い、と言ってしまえばそれまでな気はしますし、だからといってお互いに修正する方向には来ないんだろうなーという気もしています。

結局、既存プロジェクトを Kotlin へ順次移行するのは Lombok と衝突する。
似たもの同士、近くによるとロクなことがない、という人生教訓になりましたとさ。

めでたくないです。つらいです。

ということで、 Java 、とくに SpringBoot で作られた既存のプロジェクトを Kotlin に移植するのは一気にやるか、またはサブプロジェクトとスコープを調整し直すかなにかしないといけませんよ、ということのようです。

特に Annotation もりもりの SpringBoot の移植はそれなりの規模になると、ちょっと気合入れて手を入れないと厳しそうな感じでしょうか。

今回のソースコード一式はこちら。

https://github.com/grim13b/LombokConflict


2013年8月3日土曜日

【Java】ドラゴンクエスト1のふっかつのじゅもんをつくる何かを作ってみた

もともと仕事上、誰かにソースを公開することがまず無くあまり人様に自分の書いたソースコードをお見せする機会も中々なく、最近はヘッドホンの改造記事とかばかりなので、たまには技術メモらしいことをしてみようということで、そんなに需要もなかろうと思い死蔵させていたソースを公開することにしました。

その名も
ふっかつのじゅもんびるだー
です。

センスないですね。

これをライブラリにしたAndroidアプリもあるのですが、そっちはまた別の機会にでも公開しようと思います。

一応簡単な使い方的なのはREADMEに書いて有りますが詳しくはtestあたりを適当に見てください。

なお、このプログラムはSATOH_Yoshiyuki氏の記事と掲載されているソースコードをパクリ元に作成されました。
氏の公開された情報と姿勢に感謝いたします。

「復活の呪文」資料室


普通こう書かないな?とか、なんかバグってない?とか、そんなのがありましたらツッコミください。

あ、でもマサカリとかだと心が折れてしまうのでやさしくおねがいします。

ドラゴンクエスト用ふっかつのじゅもんビルダー
http://grim13b.github.io/FukkatsuNoJumonBuilder/