1. 無料アクセス解析

crossroad's Blog

Javaを中心にした技術ネタなど。

スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。
  1. --/--/--(--) --:--:--|
  2. スポンサー広告

Mavenトラブル事例-SCMプラグインでNoClassDefFoundError

。。。Mavenトラブル事例。。。

SCMプラグイン1.6で、Subversionにアクセスしようとした場合に。。。

> maven scm:update
>    :
> java.lang.NoClassDefFoundError: org/apache/regexp/RESyntaxException

が発生しました。

原因は、SCMプラグインの依存関係に、Jakarta Regexpが指定
されていない
ことでした。

対応としては、SCMプラグインのproject.xml(Windows環境であれば、
C:\Documents and Settings\ユーザ\.maven\cache\maven-scm-plugin-1.6\project.xml)
を修正し、Regexpへの依存関係を追加します。

<project>
     :
  <dependencies>
     :

    <dependency>
      <groupId>regexp</groupId>
      <artifactId>regexp</artifactId>
      <version>1.3</version>
    </dependency>

     :
  </dependencies>
</project>

スポンサーサイト

テーマ:JAVA - ジャンル:コンピュータ

  1. 2006/08/31(木) 23:12:35|
  2. ソフトウェア開発 Maven
  3. | トラックバック:0
  4. | コメント:0

The Street Slidersにハマる

今更ながら。。。The Street Slidersにハマりました。

以前からバンドメンバに進められてはいたのですが、音源の古さからくる
音のチープさもあってイマイチのめりこめませんでした。

が。。。最近、YouTubeにあがっているライブ映像を観て衝撃。
むちゃくちゃカッコ良い!音も良い!!

HARYYのボーカルの渋さ。荒削りな印象だけど妙に色気があります。
これに耳が慣れると他の男性ボーカルは聴けないです。

HARYYと蘭丸のギターの絡みがすごい。
弾きまくっているわけではなくて、絶妙なリズムと音数です。
ギターの音も良いですね!

JAMESのベースはこれまた派手さはないけれども、シンプルなフレーズ
でグルーブ感抜群です!!
ここのところコピーはしてなかったんですけど、コピーしたくなってきました。

最後にZUZUのドラム。ドラムは良くわからないけど、
歯切れの良いスネアの音が気持ちいいです。

全体に4人の音が絶妙に絡み合ってる感じです。まさにバンドサウンド!!

いや~早速DVDとか買っちゃいました。
秋にはHARRYのツアーもあるとかで、しかもベースはJAMES!!
これは行かねば!


  1. 2006/08/28(月) 23:41:04|
  2. 音楽
  3. | トラックバック:0
  4. | コメント:0

Mavenトラブル事例-jarゴールでStringIndexOutOfBoundsException

続・・・Mavenトラブル事例。

jarゴールを実行すると以下のようなエラーが発生しました。

java.lang.StringIndexOutOfBoundsException: String index out of range: 70
 at java.lang.String.substring(String.java:1765)
 at org.apache.tools.ant.taskdefs.Manifest$Attribute.writeValue(Manifest.java:347)
 at org.apache.tools.ant.taskdefs.Manifest$Attribute.write(Manifest.java:329)
 at org.apache.tools.ant.taskdefs.Manifest$Section.write(Manifest.java:504)
 at org.apache.tools.ant.taskdefs.Manifest.write(Manifest.java:912)
 at org.apache.tools.ant.taskdefs.Jar.writeManifest(Jar.java:396)
 at org.apache.tools.ant.taskdefs.Jar.initZipOutputStream(Jar.java:343)
 at org.apache.tools.ant.taskdefs.Zip.execute(Zip.java:410)
 at org.apache.tools.ant.Task.perform(Task.java:341)

原因はproject.xmlの記述でした。

<project>
   :
  <name>ほげほげほげほげほげほげほげ</name>
   :
  <organization>
    <name>ほげほげほげほげほげほげほげ</name>
  </organization>
   :
