Best way to support parent application contexts

[Anonymous]

I spent some time figuring out how to support parentApplicationContexts and only way I found is by deriving from AbstractXmlApplicationContext. Is this the recomennded way to go?

Also, I needed plug in my own resource locator. I ended up creating a virtual method on the AbstractXmlApplicatinoContext to allow my derived class to provide the resource that is in a separate DLL. Is there a better way to do this?

Thanks,

Michael

PS - The work on this framework is impressive so far.

[Griffin Caprio]

I think a little context would help.

What exactly are you trying to do? How do you mean "support parentApplicationContext" ?

Griffin

[Mark Pollack]

Hi,

If I understand you correctly, you don't have to extend AbstractXmlApplicationContext, that should probably never be the case.

You can do something like the following code snip


IApplicationContext parentContext =
new FileSystemXmlApplicationContext(@"..\..\parent.xml");

IApplicationContext childContext =
new FileSystemXmlApplicationContext(new string[]{ @"..\..\child.xml"}, parentContext);


You can now use the features described in Child object definitions (http://www.springframework.net/doc/reference/objects.html#objects-childobjects). There is a Sample Program (http://opensource.atlassian.com/confluence/spring/display/NET/Forum+Questions) on our wiki showing the usage.

We would like to support this within the app.config file itself, take a look at the mailing list thread (http://sourceforge.net/mailarchive/forum.php?thread_id=5851456&forum_id=40049) on this topic and cast your vote!

Just guessing here on the second point...can you describe what type of resource you are getting from another DLL - strings/images??? We probably need to do a little work here I bet. We could expose external resources into the application context using either an implementation of IObjectFactoryPostProcessor (http://www.springframework.net/doc/reference/objects.html#objects-factory-customizing) or IFactoryObject (http://www.springframework.net/doc/reference/objects.html#objects-factory-lifecycle-factoryobject).

Cheers,
Mark

[Anonymous]

I'm using parentApplicationContexts because I have a separate file for each set model, view, and controller classes. They are being declared as singletons within the applicationContext but I obviously don't want every class instantiated when the main applicationContext is started.

As for the resource issue, all of my spring definition files are stored embedded resources within the DLL. If there is a prebuilt way to do this, I'd be happy to use it.

[Mark Pollack]

Hi,

If you want to load seperate files into the same app context you don't necessarily need to have a heirarchy, use the constructor

FileSystemXmlApplicationContext( string[] configurationLocations )

I'm not sure of what you mean regarding hierarchical context and precreating singletons. To create the singletons lazily, you can set the lazy-init attribute on the each object element to <object id="foo" lazy-init="true" ... /> or declare all the objects to have that attribute using <objects default-lazy-init="true">

There isn't an out-of-the-box way to get the definition file from a embedded resource. This is probably the equivalent of getting the application context out of a java .jar file. Many of the initial requests we have received regard getting the file contents from various locations. The dev team will toss around how/when to incorporate this into a future release. We'll keep you posted.

Cheers,
Mark

[Anonymous]

Your lazy-init suggestion is a good one, except our project must allow multiple instances of each set of MVC classes, hence the hierarchical app contexts.

[Mark Pollack]

Hi,

Just another FYI, you can also specify <object id="exampleObject" ... singleton="false"/> so that each time the object is retrieved from the object factory, a new instance is created. I'm not clear of what feature set hierarchical contexts is giving you....hope you are enjoying the framework nevertheless!

Cheers,
Mark

[Aleks Seovic]

Hi Michael,

I did some work in the experimental branch last week that, among other things, adds support for resource loading from assemblies.

You only need to reference resource using following naming convention:

assembly://<partialAssemblyName>/<resourceName>

Resource loader will figure out it is assembly resource based on the protocol name, load specified assembly (if it's not already loaded) and return instance of AssemblyResource for the specified resource name. Then you can easily get InputStream from it as you would for any other IResource implementation. Keep in mind that resource name has to be fully qualified with a namespace in order for this to work.

I'm not sure if this code will be merged into mainline before 0.6 release as I still have some changes to make, but you should be able to get it from CVS and try it out. Branch name is TRY_aseovic_041030.

Please let us know if this helps and if you like the mechanism or have some suggestions on how to make it better.

Regards,

Aleks