Configuring an app context from a string

[innes]

This is probably a silly question, but I can't see a way to create an IApplicationContext configured from the contents of a string containing XML (or an InputStreamResource initialised with a StringReader, for example). Is this possible, or do I need to save the string to a temporary file and configure from that?

[Rick Evans]

Hiya

Unfortunately, the current API for the available IApplicationContext (http://www.springframework.net/doc/api/html/Spring.Context.IApplicationContext.html) implementations does not support configuration from an arbitrary XML resource (such as a stream of XML being read from a string).

The technique you describe (feeding a string into an InputStreamResource (http://www.springframework.net/doc/api/html/Spring.Core.IO.InputStreamResource.html)) is used extensively in the unit tests for the XMLObjectFactory (http://www.springframework.net/doc/api/html/Spring.Objects.Factory.Xml.XmlObjectFactory.html) class, because its just so darn convenient. The IApplicationContext abstraction is kinda targeted at more enterprise level usage, so I (for one) never quite envisaged one needing to configure it from anything other than a physical resource (almost always a file). Making the container more amenable to end-user configuration has been on the cards for some time now... this applies to Spring Java as well. I'll start looking into it again after the Spring.NET 1.0 final release is out next week

Are you doing your own testing with Spring.NET? Or do you have some esoteric use case that we can fold into the API? I want to help out, but I don't want to post some ugly old hack :? (several are coming to mind right now, all of them quite nausea inducing), so do get back to me with just why you would want to do this (configure the Spring.NET container from a string of XML), and maybe we can open up the API for you. Having to save the string to a temporary file and then pass the temporary filename to the, well ugh... that would work, but it would be so darn nasty :(

Ciao
Rick

[innes]

I'm developing a distributed application that acts as a platform for running tasks (defined in dotnet classes) asynchronously. Configuration and state is held in a shared database accessed by a cluster of worker machines.
I can see one area (well, a few areas, but I want to start small!) where IoC could be very useful to simplify things. I want to redesign a subsystem that serves singleton instances of 'service' classes to running tasks identified by string id (a service locator type thing) to use Spring if possible. Service classes are dependent on other service classes, meaning that if I stick with the service locator pattern, services need to know the 'id's of the services they depend on - yuck.
At the moment, the service classes are registered in the shared database, and I'd want to replace this registration information with a Spring object definition file, also stored in the database. Hence the requirement to configure from an XML stream - I would be loading the XML from a database field.

Actually although using a temporary file isnt ideal, it's not going to stop me having a go.:)

[Rick Evans]

Hiya

I see where you're going now. I'll mull it over a bit more... in the interim though, if you don't need access to the full IApplicationContext (http://www.springframework.net/doc/api/html/Spring.Context.IApplicationContext.html), and you don't want to go down the route of the temporary file, have you considered using just the plain XmlObjectFactory (http://www.springframework.net/doc/api/html/Spring.Objects.Factory.Xml.XmlObjectFactory.html)?

As I mentioned in my previous email, configuring an XmlObjectFactory (http://www.springframework.net/doc/api/html/Spring.Objects.Factory.Xml.XmlObjectFactory.html) from an arbitrary string is easy... there are loads of tests in the XmlObjectFactoryTests class (provided as part of the release distribution) that do exactly that. Ping me if you want me to post an actual example on this forum.

I'll discuss your issue with the other developers... I can't think of a compelling reason why the XmlApplicationContext doesnt support this kind of configuration. I'll keep you posted, and I'll reply to this forum posting when I've resolved your issue.

Have a cool the rest of your weekend, ciao
Rick

[innes]

Thanks - in the meantime I am going to start by messing about with programmatical configuration of an object factory in a test project. Hopefully this'll give me a better understanding of the mechanics of Spring.

[Rick Evans]

Haha... how very Heineken. I'm actually writing a blog post about that very issue right here, right now (programmatic configuration of the Spring.NET IoC container).

For too long I've been hearing remarks about how Spring.NET forces XML down developers throats. It doesn't... its just that XML configuration is usually the most expedient, plain vanilla, no-nonsense way of doing so.

I'll post the link to my blog entry here when I'm done.

Ciao
Rick

[innes]

I managed to get what I wanted to do implemented with XmlObjectFactory, using a post processor to do some extra configuration on the objects. Dead good, and no more unique-ids-of-other-objects embedded in my classes!

[Aleks Seovic]

Another option is to implement your own resource class that would know how to connect to database, read the config file and expose it as a Stream.

This is one of the reasons we implemented resources the way they are implemented. It is pretty straight forward to write your own IResource implementation, and probably the best way to go in this case because you'll be able to load the full-blown context, not just an object factory.

Let me know if you want to go down this route and I will implement necessary support for adding custom resource registrations, which unfortunately still isn't there.

Regards,

Aleks