</project>

このように、project.name要素、project.organization.name要素に
長い日本語の値を指定していた
ことが問題でした。

これらの要素の値は、生成されるJarファイルのマニフェストに追記
されるのですが、その時に文字列を折り返そうとしてエラーが起こっているようです。

対応としては短い値にするか、1バイト文字での記述に修正します。
日本語でも短い値であったり、1バイト文字だけであれば問題は起こりません。

にしても次から次へとわかりにくい問題が起こる。。。



テーマ:JAVA - ジャンル:コンピュータ

  1. 2006/08/28(月) 23:26:17|
  2. ソフトウェア開発 Maven
  3. | トラックバック:0
  4. | コメント:0

Mavenトラブル事例-TomcatプラグインでJSPが文字化け

続々々Mavenトラブル事例。

Tomcatプラグイン1.2.1で、日本語を含むJSPをプリコンパイルすると、

 hoge_jsp.java:10: 警告: この文字は、エンコーディング MS932 にマップできません。

のような警告がでます。
そのままビルドはできますが、Tomcatにデプロイしてアクセスすると
日本語が文字化けしてしまいます。

原因は、JSPプリコンパイル時の文字コードが、UTF-8固定になっていることにあります。

JSPをプリコンパイルするTomcatのプリコンパイラ(org.apache.jasper.JspC)では、
生成するServletのソースコードのデフォルト文字コードがUTF-8になっています。
Windowsで開発している場合はソースコードはMS932で書くことが多く、
コンパイル時もMS932を指定するので、ここで文字化けが起こってしまうのです。

対応としては、TomcatプラグインのJellyスクリプトを改造するしかありません。
(Tomcatプラグインには、プリコンパイル時の文字コードを指定するプロパティ
は用意されていないようです)

Tomcatプラグインのplugin.jellyに、_jspcと言うゴールがあり、
その中でjasper2タスクが実行されるようになっています。

jasper2タスクには、javaEncodingプロパティが用意されているので、
これを使って文字コードを指定するようにすればOKです。

<jasper2 validateXml="false"
  uriroot="${maven.war.webapp.dir}"
  webXmlFragment="${maven.build.dir}/tomcat/src/WEB-INF/generated_web.xml"
  addWebXmlMappings="true"
  outputDir="${maven.build.dir}/tomcat/src/java"
  javaEncoding="MS932"/>

テーマ:JAVA - ジャンル:コンピュータ

  1. 2006/08/27(日) 01:00:19|
  2. ソフトウェア開発 Maven
  3. | トラックバック:0
  4. | コメント:2

Mavenトラブル事例-Maven1.0.xでTomcatプラグイン

続々Mavenでのトラブル事例。

Maven1.0.2で、Tomcatプラグイン1.2.xは使えません。

NoClassDefFoundError org/apache/tools/ant/taskdefs/Redirector
が発生します。

これは、Maven1.0.2にバンドルされているAntのバージョンが古い(1.5.3)のが原因です。
上述のクラスRedirectorはAnt1.6で新規追加されたクラスなので
当然Ant1.5.3環境では存在しません。

Maven1.0.2のAntを1.6.xにバージョンアップすることも試みたのですが、
あちこち不整合が起こるようで上手くいきません
でした。

結局、Ant1.6.xをバンドルしたMaven1.1.xを使うことで対処。
Maven1.0.2の方が安定しているのであえてそうしていたのですが。。。しょうがありません。

テーマ:プログラミング - ジャンル:コンピュータ

  1. 2006/08/26(土) 01:51:51|
  2. ソフトウェア開発 Maven
  3. | トラックバック:0
  4. | コメント:0

Mavenトラブル事例-TomcatプラグインでJCoverageレポート生成エラー

続Mavenでのトラブル事例。

Maven1.1で、TomcatプラグインとJCogerageレポートを併用した際、
以下の問題が生じました。

