This means you can not just H2 and HSQL but also DERBY.
The following is the entry you can use:

in your spring config files. So far I’ve found that IDEA picks this up and allows you to include the xsd details you need same as importing packages in a class.

In case it doesn’t you can try adding the following:


xmlns:jdbc="http://www.springframework.org/schema/jdbc"
xsi:schemaLocation=" http://www.springframework.org/schema/jdbc
http://www.springframework.org/schema/jdbc/spring-jdbc.xsd"


G

We have some shortcuts which available by using <security: namespaces in the spring config. Two of them are ‘authentication-manager’ and ‘authentication-provider’. It would appear that in Spring 2.x these two tags were both top level tags. In 3.x however the provider needs to be inside the manager. See this link http://deprecatedconsciousness.wordpress.com/2009/12/01/spring-security-3-schema-changes/ for a slightly longer description.

G

Annotation-driven configuration was introduced in spring 2.5.x. Annotations can mark fields, methods and classes that need dependancy injection. This reduces configuration and dependancy mapping in spring configuration.

@Component, @Repository, @Service, and @Controller are four comnmonly known spring annotation. @Repository, @Service, and @Controller serve as specializations of @Component (generic stereotype). I have been using @Contoller for sometime and have found very useful, especially when combined with the benefits for spring 3′s REST support (more on that in a later post). Below is a controller with the annotation @Controller.

@Controller
public class TestController {
  // Fields, Methods etc
  @Autowired(required = true)
  public void setTestDao(TestDao testDao) {
    this.testDao = testDao;
  }
}

You can auto-detect @components by adding the following element in the spring-config.xml. The <component-scan/> element will auto-detect components for the base package of you application (filters can be applied for finer grained inclusion/exclusion of the package).

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xmlns:context="http://www.springframework.org/schema/context"
  xsi:schemaLocation="http://www.springframework.org/schema/beans
  http://www.springframework.org/schema/beans/spring-beans-2.5.xsd
  http://www.springframework.org/schema/context
  http://www.springframework.org/schema/context/spring-context-2.5.xsd">

  <context:component-scan base-package="au.edu.une.example"/>

</beans>

This component-scan would automatically detect the controller class and register any corresponding BeanDefinitions with the ApplicationContext. Therefore there would be no need for the following in the spring configuration:

<bean name="testController" class="au.edu.une.example.TestController">
  <property name="testDao" value="testDao"/>
</bean>

Another handy annotation i have been making heavy use of is @Autowired (in example above). Its great for configuring controller dependencies on dao’s and other classes, when using auto detection. I have found @Autowired handy when writing unit tests too.

So try out the Annotation-driven configuration benefits in your application.

See Annotation-based configuration for more details on this Annotation-driven configuration via spring.

As you upgrade to the apps to 6.0.24 for the coming web cluster you will probably find that any app that contains spring is throwing ThreadLocal errors when you shut Tomcat down, as below:

SEVERE: A web application appears to have started a thread named [schedulerFactory_Worker-9] but has failed to stop it. This is very likely to create a memory leak.
Mar 8, 2010 12:07:36 PM org.apache.catalina.loader.WebappClassLoader clearReferencesThreads
SEVERE: A web application appears to have started a thread named [schedulerFactory_Worker-10] but has failed to stop it. This is very likely to create a memory leak.
Mar 8, 2010 12:07:36 PM org.apache.catalina.loader.WebappClassLoader clearReferencesThreads
SEVERE: A web application appears to have started a thread named [schedulerFactory_Worker-2] but has failed to stop it. This is very likely to create a memory leak.

It would appear there has been a change in Tomcat between 6.0.20 and 6.0.24 where Tomcat is trying to detect possible memory leaks. Spring has this to say about it:

http://forum.springsource.org/showthread.php?t=84202

