Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP
Browse files

Update docs to reflect removal of path-specific scanning feature

  • Loading branch information...
commit 8a065c7961b7b3e37a94d530e266da4ae8a52529 1 parent c69745d
@sbohlen sbohlen authored
View
85 doc/reference/src/codeconfig-context.xml
@@ -40,19 +40,14 @@
that Spring.NET uses to perform dependency injection. In the case of
XML-based configuration sources, XmlApplicationContext parses XML files to
populate the metadata model. In the case of CodeConfig, the
- <literal>CodeConfigApplicationContext</literal> scans one or more folders
- for assemblies containing one or more types attributed with the <link
+ <literal>CodeConfigApplicationContext</literal> scans one or more
+ assemblies containing one or more types attributed with the <link
linkend="configuration-attribute-reference"><literal>[Configuration]</literal></link>
attribute, parses them to construct appropriate
<literal>ObjectDefinition</literal> instances, and registers those Object
- Definitions with the <literal>IApplicationContext</literal> for use. The
- default folder for scanning is the runtime directory and scanning is done
- using the 'ReflectionOnly' facilities in the BCL so only the assemblies
- that have the <link
- linkend="configuration-attribute-reference"><literal>[Configuration]</literal></link>
- attribute will be loaded into the AppDomain. You can also mix-and-match
- configuration sources, with some object definitions coming from XML and
- others from code.</para>
+ Definitions with the <literal>IApplicationContext</literal> for use. You
+ can also mix-and-match configuration sources, with some object definitions
+ originating in XML and others in code.</para>
<sect2>
<title>Using the CodeConfigApplicationContext</title>
@@ -151,26 +146,11 @@ public class DataModuleConfigurationClass
<sect1>
<title>Scanning Basics</title>
- <para>The default folder for scanning is the runtime directory and
- scanning is done using the 'ReflectionOnly' facilities in the BCL so only
- the assemblies that have the <link
- linkend="configuration-attribute-reference"><literal>[Configuration]</literal></link>
- attribute will be loaded into the AppDomain. The behavior of the
- <literal>CodeConfigApplicationContext</literal> scanning operation can be
- controlled by the following constraints:</para>
+ <para>The behavior of the <literal>CodeConfigApplicationContext</literal>
+ scanning operation can be controlled by the following constraints:</para>
<itemizedlist>
<listitem>
- <para><emphasis>Scan Root Path</emphasis></para>
-
- <para>The directory specified by this value and all subdirectories
- beneath it will be recursively scanned for assemblies and types
- matching all other constraints; defaults to the current AppDomain's
- 'bin' or run-time directory. In most common usage scenarios, this
- value will rarely need to be changed.</para>
- </listitem>
-
- <listitem>
<para><emphasis>Assembly Inclusion Constraint</emphasis></para>
<para>Only assemblies matching this contraint will be scanned;
@@ -212,10 +192,10 @@ ctx.Refresh();</programlisting>
<sect2>
<title>Scanning specific assemblies and types</title>
- <para>While the scanning process is very performant, say as compared to
- the overhead of parsing XML files, you may want to control the scope of
- the scanning operations to match your deployment or other usage models.
- To facilitate control of the scope of the scanning operation, the
+ <para>While the scanning process is very rapid (as compared to the
+ overhead of parsing XML files) you may want to control the scope of the
+ scanning operations to match your deployment or other usage models. To
+ facilitate control of the scope of the scanning operation, the
<literal>CodeConfigApplicationContext</literal> provides several
<literal>.ScanXXX()</literal> methods that accept constraints to be
applied to the assemblies and types during the scanning process. The
@@ -238,7 +218,7 @@ ctx.Refresh();</programlisting>
<row>
<entry><literal>ScanAllAssemblies()</literal></entry>
- <entry>Scans all assemblies, excpect those in the .NET BCL and
+ <entry>Scans all assemblies, except those in the .NET BCL and
Spring distribution</entry>
</row>
@@ -259,17 +239,6 @@ ctx.Refresh();</programlisting>
</row>
<row>
- <entry><literal>Scan(string assemblyScanPath,
- Predicate&lt;Assembly&gt; assemblyPredicate,
- Predicate&lt;Type&gt; typePredicate)</literal></entry>
-
- <entry>Scans the provided <literal>assemblyScanPath</literal>
- for assemblies that match the
- <literal>assemblyPredicate</literal> and types that match the
- <literal>typePredicate</literal></entry>
- </row>
-
- <row>
<entry><literal>Scan(Predicate&lt;Assembly&gt;
assemblyPredicate, Predicate&lt;Type&gt;
typePredicate)</literal></entry>
@@ -326,7 +295,7 @@ ctx.ScanWithAssemblyFilter(IsOneOfOurConfigAssemblies);</programlisting>
<para>None of this is anything other than simple .NET Delegate handling,
but its important to take note that the full flexibility of .NET
- Delegates and lamda expressions is at your disposal for formulating and
+ Delegates and lambda expressions is at your disposal for formulating and
passing scanning constraints.</para>
</sect2>
@@ -446,14 +415,10 @@ ctx.ScanWithTypeFilter(type =&gt; type.FullName.Contains("Config");</programlist
<programlisting language="csharp">var ctx = new CodeConfigApplicationContext();
ctx.Scan(assy =&gt; assy.FullName.Name.BeginsWith("Config"), type =&gt; type.Name.Contains("Infrastructure"));</programlisting>
- <para>For even more control over the scanning, you can provide a root
- scan path to the <literal>.Scan(...)</literal> method as well as shown
- in the following sample:<programlisting language="csharp">var ctx = new CodeConfigApplicationContext();
-ctx.Scan("c:\\MySpecialFolder\\MyConfigAssemblies", assy =&gt; assy.FullName.Name.BeginsWith("Config"), type =&gt; type.Name.Contains("Infrastructure"));</programlisting>Note
- that it is not possible to exclude specific types from the scanning
- process using these overloads of the <literal>.Scan(...)</literal>
- method. To get type-exclusion control, you must instantiate and pass in
- your own instance of the
+ <para>Note that it is not possible to exclude specific types from the
+ scanning process using these overloads of the
+ <literal>.Scan(...)</literal> method. To get type-exclusion control, you
+ must instantiate and pass in your own instance of the
<literal>AssemblyObjectDefinitionScanner</literal> as described in the
following section(s).</para>
</sect2>
@@ -471,22 +436,6 @@ ctx.Scan("c:\\MySpecialFolder\\MyConfigAssemblies", assy =&gt; assy.FullName.Nam
process.</para>
<sect3>
- <title>Controlling the Root of the Scanning Path</title>
-
- <para>The contructor for the
- <literal>AssemblyObjectDefinitionScanner</literal> provides an
- overload that accepts the fully-qualified path at which the scan will
- begin the search for assemblies and types. As mentioned elsewhere, if
- this path is not provided it will default to the root of the
- currently-executing AppDomain.</para>
-
- <programlisting language="csharp">//start the scan at special location for the assemblies containing [Configuration]-attributed types
-var scanner = new AssemblyObjectDefinitionScanner("c:\\MySpecialConfigurationLocation\\MyFavoriteConfigAssemblies");
-var ctx = new CodeConfigApplicationContext();
-ctx.Scan(scanner);</programlisting>
- </sect3>
-
- <sect3>
<title>Scanning Specific Assemblies and Types</title>
<para>The <literal>AssemblyObjectDefinitionScanner</literal> provides
View
18 doc/reference/src/index.xml
@@ -17,17 +17,20 @@
<bookinfo>
<title>Spring CodeConfig - Reference Documentation</title>
- <releaseinfo>1.0.0</releaseinfo>
+ <releaseinfo>1.0.1</releaseinfo>
<authorgroup>
<author>
<firstname>Stephen</firstname>
+
<surname>Bohlen</surname>
</author>
+
<author>
<firstname>Mark</firstname>
+
<surname>Pollack</surname>
- </author>
+ </author>
</authorgroup>
<legalnotice>
@@ -66,15 +69,14 @@
configuration metadata in XML files, there are also many problems with
this approach including the verbosity of XML and its heavy dependence on
string-literals which are both prone to typing errors and unusually
- resistant to most modern refactoring tools in use today. The CodeConfig
+ resistant to most modern refactoring tools in use today. The CodeConfig
approach removes these problems by providing a type safe, code-based,
- approach to dependency injection. It keeps the configuration metadatda external
- to your class so your class can be a POCO, free of any DI related annotations.
- </para>
-
+ approach to dependency injection. It keeps the configuration metadatda
+ external to your class so your class can be a POCO, free of any DI
+ related annotations.</para>
</partintro>
- &migration-example;
+ &migration-example;
</part>
<part xml:id="reference">
View
6 doc/reference/src/migration-example.xml
@@ -467,8 +467,8 @@ private static IApplicationContext CreateContainerUsingCodeConfig()
</listitem>
</itemizedlist>
- <para>In addition, finer-grained control of the root path within which to
- begin the scan, specific assemblies to scan, and specific <link
+ <para>In addition, finer-grained control of the specific assemblies to
+ scan, and specific <link
linkend="configuration-attribute-reference"><literal>[Configuration]</literal></link>
classes to include and/or exclude is supported by the scanning API. It is
also possible to compose configurations by dividing your <link
@@ -662,7 +662,7 @@ public class FirstConfiguration
public class SecondConfiguration : IApplicationContextAware //note the interface implementation
{
//field to hold the injected context
- private _IApplicationContext _context;
+ private IApplicationContext _context;
//property setter defined by the IApplcationContextAware interface
// so that the context can inject itself into the class
Please sign in to comment.
Something went wrong with that request. Please try again.