Tomcatプラグインで、JSPのプリコンパイルを有効にすると、
ROOT/target/tomcat/src 下に生成されたServletのソースコード
が出力されます。

この状態で、JCoverageレポートを生成すると。。。

jcoverage:html-report:
[report] jcoverage 1.0.5 copyright (c)2003 jcoverage ltd. http://jcoverage.com/
[report] jcoverage is licensed under the GNU General Public License
[report] jcoverage comes with ABSOLUTELY NO WARRANTY
Generate report for C:\\Hoge/target/jcoverage/coverage.xml
file.OutputDir = C:\\Hoge/target/docs/jcoverage
java.io.FileNotFoundException:
C:\\Hoge\\target\\docs\\jcoverage\\org\\apache\\jsp\package-frame.html
(指定されたパスが見つかりません。)
at java.io.FileOutputStream.open(Native Method)
at java.io.FileOutputStream.(FileOutputStream.java:179)
at java.io.FileOutputStream.(FileOutputStream.java:131)
at java.io.FileWriter.(FileWriter.java:73)
at org.apache.maven.jcoveragereport.CoverageReport.generateClassList(CoverageReport.java:162)
at org.apache.maven.jcoveragereport.CoverageReport.generatePackageList(CoverageReport.java:132)
at org.apache.maven.jcoveragereport.CoverageReport.generate(CoverageReport.java:59)
at org.apache.maven.jcoveragereport.CoverageReportGenerator.execute(CoverageReportGenerator.java:68)

とエラーが発生します。

これは、JCoverageレポートが、プリコンパイルで生成されたServletの
カバレージを計測しようとしたが、ソースディレクトリに
ROOT/target/tomcat/src が含まれていないことが原因です。


対応はいくつかの設定が必要です。

--- maven.xml ----------------------------------------
1: <preGoal name="jcoverage:html-report">
2:   <!-- TomcatプラグインのプリコンパイルJSPのソースパス -->
3:   <j:set var="location.precompiledjsp.src" value="${maven.build.dir}/tomcat/src/java"/>
4:
5:   <available file="${location.precompiledjsp.src}" type="dir"
6:    property="exists.precompiledjsp" value="true"/>
7:   <j:if test="${exists.precompiledjsp}">
8:     <ant:path id="my.other.src.dir" location="${location.precompiledjsp.src}"/>
9:     <maven:addPath id="maven.compile.src.set" refid="my.other.src.dir"/>

10:   </j:if>
11: </preGoal>

このように、JCoverageレポートのpreGoalを追加し、プリコンパイル
されたServletの所在をソースディレクトリに追加します。


ポイントは、5~7行目です。
ここで、プリコンパイのディレクトリの存在チェックを行い、
存在しない場合は、ソースディレクトリを追加しないようにします。
こうしておかないと、今度は逆にプリコンパイルしていない状態で
JCoverageプラグインがエラーになってしまいます。

--- project.properties --------------------------------
# プリコンパイルされたJSPソース(org.apache.jsp.xxx_jsp.class)は、カバレージ検査対象から外す
>maven.jcoverage.instrumentation.excludes = org/**/*.*

次に、プリコンパイルされたServletをJCoverageレポートの対象から外します。
プリコンパイルされたServletのJUnitテストなんて書いているわけがないので、
JCoverageの対象にすると、カバレージが下がってしまう為です。


こうして見てみると、Mavenのプラグイン群は、組み合わせの相性が脆弱である
といわざるを得ません。
1つの組織で開発しているわけではなく、多くのオープンソースコミュニティ
によって開発されているので、しょうがないとは思いますが。。。


テーマ:プログラミング - ジャンル:コンピュータ

  1. 2006/08/26(土) 01:38:10|
  2. ソフトウェア開発 Maven
  3. | トラックバック:0
  4. | コメント:0

Mavenトラブル事例-プロパティ名にハイフンは使えない

Mavenでのトラブル事例。

