On Sat, Sep 12, 2009 at 11:57 AM, measwel <marek_karczew...@yahoo.com.au>wrote:
> > jdbc.properties is read by applicationContext-resources.xml. I'm not > certain > there should be a *-resources.xml file in both src/main/resources and > src/test/resources. If there is, I'd compare file contents and see if > they're the same. If so, delete the one in the test directory. > > I still dont understand when the connection settings from pom are used and > when the settings from applicationContext-resources are used. > The connection settings in pom.xml are filtered and put into jdbc.properties, then read by Spring. This allows you to change the settings in your pom.xml (for example, by activating a profile) and not have to change any files by hand. If you will never change your settings, you could hard-code them in jdbc.properties. > > The files are almost the same, but in main: > > <?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:jee="http://www.springframework.org/schema/jee" > xsi:schemaLocation="http://www.springframework.org/schema/beans > http://www.springframework.org/schema/beans/spring-beans-2.0.xsd > http://www.springframework.org/schema/jee > http://www.springframework.org/schema/jee/spring-jee-2.0.xsd"> > > <!-- For mail settings and future properties files --> > <bean id="propertyConfigurer" > > class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer"> > <property name="locations"> > <list> > <value>classpath:jdbc.properties</value> > <value>classpath:mail.properties</value> > </list> > </property> > </bean> > > <!-- JNDI DataSource for J2EE environments --> > <!--<jee:jndi-lookup id="dataSource" > jndi-name="java:comp/env/jdbc/appfuse"/>--> > > <bean id="dataSource" class="org.apache.commons.dbcp.BasicDataSource" > destroy-method="close"> > <property name="driverClassName" value="${jdbc.driverClassName}"/> > <property name="url" value="${jdbc.url}"/> > <property name="username" value="${jdbc.username}"/> > <property name="password" value="${jdbc.password}"/> > <property name="maxActive" value="100"/> > <property name="maxWait" value="1000"/> > <property name="poolPreparedStatements" value="true"/> > <property name="defaultAutoCommit" value="true"/> > </bean> > </beans> > > In test: > > <?xml version="1.0" encoding="UTF-8"?> > <beans xmlns="http://www.springframework.org/schema/beans" > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" > xsi:schemaLocation="http://www.springframework.org/schema/beans > http://www.springframework.org/schema/beans/spring-beans-2.0.xsd"> > > <bean id="propertyConfigurer" > > class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer"> > <property name="locations"> > <list> > <value>classpath:jdbc.properties</value> > <value>classpath:mail.properties</value> > </list> > </property> > </bean> > > <bean id="dataSource" > class="org.springframework.jdbc.datasource.DriverManagerDataSource"> > <property name="driverClassName" value="${jdbc.driverClassName}"/> > <property name="url" value="${jdbc.url}"/> > <property name="username" value="${jdbc.username}"/> > <property name="password" value="${jdbc.password}"/> > </bean> > > </beans> > The main one uses a connection pool and the test one uses a straight connection to the database. You definitely want a connection pool for production use, but it's somewhat overkill for tests. > > Universal Manager has been deleted in trunk. > > Is it advisable to rewrite the existing classes to use Generic manager > instead? > It's up to you. If it ain't broke, don't fix it is my opinion. ;-) You could also just look at the latest one in trunk and try to use it, but I'm not sure if other changes are required. > > > > > 5) Code generation. The manager bean for a generated class gets defined > in > > context.xml, while the present beans are defined in > > ApplicationContext-service.xml. Why is it so? > > > > Code generation is designed to run in embedded mode. The > applicationContext-service.xml file is stored in a JAR by default. That's > why we modify the (originally empty) applicationContext.xml file. > > I dont understand. Could you elaborate? > Before you run "appfuse:full-source", the applicationContext-service.xml doesn't exist in your project. Code generation doesn't take into account which file to write to when it generates code - it only modifies applicationContext.xml. This allows your code to stay somewhat separate from AppFuse's. Matt -- > View this message in context: > http://www.nabble.com/Some-appfuse-clarification-requested-tp25414317s2369p25416751.html > Sent from the AppFuse - User mailing list archive at Nabble.com. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@appfuse.dev.java.net > For additional commands, e-mail: users-h...@appfuse.dev.java.net > >