Problem with nested web.config's and config://spring/objects

[Erich Eichinger]

I just ran into a really nasty problem with the way config://spring/objects resource-uris are resolved when using nested WebApplicationContexts (by placing web.config's in my subdirectories)

Say we have the following structure:

Root
  web.config
  root.aspx

  SubDirectory
     web.config
     child.aspx

with both web.config's containing each a spring/context section referencing the "local" spring/objects section using <resource uri="config://spring/objects" />.

If root.aspx is the first page called after an application-restart, the Root-Context will get instantiated correctly containing all object-definitions from Root/web.config

But: If child.aspx is the first page called after an application-restart, the Root-Context will get instantiated incorrectly with the spring/objects-section of SubDirectory/web-config.

Here's what I found:

1)
For resolving the call to ConfigurationSettings.GetConfig("spring/context") the NET-Runtime calls the ContextHandler 2 times - one for Root/web.config and one for SubDirectory/web.config passing the previously created WebApplicationContext as parent to the SubDirectory's WebApplicationContext. So far so good.

2) Before the SubDirectory's context is created, the Root-Context will be initialized. The problem starts, when the Root-Context tries to resolve the
config://spring/objects resource. This is also done through a call to ConfigurationSettings.GetConfig("spring/objects"). But we're still at the SubDirectory's level!

Thus (+ the fact, that the DefaultSectionHandler ignores any parent-settings), the result of the GetConfig()-call is the "spring/objects"-section of SubDirectory/web.config instead of Root/web.config as expected.

I don't think this behaviour is by intention?

My idea would be to make the WebApplicationContext-Implementation remember the config-file's path, from which it has been constructed and to pass this file to the ConfigSectionResource-implementation. This implementation uses a ConfigurationReader instead of calling ConfigurationSettings.GetConfig().

I'm using the latest nightly build.

br,
oaky

[Aleks Seovic]

This is not the first time users reported this error, but I have a hard time reproducing it.

I constantly access SpringAir through TripForm.aspx, which is equivalent to your child.aspx, but never had this problem -- both contexts are properly initialized and everything works fine.

I will try it again, but before I do, could you please make sure that you are running .NET 1.1 SP1, just to make sure that this is not another issue related to pre-SP1 releases of ASP.NET.

Thanks,

Aleks

[Erich Eichinger]

I'm running .NET 1.1 SP1 and the nightly build 20060216-1834.

I'll have a look at SpringAir to find the differences to my own app. I hope I can work out a small example app that illustrates the problem.

btw: i just found another bug in the WebApplicationContext.Current property implementation. If the application is placed directly under the web-root, contextName will be string.Empty. This in turn causes ContextRegistry.GetContext() to raise an exception.

I solved this by placing the following code before the call to GetContext()

lock(syncRoot)
{
  if (!StringUtils.HasLength(contextName))
  {
     contextName = AbstractApplicationContext.RootContextName;
  }
  context = ContextRegistry.GetContext(contextName);
  ...

br,
oaky

[Aleks Seovic]

You are on the roll today, man

Thanks to users like you we might actually see the official release some time soon

I have no way of trying root web-app a the moment, so could you please check if this solves the problem as well:

                string contextName = requestUrl.Substring(0, requestUrl.LastIndexOf('/'));
                if (contextName == String.Empty)
                {
                    contextName = "/";
                }

I believe it should -- if I remember correctly root context for the root web-app will be registered with a name of '/'. If that's the case, your code would work, but there would actually be two application contexts created.

I might be wrong, but if you can try it and let me know (you can also setp through ContextHandler to see what is returned by VirtualPath property that is used as a context name), I'd really appreciate it.

Thanks,

Aleks

P.S. I figured out what's different in SpringAir -- I don't use config section fo root context's object definitions. All of the definitions are in the external files...

[Erich Eichinger]

I'm glad I can help. I really appreciate your work and already forced my whole department to follow your ideas ;-)

I'm afraid, naming the root-context "/" won't work, unless the Spring.Context.Support.ContextHandler is rewritten. In the Create() method on line 220:

	            contextName = ((HttpConfigurationContext) configContext).VirtualPath;

I've already stepped through this with the debugger. Somewhere deep inside, an empty contextName passed from the ContextHandler to the ContextInstantiator gets replaced with RootContextName.

So your solution could result in 2 context-instances until ContextHandler and WebApplicationContext agree on using the same name for the root-context.

br,
ee

[Erich Eichinger]

btw: If I ever get my samplecode ready, how do I send it to you?

[Aleks Seovic]

Thanks, I really appreciate both your help and you forcing your whole team to use Spring

In that case I will make the change as you suggested, although I will probably pull the code outside of synchronized block in order to minimize the amount of time we spend there.

There is also another issue with the context name being lowercased for some reason, so I'll fix that one as well while I'm there.

Regards,

Aleks

P.S. You can just email me your sample app by clicking on the Email link under any of my posts, although I think I might be able to reproduce it myself if I change SpringAir root context to use local config section instead of external files. I'd rather you spend more time finding other bugs and solutions for them than waste it on something I can easily do myself

[Erich Eichinger]

I'd rather you spend more time finding other bugs and solutions for them than waste it on something I can easily do myself

At your service ;-) My sample is ready and I'll email it asap.

Here's the next problem: On my way finding a possible solution (I was thinking of passing the web.config's filepath to the applicationcontext in a generice way within ContextHandler.Create() and providing my own WebConfigSectionResource in WebApplicationContext) I found the same problem affecting the loading of custom resource handlers. If you look at the ctor of AbstractApplicationContext there's a call to ConfigurationUtils.GetSection(ResourcesSectionName ). The corresponding ResourcesSectionHandler also silently ignores the "parent"-parameter passed in - leading to the same problem.

Seems to me, that the whole configuration & instantiation process of ApplicationContexts needs some rework to make it web-ready?

br,
oaky

btw: Why are ResourceHandlers/ProtocolMappings instance-specific? imo they should be stored to a singleton-registry (same way as e.g. typealiases)

[Aleks Seovic]

They are not instance specific -- type aliases, resource handlers, type converters, and configuration parsers are all registered globally, and should be in the root config file *only*.

They are all handled exactly the same way, so I'm not sure why you are having problems...

- Aleks

[Aleks Seovic]

Sorry, you are right -- each context has its own set of resource handlers...



- Aleks