。。。にしてもMaven(1.x。2.xは試してないので知りませんが)はデリケートです。
ちょっとプラグインのバージョンが違うだけで、それまで動いていたものが
動かなくなったり、問題が発生しているのにエラー表示なく正常終了したり。

プラグインの品質にもややバラツキがあり、Maven本体のバージョンアップと
同期してメンテナンスされていないものも少なくないようです。

と、文句はこのくらいとして。。。

今回はプロパティの命名でハマりました。
maven.xmlに自作のゴールを書き、prject.propertiesでそのゴール
で使うプロパティを定義しました。

 --- maven.xml ------------------------------
 <goal name="hoge:hoge">
  <echo message="value = ${hoge.a-b}"/>
 </goal>

 --- project.properties ---------------------
 hoge.a-b = HOGEHOGE

これを実行すると。。。

  __ __
 | \/ |__ _Apache__ ___
 | |\/| / _` \ V / -_) ' \ ~ intelligent projects ~
 |_| |_\__,_|\_/\___|_||_| v. 1.0.2
 build:start:
 hoge:hoge:
  [echo] value = 0
 BUILD SUCCESSFUL
 Total time: 3 seconds

定義したプロパティ hoge.a-b の値が取得できず、'0'になっています。

原因は、プロパティの名前に'-'(ハイフン)を使っていることでした。
ハイフンを取り除いて、プロパティ名を hoge.ab に変更すると。。。

  __ __
 | \/ |__ _Apache__ ___
 | |\/| / _` \ V / -_) ' \ ~ intelligent projects ~
 |_| |_\__,_|\_/\___|_||_| v. 1.0.2
 build:start:
 hoge:hoge:
  [echo] value = HOGEHOGE
 BUILD SUCCESSFUL
 Total time: 3 seconds

ちゃんとプロパティの値が取得できました。

'-'等は命名によく使うのですが、こんな落とし穴があったとは。

テーマ:プログラミング - ジャンル:コンピュータ

  1. 2006/08/24(木) 23:10:03|
  2. ソフトウェア開発 Maven
  3. | トラックバック:0
  4. | コメント:0

トリビアの泉での検証方法

今トリビアの泉をやってますが、トリビアの種でオナラの臭いを
体から消す(離す)にはどうすれば良いか、と言う検証をやってました。

以前から思っていたのですが、なにげにトリビアの泉の検証は高度だと思います。

つまり、視聴者からの漠然とした問いかけに対して、
・明確なゴールを設定する。
・どうすればゴールにたどり着けるか、あるいはどれだけの条件を満たせば
 ゴールに到達できるかを考える。
・ゴールにたどり着くまでに何をしなければならないか、シナリオを考える。
・とっかかりとなる仮定を立てる。
・シナリオに従い、順次検証して行く。
といったことをやっています。

普段、仕事をしていて常々思っているのですが、このように仕事に対して
ゴールを明確にし、着実に仕事を進めていくというのはなかなか難しいものです。

人間、考えなくてもわかるところ、楽なところからやろうとするので、
どうしても行き当たりばったりになりがちです。
その結果、あれこれとやってはみたものの結局目的は果たせずに
無駄な労力を使ってしまった、と言う事も少なくありません。

仕事の進め方で悩んだ時は、トリビアを思い出してみよう。

  1. 2006/08/23(水) 21:37:20|
  2. 日記
  3. | トラックバック:0
  4. | コメント:0

Maven1.xでSeasar関連ライブラリを扱う

Maven 1.1 beta-3 で、Seasar2 に依存したプロジェクトをビルドする時の問題。

○問題1 SeasarファウンデーションのMavenリポジトリ
 Seasar2関係のライブラリは、標準のリモートリポジトリである
 ibiblioでは公開されていないようで、
 Seasarファウンデーションの公式サイトにリポジトリ
があります。

 ここでは、Maven1.x用と、Maven2.x用のリポジトリが用意されている
 ようなのですが、Maven1.x用の方はメンテナンスされておらず、
 ライブラリが古いままで更新が止まっています。

 この問題は、既に他の方が解決されていて、ここ
 に対応方法が書かれています。
 (参考になりました。ありがとうございました。)

 
