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
>
>

Reply via email to