Best Practice for application re-use?

[stutchbury]

Hi

I've been learning a great deal lately about best practices in design and implementation of business requirements and code (thanks Rod:), but I'm struggling to do the same at the 'sysadmin' level.

Using Spring, I havea couple of client applications under development, which may (or may not) be interdependent, but both (and others) will rely on one foundation: the core stuff - authentication, authorization, menus, user/organization admin/structures. Having created this core stuff as a seperate application, I am a looking for advice as to how best to keep it from being 'consumed' by each application built atop it. i.e. I'd like to keep the context, servlet and hibernate definition files independently maintained (as well as the code base).

As I'm fairly new to Spring/JSP/Tomcat, I'm struggling to think of any solution except a fairly complex Ant build file to 'merge' the required files from the seperate applications into one war file for deployment - which is not really what I was trying to achieve. (Although I can't release the client apps, I would like to release the core stuff).

My apologies if this is not all entirely 'on topic' for Spring, but any guidance would be appreciated.

Many thanks

Philip

[Dan Washusen]

Hi Philip,
We have a common project (several actually) that our other projects depend on. The common project generates a jar file and using Maven's dependency management; we include the jar file in our other projects. If your not to keen on Maven for some reason, I believe Savant offers something similar for Ant.

Another alternative could be to include the source from your common project into the current project. This can simplify refactoring between the two projects, but it's really easy to dig yourself a very big hole once several project start using the common project.

Hope that helps.

Cheers,
Dan

[stutchbury]

Hi Dan

Thanks for the response. I'll take a look at Maven. I'm fairly comfortable with the inclusion of common jar files, but not quite so sure how to handle the config files (application/servlet context, hibernate etc) and jsp's, so they are included/merged with the derived app.

I think I should keep my core stuff as a seperate servlet (i.e. merge menu options from derived apps to point at the core 'application' to do user maintenance etc) - perhaps creating taglibs for common stuff?

Philip

[Ben Alex]

We use Maven - it's worth the effort to learn.

For some applications you might find separate WARs a reasonable solution. For example:

security.war: holds a CAS server, and user management tools.
welcome.war: holds an entry page with links to other parts of the application.
gl.war: holds general ledger functions.
invoice.war: holds invoice functions.

You'd use the CAS single sign on solution so the user authenticates once and can move from one webapp to the other transparently. The only issue is each webapp would hold a distinct user session, so you'd need to consider this (session timeout, data that might need to be shared between more than one webapp etc).

[dmfrey]

Philip,

I have found that using Spring's Ant-style replacement works great for configuring included components.

I have a jar file that defines it's own spring context. I call this hibernateContext.xml, since it is strictly for setting up hibernate as my integration layer. I also have a default properties file called hibernate.properties that defines common the hibernate properties that I may replace at any given time, ie. dialect, url, username, password, etc.

I can load and run junit tests against this jar file, no problem.

Once I have my jar file, all I do is drop it into my /WEB-INF/lib directory. In my web.xml file I set a context param, contextConfigLocation, that lists all spring context's to load, including "classpath:hibernateContext.xml". In my applicationContext.xml, i define a bean:

<bean id="config" class="org.springframework.context.support.PropertyPlaceh olderConfigurer">
<property name="location">
<value>/WEB-INF/hibernate.properties</value>
</property>
</bean>

then when setting up hibernate, the values get replaced by what is in the properties file.
<property name="dialect"><value>${hibernate.dialect}</value></property>

By using this method, I create a new properties file for each application. The backend jar does not change, but each implementation can setup access to its own datasource by just changing the properties file.

The other nice thing about this is once you move from, say, dev to qa to pre-prod, the only thing that changes is that properties file, ie. you could create one for each evironment and change what the applicationContext.xml file loads in each environment.

I hope this helps.
Dan

[stutchbury]

Hi Dan

Many thanks, this is really useful - think I now have a way forward that I feel is maintainable...

Philip

[Dan Washusen]

No probs Philip, I'm glad I could help.

Enjoy, and I hope your re-use is going well :D