○問題2 ライブラリをダウンロードできない
 問題1の対応方法に従って対応したところ、


  「s2-framework-2.3.11.jar」のダウンロードを試みています。
  警告:s2-framework-2.3.11.jar のダウンロードに失敗しました。
  ビルドのプロセスを続ける事が出来ません。以下の依存関係が満たされていない為です:
  s2-framework-2.3.11.jar


 と言うエラーが発生し、ライブラリをダウンロードできません。
 Mavenの-Xパラメタを指定してデバッグ情報を出力してみると。。。

  Trying to get missing/snapshot dependencies required by Maven Web Application:
  「s2-framework-2.3.11.jar」のダウンロードを試みています。
   :
   略
   :
  http://maven.seasar.org/maven//org.seasar.container/jars/s2-framework-2.3.11.jar - Status code: 404 File not found on one of the repos
  org.apache.maven.wagon.ResourceDoesNotExistException: File: http://maven.seasar.org/maven//org.seasar.container/jars/s2-framework-2.3.11.jar does not exist
   at org.apache.maven.wagon.providers.http.HttpWagon.get(HttpWagon.java:321)
   at org.apache.maven.wagon.providers.http.HttpWagon.getIfNewer(HttpWagon.java:231)
   at org.apache.maven.verifier.DependencyVerifier.getRemoteArtifact(DependencyVerifier.java:418)
   at org.apache.maven.verifier.DependencyVerifier.getDependencies(DependencyVerifier.java:292)
   at org.apache.maven.verifier.DependencyVerifier.satisfyDependencies(DependencyVerifier.java:185)
   at org.apache.maven.verifier.DependencyVerifier.verify(DependencyVerifier.java:104)
   at org.apache.maven.project.Project.verifyDependencies(Project.java:582)
   at org.apache.maven.plugin.PluginManager.attainGoals(PluginManager.java:679)
   at org.apache.maven.MavenSession.attainGoals(MavenSession.java:264)
   at org.apache.maven.cli.App.doMain(App.java:546)
   at org.apache.maven.cli.App.main(App.java:1390)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
   at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:585)
   at com.werken.forehead.Forehead.run(Forehead.java:551)
   at com.werken.forehead.Forehead.main(Forehead.java:581)
  警告:s2-framework-2.3.11.jar のダウンロードに失敗しました。
  
 URLに、...maven//org.seasar.container...と、スラッシュが2つ付いてしまっています。
 原因は、Mavenの実装にあるようです。
 (Mavenのバグ?と言うか想定外の使い方なのでしょうがないんでしょうが)

 対応としては、artifactIdの先頭に"../"を付与して無理やりURLを補正すると、
 とりあえずうまくダウンロードできました。(他に問題が出るかもしれませんが。。。)

 例えば、
   <dependency>
     <groupId>../org.seasar.container</groupId>
     <artifactId>s2-framework</artifactId>
     <version>2.3.11</version>
     <properties>
      <war.bundle>true</war.bundle>
     </properties>
   </dependency>
 のような感じです。



やっぱりもうMaven2.xに移行するべきなのかな。

テーマ:プログラミング - ジャンル:コンピュータ

  1. 2006/08/15(火) 21:40:32|
  2. ソフトウェア開発 Maven
  3. | トラックバック:0
  4. | コメント:2

javadocでIllegalArgumentException

現在参画しているプロジェクトの開発環境構築のため、
あれこれと試していると、JavaDoc生成で例外が発生。


[javadoc] 全パッケージとクラスの階層ツリーを作成しています...
[javadoc] C:\\hoge\\HelloWorld.htmlの生成
[javadoc] java.lang.IllegalArgumentException
[javadoc] at sun.net.www.ParseUtil.decode(ParseUtil.java:183)
[javadoc] at sun.misc.URLClassPath$FileLoader.(URLClassPath.java:860)
[javadoc] at sun.misc.URLClassPath$3.run(URLClassPath.java:316)
[javadoc] at java.security.AccessController.doPrivileged(Native Method)
   :
  以下略


こんなことは初めてだったのですが、あれこれ調べているとWeb上に情報が。
http://forum.java.sun.com/thread.jspa?tstart=0&forumID=41&threadID=551665&trange=15

どうやら、環境変数CLASSPATHの設定が悪さをしているらしい。
確かに

 > set CLASSPATH=

として、CLASSPATHをクリアしてやるとエラーにならずにjavadocを実行できます。

CLASSPATH設定のどこがマズかったのかと言うと、既に存在しないjar
ファイルへの参照が含まれていたのが原因だったようです。
CLASSPATHからこの記述を削除することで問題解決しました。

テーマ:プログラミング - ジャンル:コンピュータ

  1. 2006/08/12(土) 02:26:42|
  2. ソフトウェア開発 Java
  3. | トラックバック:0
  4. | コメント:0

S2Daoの例外ハンドリング

S2Daoを使ったアプリケーション設計を考えているのですが、
ひとつ課題に直面しました。

それはS2Daoが送出する例外です。
S2Daoはデータベースアクセス時にエラーが発生すると、
実行時例外を投げます。


この時、例外の種類によってはエラーとはせずに、アプリケーション
内部でハンドリングしたい場合があります。

例えば、レコード更新時の楽観的排他制御に引っかかった場合、
NotSingleRowUpdatedRuntimeExceptionが送出される
ようなのですが、この場合はエラーとはせずに例外を無視したり、
リトライを試みる、などです。

このような例外ハンドリングをする場合は、その例外の型を
知っておかなければなりません。


ここで問題なのが、S2Daoはインターフェースとして定義し、
実装(ロジック)を記述しない(しなくて良い)と言う点です。
つまり、例外ハンドリングはDaoではできず、その呼び出し元である
ビジネスロジックで行なうことになります。
と言う事は、ビジネスロジックが例外の型を知っておく必要があり、
ビジネスロジックがS2DaoのAPIに依存してしまうことになります。

J2EEのWebアプリケーションで一般的な多層アーキテクチャでは
各層の依存関係を持たせたくないので、上記のように
ビジネスロジック層がデータアクセス層の実装に依存してしまうのは
望ましくないと思っています。


はて、どうしたものか。。。と思っていたのですが、
S2AOPのThrowsInterceptorを使うことを思いつきました。
S2Daoで作ったDaoに対して、ThrowsInterceptorを設定することで、
上記のようなS2Dao固有の例外をキャッチし、抽象的な例外で
ラップして送出します。

public class S2DaoThrowableInterceptor extends ThrowsInterceptor {
 public void handleThrowable(
    NotSingleRowUpdatedRuntimeException e,
    MethodInvocation invocation) throws Throwable {
  throw new DaoException(e);
 }
}


のような感じです。
ここで送出しているDaoExceptionはアプリケーションで独自に定義
した例外で、S2Dao等の特定のプロダクトに依存しません。

そして、このアスペクトをDaoに設定するdiconファイルは以下のようになります。

<components>
 <component
  name="s2DaoThrowableInterceptor"
  class="hoge.S2DaoThrowableInterceptor"/>


 <component class="hoge.IHogeDao">
  <!-- dao.interceptorより前に記述しないと機能しない -->
  <aspect>s2DaoThrowableInterceptor</aspect>
  <aspect>dao.interceptor</aspect>
 </component>
</components>

※S2Daoへのアスペクトの追加は、dao.interceptorより前に記述しないと
 追加したアスペクトが機能してくれませんでした。


こうすることで、ビジネスロジック層ではDaoExceptionを受け取る
ことになり、S2Dao固有の例外を意識しなくて済むはずです。

これで、一件落着。
しかしもっとシンプルな方法がありそうな気も。。。

