Comments on: Spring: Many applicationContext.xml > One applicationContext.xml http://72miles.com/blog/posts/spring-many-applicationcontextxml-one-applicationcontextxml/ Software By Architecture, Design, and Experience Fri, 05 Dec 2008 00:07:34 +0000 http://wordpress.org/?v=2.6.3 By: Andrew Sazonov http://72miles.com/blog/posts/spring-many-applicationcontextxml-one-applicationcontextxml/#comment-54 Andrew Sazonov Sat, 07 Jun 2008 06:44:16 +0000 http://72miles.com/blog/?p=27#comment-54 Just my 2 cents - suggestion from Mike regarding testing via bean overriding (i.e registering bean in text context using the same name as one in production) will work, but only if context is configured to allows bean definition overriding (there is appropriate setting for that)<div class="comment-remix-meta"><a href="#" class="replyto" onclick="replyto('54','Andrew Sazonov'); return false;">Reply</a> - <a href="#" class="quote" onclick="quote('54','Andrew Sazonov','Just my 2 cents - suggestion from Mike regarding testing via bean overriding (i.e registering bean in text context using the same name as one in production) will work, but only if context is configured to allows bean definition overriding (there is appropriate setting for that)'); return false;">Quote</a></div> Just my 2 cents - suggestion from Mike regarding testing via bean overriding (i.e registering bean in text context using the same name as one in production) will work, but only if context is configured to allows bean definition overriding (there is appropriate setting for that)
Reply - Quote
]]> By: Mike http://72miles.com/blog/posts/spring-many-applicationcontextxml-one-applicationcontextxml/#comment-51 Mike Thu, 29 May 2008 12:45:34 +0000 http://72miles.com/blog/?p=27#comment-51 Max, good points on test datasouces. With a Spring context, you could create a datasource bean with the same name, and then load that test context AFTER the production context, the test context would be used. That way you can keep all the configuration in the application contexts and have them injected.<div class="comment-remix-meta"><a href="#" class="replyto" onclick="replyto('51','Mike'); return false;">Reply</a> - <a href="#" class="quote" onclick="quote('51','Mike','Max, good points on test datasouces. With a Spring context, you could create a datasource bean with the same name, and then load that test context AFTER the production context, the test context would be used. That way you can keep all the configuration in the application contexts and have them injected.'); return false;">Quote</a></div> Max, good points on test datasouces. With a Spring context, you could create a datasource bean with the same name, and then load that test context AFTER the production context, the test context would be used. That way you can keep all the configuration in the application contexts and have them injected.
Reply - Quote
]]> By: Max Power http://72miles.com/blog/posts/spring-many-applicationcontextxml-one-applicationcontextxml/#comment-50 Max Power Wed, 28 May 2008 23:15:03 +0000 http://72miles.com/blog/?p=27#comment-50 Splitting your bean definitions into multiple files is definitely a good practice. However, regarding how your old way of not splitting it up caused the app context to connect to the database reminds me of something I read where I believe the preferred way of coding unit tests is to create the beans programmaticly in the setup methods. This way the tests aren't tied to configuration files that may be changed, causing the tests to become invalid since they aren't being run in the same configuration against which they were coded.<div class="comment-remix-meta"><a href="#" class="replyto" onclick="replyto('50','Max Power'); return false;">Reply</a> - <a href="#" class="quote" onclick="quote('50','Max Power','Splitting your bean definitions into multiple files is definitely a good practice. However, regarding how your old way of not splitting it up caused the app context to connect to the database reminds me of something I read where I believe the preferred way of coding unit tests is to create the beans programmaticly in the setup methods. This way the tests aren\'t tied to configuration files that may be changed, causing the tests to become invalid since they aren\'t being run in the same configuration against which they were coded.'); return false;">Quote</a></div> Splitting your bean definitions into multiple files is definitely a good practice. However, regarding how your old way of not splitting it up caused the app context to connect to the database reminds me of something I read where I believe the preferred way of coding unit tests is to create the beans programmaticly in the setup methods. This way the tests aren’t tied to configuration files that may be changed, causing the tests to become invalid since they aren’t being run in the same configuration against which they were coded.
Reply - Quote
]]> By: Adrian Neagomir http://72miles.com/blog/posts/spring-many-applicationcontextxml-one-applicationcontextxml/#comment-49 Adrian Neagomir Tue, 27 May 2008 15:14:21 +0000 http://72miles.com/blog/?p=27#comment-49 I use two definition files when doing web applications with Spring: one containing the database access and the service layer while the web related stuff in the configuration file that's used to configure the DispatcherServlet. The advantage of having this setup is that I can instantiate a console application that has access to the entire service layer for batch jobs, tests etc. using only the first file without having any dependency to a servlet container. Using more files one can assemble different application using the same codebase.<div class="comment-remix-meta"><a href="#" class="replyto" onclick="replyto('49','Adrian Neagomir'); return false;">Reply</a> - <a href="#" class="quote" onclick="quote('49','Adrian Neagomir','I use two definition files when doing web applications with Spring: one containing the database access and the service layer while the web related stuff in the configuration file that\'s used to configure the DispatcherServlet. \r\n\r\nThe advantage of having this setup is that I can instantiate a console application that has access to the entire service layer for batch jobs, tests etc. using only the first file without having any dependency to a servlet container.\r\n\r\nUsing more files one can assemble different application using the same codebase.'); return false;">Quote</a></div> I use two definition files when doing web applications with Spring: one containing the database access and the service layer while the web related stuff in the configuration file that’s used to configure the DispatcherServlet.

