Ok here are the samples. I apologize for taking a while but we have a pretty
deep parent hierarchy and I had to scrub these files to make them generic.
Also let me take a second to explain how we use appfuse so you can understand
some of the modifications we have made. W
We have a number of company databases and we wanted to provide a management
application for each and we also did not want our developers writing their own
SQL or creating their own hibernate layer. We decided that if there was a
central kit for data access for each database we could tune that layer and
every application that leveraged that layer could take advantage of the
improvement. This has been in place for a little over a year and is working
well. We ran under maven-1 and recently converted to maven-2 but have been
using a version of the maven-2 appfuse plugin for quite sometime.
The first step is to use appfuse to generate the management application for
each database. This is fairly straightforward since it follows very closely to
the appfuse tutorial. Then for composite applications that need to access
multiple databases from inside that application they merely have to import the
database access layer jar for each database. These jars are the standard
appfuse data layer jars that include the hibernate layer (dao and hibernatedao)
and the spring layer (manager and managerimpl). We also support multiple
schemas per kit which is why we changed from middlegen to hibernate-tools
To avoid collisions we needed to do 3 things:
1) Place the applicationContest-persist.xml and applicationContext-service.xml
in their own package structure. (i.e.
com.scryan.datakit.dao.hibernatedao.applicationContext.xml)
2) Create a property management system that allowed us to dynamically configure
the sessionFactory datasource for each jar and each environment (dev, test,
stage and prod) for both runtime and testing.
3) Insure all bean names are unique so there is no collision during spring load
time if the tablenames are the same. This also meant that our sessionFactories
and transactionManagerProxies must have unique names across kits and that the
correct dependencies were injected to the correct beans.
That said here is how we set up the maven-1 and maven-2 projects to support
testing and runtime with one set of context files and multiple datasources
applicationContext-persist.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE beans PUBLIC "-//SPRING//DTD BEAN//EN"
"http://www.springframework.org/dtd/spring-beans.dtd";>
<beans>
<!-- Hibernate SessionFactory -->
<bean id="sessionFactoryUnique"
class="org.springframework.orm.hibernate3.LocalSessionFactoryBean">
<property name="configLocation">
<value>classpath:com/scryan/datakit/properties/hibernate.cfg.xml</value>
</property>
<property name="mappingLocations">
<value>classpath*:com/scryan/datakit/model/**/*.hbm.xml</value>
</property>
</bean>
<!-- Make sure to make the proper changes in the service xml to use this
transaction manager -->
<bean id="transactionManagerUnique"
class="org.springframework.orm.hibernate3.HibernateTransactionManager">
<property name="sessionFactory">
<ref local="sessionFactory" />
</property>
</bean>
!-- Generic DAO - can be used when doing standard CRUD -->
<bean id="dao" class="com.scryan.datakit.dao.hibernate.BaseDAOHibernate">
<property name="sessionFactory" ref="sessionFactoryUnique" />
</bean>
<!-- Add new DAOs here -->
<!--CreditReportValue-START-->
<bean id="creditReportValueDAO"
class="com.scryan.datakit.dao.jdbc.CreditReportValueDAOJdbc"
autowire="byName" >
<property name="sessionFactory" ref="sessionFactoryUnique" />
</bean>
hibernate.cfg.xml for runtime using a jndi datasource from weblogic located in
src/main/resources/properties/com/scryan/datakit/properties
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE hibernate-configuration PUBLIC "-//Hibernate/Hibernate Configuration
DTD 3.0//EN"
"http://hibernate.sourceforge.net/hibernate-configuration-3.0.dtd";>
<hibernate-configuration>
<session-factory>
<property
name="hibernate.dialect">org.hibernate.dialect.DB2Dialect</property>
<property
name="hibernate.connection.datasource">jdbc/SAMPLEDATASOURCE</property>
<!-- We use the old parser to get around an issue with weblogic and
ANTLR -->
<property name="hibernate.query.factory_class">
org.hibernate.hql.classic.ClassicQueryTranslatorFactory
</property>
<property name="hibernate.generate_statistics">true</property>
</session-factory>
</hibernate-configuration>
hibernate.cfg.xml for test located in
src/test/resources/properties/com/scryan/datakit/properties
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE hibernate-configuration PUBLIC "-//Hibernate/Hibernate Configuration
DTD 3.0//EN"
"http://hibernate.sourceforge.net/hibernate-configuration-3.0.dtd";>
<hibernate-configuration>
<session-factory>
<property
name="hibernate.connection.username">SAMPLEUSERNAME</property>
<property
name="hibernate.connection.password">SAMPLEPASSWORD</property>
<property
name="hibernate.connection.url">jdbc:db2://SAMPLEMACHINENAME:SAMPLEPORT/SAMPLEDATABASENAME</property>
<property
name="hibernate.connection.driver_class">com.ibm.db2.jcc.DB2Driver</property>
<property name="hibernate.connection.isolation">1</property>
<property
name="hibernate.dialect">org.hibernate.dialect.DB2Dialect</property>
<!-- We use the old parser to get around an issue with weblogic
and ANTLR -->
<property
name="hibernate.query.factory_class">org.hibernate.hql.classic.ClassicQueryTranslatorFactory</property>
<property name="hibernate.generate_statistics">true</property>
</session-factory>
</hibernate-configuration>
pom.xml build section for both runtime and test
<build>
<sourceDirectory>${basedir}/src/main/java</sourceDirectory>
<testResources>
<!-- This grabs any test specific properties for the test run
-->
<testResource>
<directory>${basedir}/src/test/resources/properties</directory>
<includes>
<include>**/*.*</include>
</includes>
<filtering>false</filtering>
</testResource>
<!-- This grabs any environment specific test specific files
(build env could be dev,test,stage,prod) Should be using profiles here. -->
<testResource>
<directory>${basedir}/src/test/resources/${maven.build.environment}</directory>
<includes>
<include>**/*.*</include>
</includes>
<filtering>false</filtering>
</testResource>
</testResources>
<resources>
<!-- This grabs environment specific properties and should be
replaced with profiles. -->
<resource>
<directory>${basedir}/src/main/resources/${maven.build.environment}</directory>
<includes>
<include>**/*.*</include>
</includes>
<filtering>false</filtering>
</resource>
<!-- This grabs non environment specific properties including
the applicationContext xml files. -->
<resource>
<directory>${basedir}/src/main/resources/properties</directory>
<includes>
<include>**/*.*</include>
</includes>
<filtering>false</filtering>
</resource>
<!-- This makes sure all the hbm.xml files are included in
the jar. The applicationContext xml files are in resources. -->
<resource>
<directory>${basedir}/src/main/java</directory>
<includes>
<include>**/*.hbm.xml</include>
</includes>
<filtering>false</filtering>
</resource>
</resources>
</build>
Scott Ryan
Chief Technology Officer
Soaring Eagle L.L.C.
[EMAIL PROTECTED]
www.soaringeagleco.com
(303) 263-3044
-----Original Message-----
From: Daniel Serodio [mailto:[EMAIL PROTECTED]
Sent: Friday, August 25, 2006 7:33 AM
To: Maven Users List
Subject: Re: Better to use variables or hard-coded paths?
Scott Ryan wrote:
> We actually use the same application context but use the test resources
> construct to pull it out of the main build path for use during testing. You
> just need to include the xml files from the main tree in your resources
> during testing and it works very nice. We use a different hibernate
> configuration since in one case we are using a JNDI lookup in production and
> during testing just a direct jdbc connection. The xml is configured to build
> the session factory from the data source we define in the properties file.
> If you like I can send you the maven 1 or 2 config we are using.
>
Can you please send me the m2 config? I don't understand what you mean
by "pull it out of the main build path".
> Scott Ryan
> Chief Technology Officer
> Soaring Eagle L.L.C.
> [EMAIL PROTECTED]
> www.soaringeagleco.com
> (303) 263-3044
>
> -----Original Message-----
> From: Matt Raible [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, August 23, 2006 10:58 AM
> To: Maven Users List
> Subject: Re: Better to use variables or hard-coded paths?
>
>
> On 8/23/06, Daniel Serodio <[EMAIL PROTECTED]> wrote:
>
>> Matt Raible wrote:
>>
>>> I'm customizing my pom.xml so XML files are available on my classpath
>>> (at /WEB-INF/*.xml) when testing. My question is (hopefully) simple.
>>>
>>> Is it better to use:
>>>
>> <snip/>
>>
>> I think using "Hard-coded directories" is more "Maven-like", while using
>> variables is more "Ant-like". I'd stick with the hard-coded directories,
>> or better yet, use Maven's "stardard directory layout"
>> http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html
>>
>
> I am using this layout, I just need to include src/main/webapp in my
> classpath so I can use /WEB-INF/applicationContext.xml in my tests -
> w/o having duplicate context files.
>
> Thanks for your advice Daniel.
>
> Matt
>
>
>> HTH,
>> Daniel Serodio
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