テーマ:プログラミング - ジャンル:コンピュータ

  1. 2006/08/11(金) 01:04:09|
  2. ソフトウェア開発 Seasar
  3. | トラックバック:0
  4. | コメント:0

DIコンテナの価値・メリット

昨今のJavaによるシステム開発(特にWebアプリケーション)では、
DIコンテナの使用が当たり前のようになってきています。

今回、僕が参画したプロジェクトでも、Seasar2の採用を検討しています。

しかし、ここで周囲の人から「DIコンテナって何がうれしいの?」
という質問が。
うーむ、すぐに思いつくところでは、
 1.オブジェクト間の直接的な依存関係を排除でき、オブジェクトの
  再利用性や保守性が高まる。
 2.アスペクト指向技術との組み合わせによって、トランザクション管理
  と言った非業務ロジックを任せることができる。
 3.インターフェースベースの設計が促進され、オブジェクトの責務
  が明確化すると共にシステムの品質向上に繋がる。
 4.モックやスタブへの切替えが用意になり、ユニットテストがし易くなる。
と言ったところでしょうか。。。

しかし、他の類フレームワーク...MVCフレームワークやO/Rマッピング
フレームワークなど...に比べると効果が直感的にわかりにくいです。
ある程度、Javaでの開発経験があれば理解してもらえますが、
そうではない人(マネージャや業務SEの方)にはなかなかDIコンテナ
の利点を理解してもらえません。

考えてみると、DIコンテナはそれを使えば効果が表れるものではなく、
良い設計ができてこそ効果を発揮するのではないかと言う事です。
(DIコンテナに限らず、何でも使えば良いってものではないですが)

再利用性や拡張性、保守性を高めようと設計していくと、自ずと
オブジェクト間の依存関係を弱めようと考えます。
インターフェースを使うことで、オブジェクト同士の結合度を
下げようとするわけです。

が、例えインターフェースを利用しても、必ずどこかにオブジェクト
の依存関係を記述しなければなりません。
これまでは、主にAbstract FactoryやFactory Methodといった
デザインパターンを使うことで、この「依存関係を記述する場所」
を一元化していたのですが、それでもプログラムに依存関係を
埋め込むことには変わりありません。

そこで、DIコンテナを使いたいと言う動機が産まれます。
DIコンテナを使えば、DIコンテナの定義ファイルに依存関係を
記述するので、プログラムからは依存関係の記述を排除できます。

このように、「良い設計とは何か」「それを実現するにはどうするか」
と言うストーリーを理解してはじめてDIコンテナの価値が
わかるのではないかと思います。

逆に、良い設計ができなければ、DIコンテナのメリットを充分に
活かすことができません。

DIコンテナを使うには、多層アーキテクチャや、J2EEパターン、
アーキテクチャパターンなどの知識も必要になってくるのではないでしょうか。


テーマ:プログラマの憂鬱 - ジャンル:コンピュータ

  1. 2006/08/08(火) 21:52:02|
  2. ソフトウェア開発 Seasar
  3. | トラックバック:0
  4. | コメント:2

プロフィール

Author:crossroad
関西在住。男。
フリーランスのソフトウェアエンジニア。
エレキベース(Rock&Roll)とお酒が好物でございます。

カテゴリー

タグリスト

Java F1 フリーランス ベーシスト HARRY TheStreetSliders iPhone FX お酒 Seasar Maven eclipse Wicket マイホーム 野球 プロジェクトファシリテーション Rails Ruby UML お店 ソフトウェア Tomcat S2Flex2 jsf Teeda Eclipse タグライブラリ ajax タスク europa mylyn trac 

ブログ内検索

最近の記事

最近のコメント

最近のトラックバック

カレンダー

07 | 2006/08 | 09
- - 1 2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30 31 - -

月別アーカイブ

全ての記事を表示する

全ての記事を表示する

Twitter


RSSフィード

リンク

このブログをリンクに追加する

アクセスカウンタ

上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。