総称型（Generics）は取得できない…？ - ようじのにっき
Seasar も Spring もいいんだけど、、なんか DI の為だけに開発者がインターフェイスつくるってルールもなんかなぁって思う今日この頃…。生産性、生産性…って言うなら、インターフェイス（の作成）を省く手段を考えるのもいいかなってことで、「javassist」使って、POJOのロジックからインターフェイスを自動生成する Eclipse のビルダーでも作ってみようかと。 んで、サンプル↓作ってみたところ、、、 CtClass ctClass = classPool.get("hoge.logic.impl.HogeLogicImpl"); // 実装済みの POJO … CtMethod[] ctMethods = ctClass.getMethods(); CtClass ctInterface = classPool.makeInterface("hoge.logic.HogeL
Spring JavaConfigのM2が出ました - あるまに
「4月5月に作業するよ」って言って、本当に5月上旬に出てくるのは偉いですね。 リリースのアナウンス ダウンロード バージョンアップ内容 新しいアノテーションの追加 scoped beansのサポート*1 エンハンスの改善 Petclinicサンプルの追加 追加されたアノテーション @ExternalBean 親のコンテナ設定（Application Contextの設定）を引き継ぐ @ScopedProxy scoped proxyの指定。これ今まで使った事無くて知らなかったのですが、例えばシングルトンBeanがセッションスコープBeanの参照を持っている時に、直接参照を持つと1つしかinjectされない（だってシングルトンだから）という問題をProxyで解消するもののようですね。proxy scopeが指定されると、プロキシの参照を持つようになって、呼び出し時にスコープに応じて適切に参照
ひがやすを blog - [etc]Guice vs. SpringJavaConfig (5) Conclusions
Guice vs. SpringJavaConfig (5) Conclusions Springの勝ちということになっていますね。ただ、だからGuiceがだめだと短絡的に思っては危険です。このアーティクルの著者は、@Injectを侵略的だとしてSpringのポイントにしていますが、これは人によって評価が分かれるところです。ただ、Spring派の人は、アノテーションが侵略的だと感じる傾向があるということは言えるかもしれません。だからSpringからEJB3へ移行する人も少ないのかも。EJB3もアノテーションでのDIですから。 後、AOPもSpringのポイントとしていますが、これもちょっと疑問。AspectJのポイントカットは、わかりにくいと思うんだけどなぁ。実際の案件で使っている人もわかりづらいといってました。 結局、Springな人がGuiceに移行するのは少ないのかもしれませんね。
![ひがやすを blog - [etc]Guice vs. SpringJavaConfig (5) Conclusions](https://cdn-ak-scissors.b.st-hatena.com/image/square/5e37ebe5efb38a32423841ba747d4cb2e5df13ac/height=288;version=1;width=512/https%3A%2F%2Fogimage.blog.st-hatena.com%2F17680117126970898857%2F17680117126970928023%2F1550549930)
Guice vs. SpringJavaConfig (5) Conclusions - レベルエンター山本大のブログ
Guice vs. Spring JavaConfig: A comparison of DI styles DIスタイルの比較：Guice 対 SpringのJavaコードコンフィグ http://jroller.com/page/habuma?entry=guice_vs_spring_javaconfig_a ■[翻訳]Guice vs. SpringJavaConfig (1) A Knight's tour of Guice ■[翻訳]Guice vs. SpringJavaConfig (2) Guice and AOP ■[翻訳]Guice vs. SpringJavaConfig (3) A Knight's tour of Spring JavaConfig ■[翻訳]Guice vs. SpringJavaConfig (4) Spring JavaConfig and
SpringFrameworkで命名規約ベースの設定を実現するArid POJOs - あるまに
記事のタイトルみたいですが、1行で言えばそういう事です。今まで（Springに）無かったのが不思議なくらいですね。 作者はPOJOs IN ACTIONの著者Chris Richardson氏。 では、早速使ってみます。 基本サンプル まず下記サイトからダウンロード。 Arid POJOsのWebサイト Guiceに続きGoogle Codeです。ちなみにオープンソースなホストではCodehausが一番尖ったイメージでかっこ良いと思います。私の中で。どうでも良いですね。 今回試すサンプルのパッケージ構成 sample.arid SimpleBootStrap : 起動クラス SimpleClient : サービス呼び出し元 sample.arid.service SimpleService : サービスインタフェース SimpleServiceImple : サービス実装 実装の中身は例に
Javassistを使った動的プロキシの作成
前回の「 動的プロキシとシリアライズ」エントリで紹介した通り，今回はその第一歩として，Javassistを使って動的プロキシを作成するための方法を紹介してみようと思う。 Javassistは，動的プロキシを作成するためのライブラリというよりは，バイトコードを操作するためのライブラリである。とは言っても，バイトコードに対する低レベルな処理は，Javassistに完全にお任せで大丈夫である。JavassistのAPIを使っている限りでは，バイトコードに関する知識はほぼ０で良い。Javassistを使うと，クラスファイルを作り出すこともできるし，ファイルとして生成しなくても，その場でClassオブジェクトとして利用することが可能である。生成したいクラスについて，親クラスやインタフェースを実装させることもできるし，フィールドやメソッドを追加することもできる。 では，さっそく例を見ていこう。まず，次
動的プロキシとシリアライズ
一般的なDIコンテナに大抵標準装備されている機能に，AOPがある。例えば，あるオブジェクトのあるメソッドが呼び出された際に，そのメソッドを処理する前に何らかの処理を挟み込む，などがAOPである。この機構を実現するためには，動的プロキシと呼ばれる機能が必要となる。 デザインパターンのProxyパターンは，あるオブジェクトと同等のインタフェースを持つProxyクラスを作成し，そのProxyクラスの中から本来のオブジェクトを呼びだすようにする。クライアントは本来のオブジェクトを触っている感覚なのだが，実際にはProxyクラスという「代理」のものが応答し，本来のオブジェクトを本当に呼び出すかどうかの判断とか，引数の内容を変更してしまったり，本来のオブジェクトからスローされる例外の処理をProxyクラス内でしてしまう，などの機能拡張をProxyクラスで行うというパターンである。クライアント側は，Pr
ベンチマークを更新しました - あるまに
SpringFramework 2.0.4で、ちょうどベンチマークに関係する部分のパフォーマンスチューニングを行ったとの事なので（詳しくは次のエントリ参照）、再度ベンチマークを行いました。Seasar2も最新版に入れ替えた上で、セットアップ処理コードを一部変更しています。 計測内容 バージョンは、Spring 2.0.4 / Guice 1.0 / Seasar2 2.4.12 インスタンス取得はAOP有りとAOP無しの両方を計測（前回は有りのみでしたが、今回は無しも計測しました） 全てプロトタイプ（毎回新しいインスタンスを取得） 取得したインスタンスの実行時間は、AOP有りのみ計測（AOP無しは変わらないはずなので） 留意して欲しい事項は前回の前置きにあります ベンチマーク結果 - get instance (NO AOP)- Spring: 24,336 creations/s Gui
Spring2.0.4でパフォーマンスが大幅向上 - あるまに
SpringFrameworkのBeanのインスタンス取得が最大12倍速くなったそうです。 2.0.4リリースアナウンスより引用 Regarding the performance improvements, repeated creation of Spring bean instances is up to 12 times faster in this release than previous versions of Spring 2.0. AspectJ-based weaving performance has also increased by a significant factor. 2.0.3と2.0.4のベンチマーク比較 既にベンチマークのエントリでも速くなったと書きましたが、せっかくなので2.0.3と比較してみました。コードはGuiceベンチマークを流用してます。数
Spring勉強会での発表資料を公開しました - あるまに
先日行われたJapan Springframework User Groupの勉強会でGuiceについてライトニングトークした資料を公開しました（アップロードありがとうございます＞岩永さん）。 ブログを読まれている方には新しい情報は無いと思いますが、よろしければどうぞ。 発表資料のダウンロードはこちらから また、PowerPointを閲覧できない方や落とすのが面倒な方は、SlideShareでどうぞ。 SlideShareの資料※何故かFAQの"A"が"C"になっちゃってますが、それ以外は上記資料と同じ内容です。
Spring Java Configuration(2) - あるまに
1回目に続き、Spring Java Configurationを試してみたいと思います。今回はAOP。ちなみに付属のドキュメントにはAOPの説明が無かったので（さすがM1リリース）、テストケースを参考に試してみます。 Spring Java ConfigurationでのAOP定義 injectするServiceのインタフェースと実装クラス、そしてinjectされるClient実装クラスは、前回と同じものを使用します。AOPは既存の実装を変更せずに透過的に処理を追加（変更）できるのが売りですから、当然と言えば当然です。 で、前回のコンフィギュレーションクラスにAOPの定義を追加して、インターセプタも書いちゃいます。 @Configuration public class SpringConfigurationWithAOP { @Bean public Service service()
Spring Java Configuration(1) - あるまに
Guiceと Springframeworkの最大の違いはDIやAOPの設定をJavaコードで書くかXMLで書くかですが、実は(?)SpringでもJava コードによる設定の記述手段が用意されています*1。今回はその"Spring Java Configuration"を簡単に見てみます。なお、まだマイルストーン1なので、用意されているというよりは準備されている、もしくは計画中と言う方が適切かも知れず、今回試す内容も今後のリリースで色々変わる可能性があります。 Spring Java Configurationの最も基本的なサンプル まずinjectされるサービス。インタフェースとその実装です。 public interface Service { String getResponse(String msg); } public class ServiceImpl implements
Springframework.org
Level up your Java™ code With Spring Boot in your app, just a few lines of code is all you need to start building services like a boss. New to Spring? Try our simple quickstart guide. Most [of our] services today are all based on Spring Boot. I think the most important thing is that [Spring] has just been very well maintained over the years...that is important for us for the long term because we d
Seasar - DI Container with AOP -
S2標準dicon Seasar2.4のサイトに自動的に切り替わらない場合は以下のリンクをクリックしてください。 S2標準dicon
The Seasar Foundation Project Site
利用者向け情報 ニュース & Wiki プロダクト一覧 メーリングリスト Eclipseプラグイン Mavenリポジトリ ライセンス 各種リソース イベントサイト ファウンデーションサイト 開発者向け情報 SeasarWiki ソースコードリポジトリ 課題追跡 継続的ビルド 開発者ログイン サーバチームサイト Java プロジェクト S2Container.Java Seasar2 (S2Container) Presentation.Java Cubby Mayaa mobylet S2BlazeDS S2Flex S2JSF S2OpenAMF S2Portlet S2Struts SAStruts Teeda Ymir Persistence.Java DBFlute Doma Kuina S2Dao S2Hibernate S2JDBC S2OpenJPA S2TopLink Co
ひがやすを blog - JavaからRubyへ -
http://d.hatena.ne.jp/higayasuo/20070417#1176813784の続き。 前回のエントリーでDIContainerが提供する機能で重要なのは AOP スコープ管理 で、IoCがDIContainerの敷居を高くしていると書きました。それでは、どうしたらよいのでしょうか。 必要なオブジェクトは、自分から取りにいけばよいのです。たとえば、AOPとスコープ管理を低要するFactoryクラスがあるとします。 public class Factory { public static T getInstance(Class<? extends T> type) { ... } }使うときには、次のように呼び出します。 Service service = Factory.getInstance(Serivice.class);このFactoryクラスを使ったときのC
ひがやすを blog - [DI]DIって本当に必要? その2
http://d.hatena.ne.jp/higayasuo/20070416#1176719022の続き。 それでは、DIContainerの機能で本当に必要な2つの機能って何でしょうか。一つは、インスタンスのスコープ管理です。スコープとは、singletonだとかprototypeのようにインスタンスが存在する範囲のことです。たとえば、singletonの場合は、いつ取得しても同じインスタンスが返ってきて、prototypeの場合は、取得するたびに新しいインスタンスが返ってきます。 このスコープ管理は、単純にオブジェクトをnewしているだけでは達成できません。以前のコードを見てみましょう。 Service service = new Service();これは、ある意味prototypeですが、これをsingletonにしたい場合、次のようなコードにする必要があります。 Servic
ひがやすを blog - [DI]DIって本当に必要?
http://www.commonsmedia.jp/cm/JavaAndSolarisCampaign blogでNetBeansやJavaEEについて書いて、トラックバックしたら先着100名にAmazonギフト券3000円分をプレゼントするそうです。id:nowokayさんのためのような企画です。 id:taediumさんもid:da-yoshiさんもぜひどうぞ。ただし、Seasar固有のことはできれば避けてねということです。 DIって本当に必要?たまにそう思うときがあります。DIによって開発は本当に楽になったのか。 DIのメリットでよく語られることとして、インターフェースと実装を分離し、機能の利用者側はインターフェースを通じて機能を利用することで、実装に直接依存しなくなり、後で実装を変更しても影響を受けなくなるということがあります。 実際後から、実装クラスを変更するということはめった
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Google Code Archive - Long-term storage for Google Code Project Hosting.
higaさんによるダイコン時代の設計方法 - tpircs