On 01/22/2014 12:03 PM, Paul B. Henson wrote:
>> From: Dan Webb [mailto:[email protected]]
>> Sent: Wednesday, January 22, 2014 12:21 AM
>>
>> Yeah we're having the same problem here with dev and production using the
>> same war. Using two different wars would easily lead to configuration drift.
>
> Typically in an enterprise deployment, you have a package management system,
> and a configuration management system. With almost everything else I work
> with, I can easily create a binary package of an application, which can then
> be automatically installed anywhere it needs to be, and configure it as
> necessary automatically through our configuration management system.
>
> But anytime I have to touch anything involving enterprise JavaBeans, it seems
> to involve bending over backwards and jumping through hoops to try to avoid
> having to compile a specific binary for each and every single system on which
> it needs to be deployed :(. For our CAS servers I ended up having to have a
> custom post install for the package that swaps out config files in the WAR
> with ones from the file system before copying it into the webapps directory
> <sigh>. Maybe I'll have to do the same thing here. It would make things so
> much easier if the WAR file simply referenced an external configuration
> file...
>
> I'm sure I'm not exactly winning friends and influencing people with Java
> rants in what's likely a Java friendly forum ;), but as long as I've got my
> grumpy old man hat on, what's with all the different build utilities? This
> one uses ant, that one uses maven, hey, look, gradle! On top of trying to fit
> a square self-contained java app peg into my round enterprise systems
> management hole, I've got to set up and figure out a completely new build
> environment every time...
>
Maybe not the prettiest/correct/... way, but one thing we did was to
allow overriding Spring configuration in the file system, using a
parallel directory structure analogous to that in the war, and setting a
configuration 'home' directory in the application container. The war
contains reasonable defaults, and the file system overrides, with a
small addition to web.xml:
> <context-param>
> <param-name>contextConfigLocation</param-name>
> <param-value>
> /WEB-INF/spring-configuration/*.xml
> /WEB-INF/deployerConfigContext.xml
> file:${cas.home:/etc/cas}/spring-configuration/*.xml
> </param-value>
> </context-param>
Then ${cas.home} contains e.g. directories 'classes' and
'spring-configuration' (my understanding with Spring is "last one wins").
Tom.
--
You are currently subscribed to [email protected] as:
[email protected]
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/cas-user