The advantage of having this setup is that I can instantiate a console application that has access to the entire service layer for batch jobs, tests etc. using only the first file without having any dependency to a servlet container.

Using more files one can assemble different application using the same codebase.

Reply - Quote
]]> By: Matt http://72miles.com/blog/posts/spring-many-applicationcontextxml-one-applicationcontextxml/#comment-48 Matt Tue, 27 May 2008 14:55:04 +0000 http://72miles.com/blog/?p=27#comment-48 Another issue we ran into is having several applicationContext.xml on the classpath leads to some very hard to track errors. By giving the file a unique name, you can help avoid these conflicts.<div class="comment-remix-meta"><a href="#" class="replyto" onclick="replyto('48','Matt'); return false;">Reply</a> - <a href="#" class="quote" onclick="quote('48','Matt','Another issue we ran into is having several applicationContext.xml on the classpath leads to some very hard to track errors. By giving the file a unique name, you can help avoid these conflicts.'); return false;">Quote</a></div> Another issue we ran into is having several applicationContext.xml on the classpath leads to some very hard to track errors. By giving the file a unique name, you can help avoid these conflicts.
Reply - Quote
]]> By: Mike http://72miles.com/blog/posts/spring-many-applicationcontextxml-one-applicationcontextxml/#comment-46 Mike Mon, 26 May 2008 14:19:18 +0000 http://72miles.com/blog/?p=27#comment-46 Thank you Peter. the 90th percentile states <blockquote> This is an old habit of mine, a "main index file" that imports everything else. It is a bit cleaner than specifying every file in the web.xml descriptor </blockquote> and follows up that with an example of how to import many application contexts into a main one.<div class="comment-remix-meta"><a href="#" class="replyto" onclick="replyto('46','Mike'); return false;">Reply</a> - <a href="#" class="quote" onclick="quote('46','Mike','Thank you Peter. the 90th percentile states\r\n\r\n<blockquote>\r\nThis is an old habit of mine, a \"main index file\" that imports everything else. It is a bit cleaner than specifying every file in the web.xml descriptor\r\n<\/blockquote>\r\n\r\nand follows up that with an example of how to import many application contexts into a main one.'); return false;">Quote</a></div> Thank you Peter. the 90th percentile states

This is an old habit of mine, a “main index file” that imports everything else. It is a bit cleaner than specifying every file in the web.xml descriptor

and follows up that with an example of how to import many application contexts into a main one.

