Unable to devise a failing test that evidences the issue, but added several tests that demonstrate that its (seemingly)not possible to create the problem described in this issue. If a failing test is ultimately submitted, we can investigate further.
Commit failing test case for recurring concurrency bug in re: AbstractObjectFactory; finally have a 100% reproducible failing test case to work against now. Next up, of course, will be the harder part of making the test pass... :)
Method mentioned in the documentation was long-since deprecated and had been removed from the Interface. Docs updated to remove reference to the no-longer-existent method signature.
-introduce singleton-specific lock object registration to prevent against deadlocks when any one singleton create/destroy op calls arbitrarily long user-supplied methods that may or may not block
-wrapped modifications to nestingCount in Interlock.Increment and Interlock.Decrement calls
-wrapped calls to decrement nestingCount with protection against it decrementing to < 0
Added call to check if the SchemaSet is already compiled and compile it within a critical section to avoid thread collisions during the compilation of the schema.
Added additional option of <database: ... /> as well as <db: ... /> as a wellknown namespace since inconsistency between different places in the documentation mentions BOTH yet only <db: ... /> was actually a registered wellknown namespace (meaning any attempts to use <database: ... /> namespace would only work if the parser for that namespace was explicitly configured by the user)
-removed explicit call to add ID attribute to the control (as call to base class AddAttributesToRender(...) method adds it for us)
-updated SpringAir.2010.sln to target .NET 4.0 (since targeting .NET 2.0 wouldn't let it consume the 4.0-compiled dependencies
Improve exception messages in the case where the DynamicProxyManager attempts to register a Proxy using an already-registered name but pointing to a DIFFERENT type (this is usually a configuration error associated with attempting to export two or more services from two or more config sources that accidentally share a single common name)
-add tests to verify proper behavior from service exporter when applying declarative attributes to exported services
-relocate recent ConstructorInstantiationInfo class into Utils namespace
SPRNET-1356 : Introduce IPriorityOrdered interface to ensure correct ordering among IObjectFactoryPostProcessors
SPRNET-1355 : TypeAlias usage with other IObjectFactoryPostProcessor object definitions not working.
work started on SPRNET-1262
fix 2003/2005 solution builds