Essentially at the moment they believe this is an erroneous error and that Tomcat perhaps needs to fix this. As a result at the moment this is not an error you need to remove. We will have to live with it on the new web-cluster until one side or the other determines a resolution.

Gerwood

A comment I found on another site (http://mediakey.dk/~cc/java-default-keystore-password-cacerts/) suggests why.

It would appear that Apple updates (and I suspect simply replaces) the cacerts file during some of their software updates. This will infact completely reset your cacerts store.

Also note that the other article also notes that apple have changed the default password from ‘changeit’ to ‘changeme’

Gerwood

After a little more research it would appear that there is another setting you may need to apply to H2 to make it run the way you need. By default H2 in memory databases will be wiped out if there are no more connections to them. This means that if you remove all connections to an in memory database and then create a new one it will be connecting to a brand new, empty, in memory database.

How to fix it?

You can add ;DB_CLOSE_DELAY=-1 to the end of the testDatabaseName field in you spring datasource bean.

This means that the in memory database will be contained for the life of the running JVM. You can alternatively set it to a number greater than 0 and the database will be maintained for that many seconds past the last connection. This may be an alternative if you want the database to be available for a limited period only.

Gerwood

But I have recently discovered that Tomcat allows exceptions to be thrown from within the initialisation phase of a servlet‘s life-cycle without side-affects, while exceptions thrown from within the initialisation phase of a filter‘s life-cycle causes a Catalina SEVERE error resulting in the context not loading.

Hmmm…. Not sure why this is the case, but until someone can explain it to me I will treat it as a bug within Tomcat. We are using v5.5.25.

FYI, I came across this while trying to implement an application configuration servlet which loads on start-up setting various application properties based on environment variables et al. Due to the described ‘bug’, I have ended up using a filter for the job instead of a servlet as it behaves as I would expect. A better solution would be to use Spring, I know, but we are still having to maintain some complex legacy apps which are not worth spending the time converting to Spring.

The table is being created. So why does the test fail?

It would appear the h2 is possibly a little more advanced than HSQL by default. The reason I can’t see the table is that I haven’t committed it.

By adding ‘commit;’ as the last statement to the db schema file the errors will be corrected and the tests should pass (assuming that was the only problem).

The reason for this:

In some places (especially when testing repositories or if junit runs tests in parallel) you might end up with several connections to the in memory database. This could happen when you as a repository for something and it fires a second query while retrieving data from a previous one.

The result is that the first connection where I created the tables can see them because they are a part of its working data. The second connection can’t as they haven’t been committed back to the proper database for everyone else yet.

Gerwood

I was updating our Library’s electronic document repository system, eReserve, when I noticed that it was using a Log4j SMTPAppender for cases when documents where not found where expected (HTTP 404). The Appender was setup to send an email to the Library’s document manager in order to keep on top of dud links. However, it was not working because in a recent iteration eReserve was updated to use  a Maven build instead of an Ant build. This resulted in Ant tokens not being processed and hence the ‘To’ property of the SMTPAppender not being set. So the email was going nowhere.

Now, for each environment we have a different ‘To’ address to use because we don’t want the Library’s document manager to receive all of our emails generated during development and system testing. For this situation we make use of Tomcat environment variables. But we can’t set log4j.properties to get values from JNDI. So we have to set the ‘To’ field programmatically (that is, at run time as part of the code). Here is the code I used:


// This will set the To option of the SMTPAppender instead of it being set in the Log4j properties file
// this allows this value to be determined programmatically, in this case from an environment variable
Logger logger = LogManager.getLogger("erez.email");
SMTPAppender appender = (SMTPAppender)logger.getAppender("erezEmail");
appender.setTo((String)pageContext.findAttribute("erez_email"));
appender.activateOptions();


Note the activateOptions() method of the SMTPAppender object. This is like the ‘save’ button on forms… was hard to find that this was needed.

The Log4j API can be found here (note the version): http://logging.apache.org/log4j/1.2/apidocs/index.html