I came up with a better workaround. I did the following to my maven
project, which uses the cas-server-webapp as an overlay.
<build>
...
<resources>
<!-- Copy configurations over to webapp folder -->
<resource>
<filtering>true</filtering>
<directory>${basedir}/src/main/resources</directory>
</resource>
<resource>
<filtering>true</filtering>
<directory>${basedir}/src/main/webapp/WEB-INF</directory>
<targetPath>${build.directory}/${build.finalName}/WEB-INF</targetPath>
<includes>
<include>**/*.properties</include>
</includes>
</resource>
</resources>
...
</build>
So, I am now able to keep cas.properties in it's original location, and
also make it change the values dynamically on build.
On 04/04/11 10:23, Trenton D. Adams wrote:
Hi Scott,
On 04/04/11 09:44, Scott Battaglia wrote:
Just a note that for 3.4.7 we moved the configuration of that property
configurer to its own file so that both applicationContext and
cas-servlet
reference the same file. It should also make it easier for you to
override
the property configurer itself.
Interesting.
We can still look into moving the cas.properties file if you think we
need
to.
I don't think you "need to". As I said, I can work around it using the
exclude functionality of the war plugin.
Just thought I would bring it forward as a potential solution to allow
the use of profiles and maven properties, without any extra effort.
I like to have my web applications do resource filtering to replace all
the configuration entries with appropriate values for a developer, by
default. Then, for production values, I use a profile. The only thing
not automatically replaced during build, would be security sensitive
data like passwords.
Anyhow, if it is in src/main/resources, then the war plugin
configuration is not needed, the cas-servlet.xml and
propertyFileConfigurer.xml do not need to be overridden, and you get the
added benefit of being able to do resource filtering from the "standard"
location (src/main/resources).
Cheers,
Scott
On Mon, Apr 4, 2011 at 11:30 AM, Trenton D.
Adams<[email protected]>wrote:
Hi Guys,
Has it been considered that cas.properties, and possibly other configs,
should be stored in src/main/resources, so as adopt the standard maven
practise of deploying the config files to WEB-INF/classes, and also take
advantage of the standard maven resource filtering configuration such as
below? This then allows the automatic configuration of cas.properties,
without developers having a need to modify them.
<build>
...
<resources>
<!-- Copy configurations over to webapp folder -->
<resource>
<filtering>true</filtering>
<directory>${basedir}/src/main/resources</directory>
</resource>
</resources>
...
</build>
As it is, we have moved it and excluded JASIG's cas.properties from the
overlay.
We did this via the maven war plugin, and having our own
propertyFileConfigurer.xml and cas-servlet.xml. However, if there's a
better way, I'd like to know. For example, I did try creating our own
properties file, and put ${} property references in cas.properties,
so that
I wouldn't have to change the cas-servlet.xml and
propertyFileConfigurer.xml, but that didn't work. I also attempted to
create a second propertyFileConfigurer.xml to load our properties,
but then
the CAS properties don't get loaded.
Example war plugin config below.
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<version>2.1.1</version>
<configuration>
<overlays>
<overlay>
<groupId>org.jasig.cas</groupId>
<artifactId>cas-server-webapp</artifactId>
<excludes>
<exclude>WEB-INF/cas.properties</exclude>
</excludes>
</overlay>
</overlays>
</configuration>
</plugin>
Thanks.
--
Trenton D. Adams
Senior Systems Analyst/Web Software Developer
Navy Penguins at your service!
Athabasca University
(780) 675-6195
:wq!
__ This communication is intended for the use of the recipient to whom
it
is addressed, and may contain confidential, personal, and or privileged
information. Please contact us immediately if you are not the intended
recipient of this communication, and do not copy, distribute, or take
action relying on it. Any communications received in error, or
subsequent reply, should be deleted or destroyed.
---
--
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-dev
--
Trenton D. Adams
Senior Systems Analyst/Web Software Developer
Navy Penguins at your service!
Athabasca University
(780) 675-6195
:wq!
--
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-dev
