StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<p>We use wildcarded imports in the modules to allow other modules contribute beans to the module declaring the import:</p> <pre><code><import resource="classpath*:com/acme/**/*-core-support.xml" /> </code></pre> <h2>Modularity</h2> <p>Modules that want to contribute to the "host" just have to place a correctly named files in <code>src/main/resources/com/acme</code> in this case to be picked up automagically. If you use classpath scanning (by <code><context:component-scan /></code> it will become even easier).</p> <p>Another thing that helps in that regard is some small Spring extension that picks up beans of a given type and republishes them in <code>ApplicationContext</code> again. By doing something like this:</p> <pre><code><plugin:list id="beanList" class="com.acme.MyCoolPluginInterface" /> <bean class="com.acme.MyPluginHost"> <property name="plugins" ref="beanList" /> </bean> </code></pre> <p>In combination with the wildcarded import this will:</p> <ol> <li>Collect all beans found in the <code>ApplicationContext</code> that implement <code>MyCoolPluginInterface</code> and wrap them in a list registered as <code>beanList</code> in the <code>ApplicationContext</code>.</li> <li>Allow the <code>MyPluginHost</code> to reference that list.</li> </ol> <p>In fact, you now can simply extend your app by adding plugin modules to the classpath (aka dependency in Maven).</p> <p>That tiny Spring extension is called Spring Plugin and published under Apache 2 licence. See <a href="http://github.com/SpringSource/spring-plugin" rel="noreferrer">http://github.com/SpringSource/spring-plugin</a> for more info. There's also a more advanced <a href="https://github.com/olivergierke/Whoops-Architecture/tree/master/plugins-sample" rel="noreferrer">sample project</a> at Github, that shows how this works and improves modularity at GitHub. The app is sample code for my "Whoops! Where did my architecture go?" presentation which you can see the <a href="https://speakerdeck.com/olivergierke/whoops-where-did-my-architecture-go-1" rel="noreferrer">slides here</a> or watch a <a href="http://www.youtube.com/watch?v=s9LJG6olxI4" rel="noreferrer">recording here</a>.</p> <h2>Different environments</h2> <p>Usually we configure our apps to run in the target environment (using JNDI lookups and stuff). Of course you would like to use the standard <code>PropertyPlaceholderConfigurer</code> mechanisms to externalize configuration that has to be touched by admins or will change through various environments.</p> <p>For integration tests we usually have additional config files in <code>src/main/test</code> that get loaded <em>additionally</em> to the normal config files <em>overriding</em> the critical beans that tie the configuration to the environment. E.g. if you have a datasource in your normal config file</p> <pre><code> <jee:jndi-lookup id="dataSource" jndi-name="jdbc/MyDataSource" /> </code></pre> <p>you would override this in your <code>test-context.xml</code> by using</p> <pre><code> <bean id="dataSource" class="...DataSource" />  </bean> </code></pre> <p>and importing that <em>after</em> the original one in the test class</p> <pre><code> @ConfigurationContext(locations = {"app-context.xml", "test-context.xml"}) public FooBarIntegrationtest { // ... } </code></pre>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload