Managing Web IApplicationContext (several questions)

[Alistair]

I've read the discussions on use of the PageHandlerFactory to have Spring manage the life of IApplicationContext within a web page but have a few more questions.

What is the timetable for this class and associated process being ready for general production use? The current 0.6.0 RC3 doesn't appear to include this functionality even though the documentation includes it in some cases.

Are there plans to modify this class so that exceptions will not be thrown for pages that aren't defined as objects (i.e. .aspx pages that don't use the IApplicationContext)?

If I were to wait until later to use the WebApplicationContext and PageHandlerFactory, what would be the best approach to managing the IApplicationContext? A singleton object used by all threads within IIS?

Finally, I need to pass the context to my service brokers (an implementation of the Broker pattern) which do not have any dependency on the System.Web namespace. Specifically, if I use Spring to instanciate the broker objects, is it possible to have a reference to the IApplicationContext injected so they have access to it without having to call WebApplicationContext.Current? Is there a better approach to this kind of problem?


Many thanks!
Alistair

[Rick Evans]

Hi Alistair

The roadmap for the Spring.NET releases is on the Confluence (http://opensource.atlassian.com/confluence/spring/display/NET/Home) wiki. The next thing up for general release is the AOP framework... this is already done (in fact, it was the first thing done, completed even before the IoC container was implemented). The lapse between the release of 0.6 final and the 0.7RC will thus be quite short. Next up will be the web (ASP.NET) support. If I had to put a timeframe on the first 0.8 (web) RC, I'd say mmm, sometime in July? Most of the core stuff is already implemented, so thats not too unreasonable. Not too sure when 0.8 will be final though, given the track record for the 0.6 build :?

In answer to how to inject the IApplicationContext instance(s) into your broker objects, you can have your broker classes implement the IApplicationContextAware (http://www.springframework.net/doc/api/html/Spring.Context.IApplicationContextAware.html) interface... I guess that your broker objects are already tied to the Spring.NET API's, so implementing this interface doesn't lose you anything.

I believe that Aleks 'The Man' Seovic is working on a fix for the issue you describe where pages that are not defined as (Spring.NET managed) objects raise an exception... there is a posting (http://forum.springframework.net/viewtopic.php?t=90) on this forum that discusses the workaround for this issue in the meantime. Of course, to get the fix, you'll have to download the latest CVS HEAD 'cos the first 0.8 RC is well, some months away (~July).

Ciao
Rick

[Alistair]

Rick

Thanks very much for such a quick response. I have read about the work around for the PageHandlerFactory issue but want to try and avoid that if possible. I think I'll wait for now, and come back to this in July once the 0.8 RC is out.

I have encapsulated the IApplicationContext within a Factory pattern for the brokers so they don't have any declarative dependency on Spring except for the Factory itself (the project obviously requires the Spring.net runtime assembly references though).

Is there any technical problem wrapping the IApplicationContext instance within a static member of a factory object and referencing this from ASP.Net pages and brokers alike?


public class ObjectFactory
{
private static volatile IApplicationContext _context = null;

private ObjectFactory()
{
}

public static ObjectFactory GetInstance()
{
return new ObjectFactory();
}

public object CreateObject(String identifier)
{
if(_context == null)
{
lock (typeof (XmlObjectFactory))
{
if(_context == null)
{
_context = (IApplicationContext)
ConfigurationSettings.GetConfig("spring/context");
}
}
}
return _context.GetObject(identifier);
}
}



Could this same factory be used equally effectively by serviced components on the application server?

Thanks again.
Alistair

[Aleks Seovic]

Hi Alistair,

While Spring.Web in general will not be released until 0.7 release (I changed road map on the wiki to reflect that), you can use PageHandlerFactory right now if you don't mind using code from CVS.

The class itself is very simple and the only thing that will change in it is the addition of the logic that replicates behavior of standard ASP.Net PageHandlerFactory for requested pages that are not found in the context (which I hope answers your second question -- yes, we plan to add that logic).

I strongly encourage you to use existing implementations of PageHandlerfactory and WebApplicationContext. Not only will you be able to define your pages in the Spring config file and inject dependencies into them, but you can also define your objects as reqest, session or application scoped using 'scope' attribute of the 'object' element.

In case you still don't want to use these classes, the best way to manage your context is not to manage it at all :wink: You can simply always call ConfigurationSettings.GetConfig("spring/context") from your factory class, which can be completely stateless and without any synchronization. In this case, .Net configuration subsystem will create and cache application context the first time you request it and return cached instance on subsequent calls. This is exactly what Spring PageHandlerFactory does.

To answer your last question, the best way to obtain reference to application context from your classes is to implement IApplicationContextAware interface -- you define writeable ApplicationContext property and Spring will inject appropriate application context instance after it instantiates your object.

Be conservative when using this, or any other Spring lifecycle interface, as it ties your code more closely to Spring. Spring.Web Page and UserControl classes implement this interface in order to get access to a message source within the context, which is one of the few scenarios that warrants IApplicationContextAware implementation. You should not have to implement this interface in order to call GetObject method on the application context -- object definitions in the config file are usually all you need to wire dependencies properly (at least in web applications).

Regards,

Aleks

[Alistair]

Aleks

Thanks for your response. A final question in this regard...

If a dependency has the scope defined as "Session", where is it stored? Does this get added to ASP.Net session scope?

In this case, I assume we have to be careful about the size and serialization overhead of the object as we would with anything persisted to Session state.

Thanks again for your help.
Regards
Alistair

[Aleks Seovic]

Yes, it gets stored within HTTP session, which means that rules for serialization etc. will depend on the selected session mode (InProc, State Server or SQL Server) and that developers need to apply the same logic they normally use to decide whether to store something within HTTP session or not.

- Aleks

[Aleks Seovic]

Just to close one of the questions in this post.

I have modified Spring PageHandlerfactory to behave the same way as the standard ASP.Net PageHandlerFactory does if page definition does not exist in the Spring application context -- it will simply try to load it from the filesystem using standard ASP.Net mechanism.

Keep in mind that if your page extends Spring.Web.UI.Page and you use one of the GetMessage methods to retrieve localized messages, you need to create definition for the page so container can inject application context into it, which is then used to access message source. In general, if your page extends Spring Page class it is probably a good idea to create definition for it in the config file.

Regards,

Aleks