Logger を Spring に DI させれば同じようなコードを毎回書かなくて済むしテスト記述性も改善できる - ~saiya/hatenablog
SLF4J などの Logger を使うときに、毎回以下のようなボイラープレートを書くのにうんざりしていませんか？ 少なくとも私は大変うんざりしています: class TestController { // Kotlin Example companion object { private val log = LoggerFactory.getLogger(TestController::class.java) } // 長くてつらい... } class TestController { // Java Example private static final Logger LOG = LoggerFactory.getLogger(TestController.class); // これは 1 行だが、とはいえ長いし class 名を二度書くのが辛い & コピペ間違いも起こしやすい }
Springのproxyとfinalメソッド、それからnull — 裏紙
SpringのRepositoryとComponentアノテ、動きに違いがあるのか、、 Repositoryだとフィールドがnullになってハマった — こざけ (@s_kozake) 2018年2月17日 ようやく🍥Repositoryでフィールドの値がnullになる原因が分かった、、 メソッドをfinal指定してました サブクラスベースのProxyではメソッドやクラスにfinalをつけてはいけないとあれほど_:(´ཀ`」 ∠): — こざけ (@s_kozake) 2018年2月19日 ここら辺、どこか詳しい資料ありますか？ CGLIBを用いてサブクラスベースのProxyを実現している状況で、メソッドをfinalにした場合、内部でどのような状況になってnullのインスタンスを見るようになったかという まあ、そもそもfinal切るなって話なのですが — こざけ (@s_kozake)
Guiceで簡易的なプラグインシステムを構築するには | さにあらず
Java 界隈には OSGi といういかついダイナミックモジュールシステムがあるのですけども、これは解決しようとしている問題の量が非常に多いのでちょっとしたものを作るために使おうとすると非常に辛い。 そもそも、アプリケーションのブートストラップ部分から全部 OSGi ベースで作りこまないと良い感じに動いてくれません。 そこで、OSGi を前提としたアーキテクチャ設計が必要になるのですけども、ちょっと便利なツール作りたいだけなのに膨大な時間をかけて OSGi を勉強するかと言われると、しませんよね。 という訳で、Java において簡易的なプラグインシステムを Guice で作ってみましょうという話です。 尚、Spring 界隈で実現する方法については@makingさんのエントリをどうぞ。 DI コンテナで実現する簡易プラグイン機構コードの場所#必要に応じてエントリ内にコードはありますが、実際
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Google Guice 使い方メモ - Qiita
