| ←Older revision |
Revision as of 04:40, 28 April 2009 |
| Line 21: |
Line 21: |
| | === Double [[Injection]] === | | === Double [[Injection]] === |
| | | | |
| - | Yet, if there are extensions written according to the [[ServiceLoader|Java Extension]] mechanism or using the ''@ServiceProvider'' annotation offered by the [[Lookup]] library, one can have two [[JAR]] files with: | + | Yet, if there are extensions written according to the [[ServiceLoader|Java Extension]] mechanism or using the ''@ServiceProvider'' annotation offered by the [[Lookup]] library, one can have [[JAR]] files one with: |
| | | | |
| | <source lang="java" snippet="anagramdemo.springlookup.scrambler"/> | | <source lang="java" snippet="anagramdemo.springlookup.scrambler"/> |
| | | | |
| - | and another one with: | + | and another one with another class: |
| | | | |
| | <source lang="java" snippet="anagramdemo.springlookup.wordlibrary"/> | | <source lang="java" snippet="anagramdemo.springlookup.wordlibrary"/> |
| | | | |
| - | and it composition together becomes piece of cake. Instead of writing complicated binding [[XML]] file or doing inefficient on start scan of all resources in a package, one can just put all three [[JAR]] files into classpath and they look each other up effectively and unrestrainably.
| + | or even more [[JAR]]s with different implementations of the same interfaces. |
| | | | |
| - | In some sense this represent an example of double [[injection]]. First of all we instructed the [[Spring]] framework to do its [[Dependency Injection]] to provide necessary implementations to the ''Anagrams'' class constructor. Yet, these implementations are unknown at compile time of the [[JAR]] and they are not present in any single configuration file. Instead they are picked up from the runtime classpath by using ''Java Extension Mechanism'' as abstracted by [[Lookup]]''.getDefault()''. This is the second level of [[injection]] where the assembler injects various [[JAR]]s into effective application classpath.
| + | The composition of final application then becomes piece of cake. Instead of writing complicated binding [[XML]] file or doing inefficient on start scan of all resources in a package, one can just put selected [[JAR]] files into classpath and they look each other up effectively and unrestrainably. |
| | | | |
| - | I am not sure if this kind of ''double'' [[injection]] can be useful in web applications where developer is also kind of assembler putting everything together, but in [[Use Modular Architecture|modular applications]] it has its place. If you are interested, see and use the [[Spring]]/[[Lookup]] bridge: | + | In some sense this represent an example of double [[injection]]. First of all we instructed the [[Spring]] framework to do its [[Dependency Injection]] to provide necessary implementations to the ''Anagrams'' class constructor. Yet, these implementations are unknown at compile time of the [[JAR]] and they are not present in any single configuration file. Instead they are picked up from the runtime classpath by using [[ServiceLoader|Java Extension Mechanism]] as abstracted by [[Lookup]]''.getDefault()''. This is the second level of [[injection]] where the assembler injects various [[JAR]]s into effective application classpath. |
| | + | |
| | + | I am not sure if this kind of ''double'' [[injection]] can be useful in web applications where developer is also acting as assembler putting everything together, but in [[Use Modular Architecture|modular applications]] it has its place. If you are interested, see and use the [[Spring]]/[[Lookup]] bridge: |
| | | | |
| | * [http://hudson.apidesign.org/hudson/job/lookup/org.apidesign$spring-lookup/javadoc/ javadoc] | | * [http://hudson.apidesign.org/hudson/job/lookup/org.apidesign$spring-lookup/javadoc/ javadoc] |