Reply - Quote
]]> By: Peter Warhol http://72miles.com/blog/posts/spring-many-applicationcontextxml-one-applicationcontextxml/#comment-45 Peter Warhol Sun, 25 May 2008 19:23:43 +0000 http://72miles.com/blog/?p=27#comment-45 I think that was covered recently in the 90th percentile: http://icoloma.blogspot.com/2008/01/mock-your-spring-config-for-fun-and.html<div class="comment-remix-meta"><a href="#" class="replyto" onclick="replyto('45','Peter Warhol'); return false;">Reply</a> - <a href="#" class="quote" onclick="quote('45','Peter Warhol','I think that was covered recently in the 90th percentile:\r\nhttp:\/\/icoloma.blogspot.com\/2008\/01\/mock-your-spring-config-for-fun-and.html'); return false;">Quote</a></div> I think that was covered recently in the 90th percentile:
http://icoloma.blogspot.com/2008/01/mock-your-spring-config-for-fun-and.html
Reply - Quote
]]> By: Ashkan http://72miles.com/blog/posts/spring-many-applicationcontextxml-one-applicationcontextxml/#comment-44 Ashkan Sat, 24 May 2008 22:53:33 +0000 http://72miles.com/blog/?p=27#comment-44 ... Clearly, working with a smaller xml file is easier than working with one enormous file. ... And working with as little as possible XML stuff is the utopia so take a look at Guice Mike.<div class="comment-remix-meta"><a href="#" class="replyto" onclick="replyto('44','Ashkan'); return false;">Reply</a> - <a href="#" class="quote" onclick="quote('44','Ashkan','...\r\nClearly, working with a smaller xml file is easier than working with one enormous file.\r\n...\r\nAnd working with as little as possible XML stuff is the utopia so take a look at Guice Mike.'); return false;">Quote</a></div> …
Clearly, working with a smaller xml file is easier than working with one enormous file.
…
And working with as little as possible XML stuff is the utopia so take a look at Guice Mike.
Reply - Quote
]]> By: cherouvim http://72miles.com/blog/posts/spring-many-applicationcontextxml-one-applicationcontextxml/#comment-43 cherouvim Sat, 24 May 2008 22:53:04 +0000 http://72miles.com/blog/?p=27#comment-43 Yep. Many files and imports is how I prefer it as well. Especially those which are deployment related (datasource, mail session details etc). And I see no problems with that.<div class="comment-remix-meta"><a href="#" class="replyto" onclick="replyto('43','cherouvim'); return false;">Reply</a> - <a href="#" class="quote" onclick="quote('43','cherouvim','Yep. Many files and imports is how I prefer it as well. Especially those which are deployment related (datasource, mail session details etc).\r\n\r\nAnd I see no problems with that.'); return false;">Quote</a></div> Yep. Many files and imports is how I prefer it as well. Especially those which are deployment related (datasource, mail session details etc).

And I see no problems with that.

Reply - Quote
]]> By: Jamo Smith http://72miles.com/blog/posts/spring-many-applicationcontextxml-one-applicationcontextxml/#comment-42 Jamo Smith Sat, 24 May 2008 22:52:29 +0000 http://72miles.com/blog/?p=27#comment-42 I've used a folder called springbeans to hold all my context files. They are module or entity centric: - user.xml - project.xml - hibernate.xml - security.xml Tests are able to isolate only 1 or 2 contexts that are required to do the given test.<div class="comment-remix-meta"><a href="#" class="replyto" onclick="replyto('42','Jamo Smith'); return false;">Reply</a> - <a href="#" class="quote" onclick="quote('42','Jamo Smith','I\'ve used a folder called springbeans to hold all my context files. They are module or entity centric:\r\n\r\n- user.xml\r\n- project.xml\r\n- hibernate.xml\r\n- security.xml\r\n\r\nTests are able to isolate only 1 or 2 contexts that are required to do the given test.'); return false;">Quote</a></div> I’ve used a folder called springbeans to hold all my context files. They are module or entity centric:

- user.xml
- project.xml
- hibernate.xml
- security.xml

Tests are able to isolate only 1 or 2 contexts that are required to do the given test.

Reply - Quote
]]>