Best practice for upgrading

13 messages

Best practice for upgrading

Reply Threaded

Hi all,

I'm quite new to both Tomcat and CAS-Server but I got everything to work.

Now, I'm quite unsure how to upgrade to the recent version (3.3.3). Is
there any information on this? Do I have to build a new .war file?

We're also using Alfresco which stores it's configuration outside the
webapps tree, so that you can safely upgrade. Is this also possible
with CAS?

TIA!

Greets,
Matthias.

--
You are currently subscribed to [hidden email] as: [hidden email]
To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user

Scott Battaglia-2

Re: Best practice for upgrading

Reply Threaded

Our recommendation is always to use the Maven2 WAR Overlay method which keeps your code and configuration separate from the main distribution.

On Mon, Aug 10, 2009 at 8:17 AM, Matthias Debus <[hidden email]> wrote:

Hi all,

I'm quite new to both Tomcat and CAS-Server but I got everything to work.

Now, I'm quite unsure how to upgrade to the recent version (3.3.3). Is
there any information on this? Do I have to build a new .war file?

We're also using Alfresco which stores it's configuration outside the
webapps tree, so that you can safely upgrade. Is this also possible
with CAS?

TIA!

Greets,
Matthias.

--
You are currently subscribed to [hidden email] as: [hidden email]
To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user

-- 
You are currently subscribed to [hidden email] as: [hidden email]
To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user

Andrew Feller

Re: Best practice for upgrading

Reply Threaded

Some javascript/style in this post has been disabled (why?)

Re: [cas-user] Best practice for upgrading Scott,

I must admit I am ignorant about the overlay method. Does this only work with pre-compiled code (JARs) or will it also compile code against CAS source pulled in the pom.xml?

Thanks,
A-

On 8/10/09 8:58 AM, "Scott Battaglia" <scott.battaglia@...> wrote:

Our recommendation is always to use the Maven2 WAR Overlay method which keeps your code and configuration separate from the main distribution.

On Mon, Aug 10, 2009 at 8:17 AM, Matthias Debus <matthias.debus@...> wrote:

Hi all,

I'm quite new to both Tomcat and CAS-Server but I got everything to work.

Now, I'm quite unsure how to upgrade to the recent version (3.3.3). Is
there any information on this? Do I have to build a new .war file?

We're also using Alfresco which stores it's configuration outside the
webapps tree, so that you can safely upgrade. Is this also possible
with CAS?

TIA!

Greets,
Matthias.

--
You are currently subscribed to cas-user@... as: scott.battaglia@...
To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user

--
Andrew Feller, Business System Programmer
LSU University Information Services
200 Frey Computing Services Center
Baton Rouge, LA 70803
Office: 225.578.3737
Fax: 225.578.6400

-- 
You are currently subscribed to [hidden email] as: [hidden email]
To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user

Matthias Debus

Re: Best practice for upgrading

Reply Threaded

In reply to this post by Scott Battaglia-2

Scott,

thanks, but do you have some links to tutorials or howtos?

As mentioned I'm new to this and really don't have a clue how to use Maven.

Greets,
Matthias

2009/8/10 Scott Battaglia <[hidden email]>:

> Our recommendation is always to use the Maven2 WAR Overlay method which
> keeps your code and configuration separate from the main distribution.
>
>
>
> On Mon, Aug 10, 2009 at 8:17 AM, Matthias Debus <[hidden email]>
> wrote:
>>
>> Hi all,
>>
>> I'm quite new to both Tomcat and CAS-Server but I got everything to work.
>>
>> Now, I'm quite unsure how to upgrade to the recent version (3.3.3). Is
>> there any information on this? Do I have to build a new .war file?
>>
>> We're also using Alfresco which stores it's configuration outside the
>> webapps tree, so that you can safely upgrade. Is this also possible
>> with CAS?
>>
>> TIA!
>>
>> Greets,
>> Matthias.
>>
>> --
>> You are currently subscribed to [hidden email] as:
>> [hidden email]
>> To unsubscribe, change settings or access archives, see
>> http://www.ja-sig.org/wiki/display/JSG/cas-user
>
> --
> You are currently subscribed to [hidden email] as:
> [hidden email]
> To unsubscribe, change settings or access archives, see
> http://www.ja-sig.org/wiki/display/JSG/cas-user

--
You are currently subscribed to [hidden email] as: [hidden email]
To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user

Eric Pierce

Re: Best practice for upgrading

Reply Threaded

In reply to this post by Andrew Feller

It works fine with pre-compiled JARs and source files. If you have
JAR files you need to include, just create a
'src/main/webapp/WEB-INF/lib' directory in your overlay directory and
drop the jars in.

Overlay setup instructions are here:
http://www.ja-sig.org/wiki/display/CASUM/Maintaining+local+customizations+using+Maven+2

Maven is an incredible time saver. When a new version of CAS comes
out, all I need to do is change the version numbers in pom.xml and
rebuild the project on my dev. server. I can quickly test our local
modifications to make sure nothing broke with the upgrade, fix
anything that did break and push the changes (including the pom.xml)
into my SVN repo. Then upgrading production is easy as:

svn co https://www.ja-sig.org/svn/cas3/tags/cas-3-3-3-final/
cd cas-3-3-3-final
mvn clean package install
svn co https://dev.usf.edu/svn/CAS/3-3-3/cas-server-usf
cd cas-server-usf
mvn clean package install

The WAR file is now in 'cas-server-usf/target' and is ready to be
deployed. You can even configure Maven to deploy the WAR for you, but
I haven't gotten that fancy with it :)

-Eric

Eric Pierce, RHCE -- University of South Florida -- (813) 974-8868
-- [hidden email]

On Mon, Aug 10, 2009 at 10:38 AM, Andrew Feller<[hidden email]> wrote:

> Scott,
>
> I must admit I am ignorant about the overlay method. Does this only work
> with pre-compiled code (JARs) or will it also compile code against CAS
> source pulled in the pom.xml?
>
> Thanks,
> A-
>
> On 8/10/09 8:58 AM, "Scott Battaglia" <[hidden email]> wrote:
>
> Our recommendation is always to use the Maven2 WAR Overlay method which
> keeps your code and configuration separate from the main distribution.
>
>
>
> On Mon, Aug 10, 2009 at 8:17 AM, Matthias Debus <[hidden email]>
> wrote:
>
> Hi all,
>
> I'm quite new to both Tomcat and CAS-Server but I got everything to work.
>
> Now, I'm quite unsure how to upgrade to the recent version (3.3.3). Is
> there any information on this? Do I have to build a new .war file?
>
> We're also using Alfresco which stores it's configuration outside the
> webapps tree, so that you can safely upgrade. Is this also possible
> with CAS?
>
> TIA!
>
> Greets,
> Matthias.
>
> --
> You are currently subscribed to [hidden email] as:
> [hidden email]
> To unsubscribe, change settings or access archives, see
> http://www.ja-sig.org/wiki/display/JSG/cas-user
>
> --
> Andrew Feller, Business System Programmer
> LSU University Information Services
> 200 Frey Computing Services Center
> Baton Rouge, LA 70803
> Office: 225.578.3737
> Fax: 225.578.6400
>
> --
> You are currently subscribed to [hidden email] as: [hidden email]
> To unsubscribe, change settings or access archives, see
> http://www.ja-sig.org/wiki/display/JSG/cas-user

--
You are currently subscribed to [hidden email] as: [hidden email]
To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user

Andrew Feller

Re: Best practice for upgrading

Reply Threaded

Eric,

Thanks for taking the time with that response; most helpful.

The only thing that I can think of is that I would like to include custom
code for all of my CAS servers, however I need to include different versions
of particular configuration files depending on the server. My test servers
use different Memcached configurations than my production servers do, etc.

Do you have any thoughts on how this should be handled?

Thanks once again,
A-

On 8/10/09 10:04 AM, "Eric Pierce" <[hidden email]> wrote:

> It works fine with pre-compiled JARs and source files. If you have
> JAR files you need to include, just create a
> 'src/main/webapp/WEB-INF/lib' directory in your overlay directory and
> drop the jars in.
>
> Overlay setup instructions are here:
> http://www.ja-sig.org/wiki/display/CASUM/Maintaining+local+customizations+usin
> g+Maven+2
>
> Maven is an incredible time saver. When a new version of CAS comes
> out, all I need to do is change the version numbers in pom.xml and
> rebuild the project on my dev. server. I can quickly test our local
> modifications to make sure nothing broke with the upgrade, fix
> anything that did break and push the changes (including the pom.xml)
> into my SVN repo. Then upgrading production is easy as:
>
> svn co https://www.ja-sig.org/svn/cas3/tags/cas-3-3-3-final/
> cd cas-3-3-3-final
> mvn clean package install
> svn co https://dev.usf.edu/svn/CAS/3-3-3/cas-server-usf
> cd cas-server-usf
> mvn clean package install
>
> The WAR file is now in 'cas-server-usf/target' and is ready to be
> deployed. You can even configure Maven to deploy the WAR for you, but
> I haven't gotten that fancy with it :)
>
> -Eric
>
> Eric Pierce, RHCE -- University of South Florida -- (813) 974-8868
> -- [hidden email]
>
>
>
> On Mon, Aug 10, 2009 at 10:38 AM, Andrew Feller<[hidden email]> wrote:
>> Scott,
>>
>> I must admit I am ignorant about the overlay method. Does this only work
>> with pre-compiled code (JARs) or will it also compile code against CAS
>> source pulled in the pom.xml?
>>
>> Thanks,
>> A-
>>
>> On 8/10/09 8:58 AM, "Scott Battaglia" <[hidden email]> wrote:
>>
>> Our recommendation is always to use the Maven2 WAR Overlay method which
>> keeps your code and configuration separate from the main distribution.
>>
>>
>>
>> On Mon, Aug 10, 2009 at 8:17 AM, Matthias Debus <[hidden email]>
>> wrote:
>>
>> Hi all,
>>
>> I'm quite new to both Tomcat and CAS-Server but I got everything to work.
>>
>> Now, I'm quite unsure how to upgrade to the recent version (3.3.3). Is
>> there any information on this? Do I have to build a new .war file?
>>
>> We're also using Alfresco which stores it's configuration outside the
>> webapps tree, so that you can safely upgrade. Is this also possible
>> with CAS?
>>
>> TIA!
>>
>> Greets,
>> Matthias.
>>
>> --
>> You are currently subscribed to [hidden email] as:
>> [hidden email]
>> To unsubscribe, change settings or access archives, see
>> http://www.ja-sig.org/wiki/display/JSG/cas-user
>>
>> --
>> Andrew Feller, Business System Programmer
>> LSU University Information Services
>> 200 Frey Computing Services Center
>> Baton Rouge, LA 70803
>> Office: 225.578.3737
>> Fax: 225.578.6400
>>
>> --
>> You are currently subscribed to [hidden email] as: [hidden email]
>> To unsubscribe, change settings or access archives, see
>> http://www.ja-sig.org/wiki/display/JSG/cas-user

--
Andrew Feller, Business System Programmer
LSU University Information Services
200 Frey Computing Services Center
Baton Rouge, LA 70803
Office: 225.578.3737
Fax: 225.578.6400

--
You are currently subscribed to [hidden email] as: [hidden email]
To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user

Scott Battaglia-2

Re: Best practice for upgrading

Reply Threaded

We've externalized that configuration either using JNDI or Spring configuration files located outside of the WAR file.

On Mon, Aug 10, 2009 at 11:43 AM, Andrew Feller <[hidden email]> wrote:

Eric,

Thanks for taking the time with that response; most helpful.

The only thing that I can think of is that I would like to include custom
code for all of my CAS servers, however I need to include different versions
of particular configuration files depending on the server. My test servers
use different Memcached configurations than my production servers do, etc.

Do you have any thoughts on how this should be handled?

Thanks once again,
A-

On 8/10/09 10:04 AM, "Eric Pierce" <[hidden email]> wrote:

> It works fine with pre-compiled JARs and source files. If you have
> JAR files you need to include, just create a
> 'src/main/webapp/WEB-INF/lib' directory in your overlay directory and
> drop the jars in.
>
> Overlay setup instructions are here:
> http://www.ja-sig.org/wiki/display/CASUM/Maintaining+local+customizations+usin
> g+Maven+2
>
> Maven is an incredible time saver. When a new version of CAS comes
> out, all I need to do is change the version numbers in pom.xml and
> rebuild the project on my dev. server. I can quickly test our local
> modifications to make sure nothing broke with the upgrade, fix
> anything that did break and push the changes (including the pom.xml)
> into my SVN repo. Then upgrading production is easy as:
>
> svn co https://www.ja-sig.org/svn/cas3/tags/cas-3-3-3-final/
> cd cas-3-3-3-final
> mvn clean package install
> svn co https://dev.usf.edu/svn/CAS/3-3-3/cas-server-usf
> cd cas-server-usf
> mvn clean package install
>
> The WAR file is now in 'cas-server-usf/target' and is ready to be
> deployed. You can even configure Maven to deploy the WAR for you, but
> I haven't gotten that fancy with it :)
>
> -Eric
>
> Eric Pierce, RHCE -- University of South Florida -- (813) 974-8868
> -- [hidden email]
>
>
>
> On Mon, Aug 10, 2009 at 10:38 AM, Andrew Feller<[hidden email]> wrote:
>> Scott,
>>
>> I must admit I am ignorant about the overlay method. Does this only work
>> with pre-compiled code (JARs) or will it also compile code against CAS
>> source pulled in the pom.xml?
>>
>> Thanks,
>> A-
>>
>> On 8/10/09 8:58 AM, "Scott Battaglia" <[hidden email]> wrote:
>>
>> Our recommendation is always to use the Maven2 WAR Overlay method which
>> keeps your code and configuration separate from the main distribution.
>>
>>
>>
>> On Mon, Aug 10, 2009 at 8:17 AM, Matthias Debus <[hidden email]>
>> wrote:
>>
>> Hi all,
>>
>> I'm quite new to both Tomcat and CAS-Server but I got everything to work.
>>
>> Now, I'm quite unsure how to upgrade to the recent version (3.3.3). Is
>> there any information on this? Do I have to build a new .war file?
>>
>> We're also using Alfresco which stores it's configuration outside the
>> webapps tree, so that you can safely upgrade. Is this also possible
>> with CAS?
>>
>> TIA!
>>
>> Greets,
>> Matthias.
>>
>> --
>> You are currently subscribed to [hidden email] as:
>> [hidden email]
>> To unsubscribe, change settings or access archives, see
>> http://www.ja-sig.org/wiki/display/JSG/cas-user
>>
>> --
>> Andrew Feller, Business System Programmer
>> LSU University Information Services
>> 200 Frey Computing Services Center
>> Baton Rouge, LA 70803
>> Office: 225.578.3737
>> Fax: 225.578.6400
>>
>> --
>> You are currently subscribed to [hidden email] as: [hidden email]
>> To unsubscribe, change settings or access archives, see
>> http://www.ja-sig.org/wiki/display/JSG/cas-user

--
Andrew Feller, Business System Programmer
LSU University Information Services
200 Frey Computing Services Center
Baton Rouge, LA 70803
Office: 225.578.3737
Fax: 225.578.6400

--

You are currently subscribed to [hidden email] as: [hidden email]

To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user

-- 
You are currently subscribed to [hidden email] as: [hidden email]
To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user

Eric Pierce

Re: Best practice for upgrading

Reply Threaded

In reply to this post by Andrew Feller

I'm using PropertyOverrideConfigurer and an external config file to configure the servers. I added the following bean to deployerConfigContext.xml and auditTrailContext:

     <bean class="org.springframework.beans.factory.config.PropertyOverrideConfigurer"
        p:location="file:/usr/local/etc/cas-connection.properties"
        p:ignoreResourceNotFound="false" />

And then all of the configuration in the rest of the file is generic -- I've got all of the config options that are the same across all my servers (search filters, baseDN, etc) but all of the connection parameters are blank. Then /usr/local/etc/cas-connection.properties has all of the server-specific info:

contextSource.urls=ldap://localhost:389,ldap://example.edu:389
contextSource.userDn=uid=admin,o=example.edu
contextSource.password=secret

ServicesdataSource.driverClassName=com.mysql.jdbc.Driver
ServicesdataSource.url=jdbc:mysql://localhost:3306/cas?autoReconnect=true
ServicesdataSource.username=root
ServicesdataSource.password=secret

AuditDataSource.driverClassName=com.mysql.jdbc.Driver
AuditDataSource.url=jdbc:mysql://localhost:3306/audit?autoReconnect=true
AuditDataSource.username=root
AuditDataSource.password=secret

Eric Pierce, RHCE -- University of South Florida -- (813) 974-8868 -- [hidden email]

On Mon, Aug 10, 2009 at 11:43 AM, Andrew Feller <[hidden email]> wrote:
>
> Eric,
>
> Thanks for taking the time with that response; most helpful.
>
> The only thing that I can think of is that I would like to include custom
> code for all of my CAS servers, however I need to include different versions
> of particular configuration files depending on the server. My test servers
> use different Memcached configurations than my production servers do, etc.
>
> Do you have any thoughts on how this should be handled?
>
> Thanks once again,
> A-
>
>
>
> On 8/10/09 10:04 AM, "Eric Pierce" <[hidden email]> wrote:
>
> > It works fine with pre-compiled JARs and source files. If you have
> > JAR files you need to include, just create a
> > 'src/main/webapp/WEB-INF/lib' directory in your overlay directory and
> > drop the jars in.
> >
> > Overlay setup instructions are here:
> > http://www.ja-sig.org/wiki/display/CASUM/Maintaining+local+customizations+usin
> > g+Maven+2
> >
> > Maven is an incredible time saver. When a new version of CAS comes
> > out, all I need to do is change the version numbers in pom.xml and
> > rebuild the project on my dev. server. I can quickly test our local
> > modifications to make sure nothing broke with the upgrade, fix
> > anything that did break and push the changes (including the pom.xml)
> > into my SVN repo. Then upgrading production is easy as:
> >
> > svn co https://www.ja-sig.org/svn/cas3/tags/cas-3-3-3-final/
> > cd cas-3-3-3-final
> > mvn clean package install
> > svn co https://dev.usf.edu/svn/CAS/3-3-3/cas-server-usf
> > cd cas-server-usf
> > mvn clean package install
> >
> > The WAR file is now in 'cas-server-usf/target' and is ready to be
> > deployed. You can even configure Maven to deploy the WAR for you, but
> > I haven't gotten that fancy with it :)
> >
> > -Eric
> >
> > Eric Pierce, RHCE -- University of South Florida -- (813) 974-8868
> > -- [hidden email]
> >
> >
> >
> > On Mon, Aug 10, 2009 at 10:38 AM, Andrew Feller<[hidden email]> wrote:
> >> Scott,
> >>
> >> I must admit I am ignorant about the overlay method. Does this only work
> >> with pre-compiled code (JARs) or will it also compile code against CAS
> >> source pulled in the pom.xml?
> >>
> >> Thanks,
> >> A-
> >>
> >> On 8/10/09 8:58 AM, "Scott Battaglia" <[hidden email]> wrote:
> >>
> >> Our recommendation is always to use the Maven2 WAR Overlay method which
> >> keeps your code and configuration separate from the main distribution.
> >>
> >>
> >>
> >> On Mon, Aug 10, 2009 at 8:17 AM, Matthias Debus <[hidden email]>
> >> wrote:
> >>
> >> Hi all,
> >>
> >> I'm quite new to both Tomcat and CAS-Server but I got everything to work.
> >>
> >> Now, I'm quite unsure how to upgrade to the recent version (3.3.3). Is
> >> there any information on this? Do I have to build a new .war file?
> >>
> >> We're also using Alfresco which stores it's configuration outside the
> >> webapps tree, so that you can safely upgrade. Is this also possible
> >> with CAS?
> >>
> >> TIA!
> >>
> >> Greets,
> >> Matthias.
> >>
> >> --
> >> You are currently subscribed to [hidden email] as:
> >> [hidden email]
> >> To unsubscribe, change settings or access archives, see
> >> http://www.ja-sig.org/wiki/display/JSG/cas-user
> >>
> >> --
> >> Andrew Feller, Business System Programmer
> >> LSU University Information Services
> >> 200 Frey Computing Services Center
> >> Baton Rouge, LA 70803
> >> Office: 225.578.3737
> >> Fax: 225.578.6400
> >>
> >> --
> >> You are currently subscribed to [hidden email] as: [hidden email]
> >> To unsubscribe, change settings or access archives, see
> >> http://www.ja-sig.org/wiki/display/JSG/cas-user
>
> --
> Andrew Feller, Business System Programmer
> LSU University Information Services
> 200 Frey Computing Services Center
> Baton Rouge, LA 70803
> Office: 225.578.3737
> Fax: 225.578.6400
>
>
>
> --
> You are currently subscribed to [hidden email] as: [hidden email]
> To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
>

-- 
You are currently subscribed to [hidden email] as: [hidden email]
To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user

bmelloni

RE: Best practice for upgrading

Reply Threaded

Some javascript/style in this post has been disabled (why?)

We use a variation of this approach in most of our projects, by taking advantage of the PropertyOverrideConfigurer��s behavior:

- This configurer was��designed so that you can have multiple PropertyOverrideConfigurer that load different files, even if they have the same properties.�� If a variable is defined/loaded multiple times, the definition from the last configurer is the one used.

- So, we define identical properties files for each environment, and load them in order of finality (PROD first, DEV last).

- We use ignoreResourceNotFound = ��tru�� so that missing properties files don��t cause problems.

The result is:

- In version control and DEV environments we have all of the properties files, allowing us to work and prepare them for all environments�� But only the DEV configuration gets used�� because its property configurer is the last one.

- When deploying to other environments we simply do��t deploy unnecessary properties files�� For example, in PROD we only deploy the PROD properties fil�� The missing files are ignored, and the app behaves as PRO�� with no fuss.

- We never have to modify the app, context or even property files during deployment.

From: [hidden email] [mailto:[hidden email]] On Behalf Of Eric Pierce
Sent: Monday, August 10, 2009 7:56 PM
To: [hidden email]
Subject: Re: [cas-user] Best practice for upgrading

-- 

You are currently subscribed to [hidden email] as: [hidden email]

To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user

-- 
You are currently subscribed to [hidden email] as: [hidden email]
To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user

Robert Oschwald

Re: Best practice for upgrading

Reply Threaded

Some javascript/style in this post has been disabled (why?)

Another approachf for this:

We use maven profiles.

You can define your props within each profile. (e.g. "dev", "prod1", "prod2" etc.)

"dev" is the default profile.

Advantage of this is, that you can define properties for maven plugins within each profile, too.

E.g. we define the "doCheck" and "doUpdate" props of the buildnumber-maven-plugin within each profile. With this, we ensure all resources are comitted before we create a production war file.

Robert

Am 11.08.2009 um 15:33 schrieb Bruno Melloni:

We use a variation of this approach in most of our projects, by taking advantage of the PropertyOverrideConfigurerÿÿs behavior:

-          This configurer wasÿÿ designed so that you can have multiple PropertyOverrideConfigurer that load different files, even if they have the same properties.ÿ If a variable is defined/loaded multiple times, the definition from the last configurer is the one used.
-          So, we define identical properties files for each environment, and load them in order of finality (PROD first, DEV last).
-          We use ignoreResourceNotFound = ÿÿtruÿÿ so that missing properties files donÿÿt cause problems.

The result is:

-          In version control and DEV environments we have all of the properties files, allowing us to work and prepare them for all environmentsÿÿ But only the DEV configuration gets usedÿÿ because its property configurer is the last one.
-          When deploying to other environments we simply doÿÿt deploy unnecessary properties filesÿÿ For example, in PROD we only deploy the PROD properties filÿÿÂ The missing files are ignored, and the app behaves as PROÿÿâÿ with no fuss.
-          We never have to modify the app, context or even property files during deployment.

-- 
You are currently subscribed to [hidden email] as: [hidden email]
To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user

Matthias Debus

Re: Best practice for upgrading

Reply Threaded

Now I have some ideas to start with.

Thanks all for your answers!

2009/8/11 Robert Oschwald <[hidden email]>:

> Another approachf for this:
> We use maven profiles.
> You can define your props within each profile. (e.g. "dev", "prod1", "prod2"
> etc.)
> "dev" is the default profile.
> Advantage of this is, that you can define properties for maven plugins
> within each profile, too.
> E.g. we define the "doCheck" and "doUpdate" props of the
> buildnumber-maven-plugin within each profile. With this, we ensure all
> resources are comitted before we create a production war file.
> Robert
> Am 11.08.2009 um 15:33 schrieb Bruno Melloni:
>
> We use a variation of this approach in most of our projects, by taking
> advantage of the PropertyOverrideConfigurerÿÿ™s behavior:
>
> -          This configurer wasÿÿ designed so that you can have multiple
> PropertyOverrideConfigurer that load different files, even if they have the
> same properties.ÿ If a variable is defined/loaded multiple times, the
> definition from the last configurer is the one used.
> -          So, we define identical properties files for each environment,
> and load them in order of finality (PROD first, DEV last).
> -          We use ignoreResourceNotFound = ÿÿœtruÿÿ€ so that missing
> properties files donÿÿ™t cause problems.
>
> The result is:
>
> -          In version control and DEV environments we have all of the
> properties files, allowing us to work and prepare them for all
> environmentsÿÿ But only the DEV configuration gets usedÿÿ€“ because its
> property configurer is the last one.
> -          When deploying to other environments we simply doÿÿ€™t deploy
> unnecessary properties filesÿÿ For example, in PROD we only deploy the PROD
> properties filÿÿÂ The missing files are ignored, and the app behaves as
> PROÿÿâÿ“ with no fuss.
> -          We never have to modify the app, context or even property files
> during deployment.
>
>
> --
> You are currently subscribed to [hidden email] as:
> [hidden email]
> To unsubscribe, change settings or access archives, see
> http://www.ja-sig.org/wiki/display/JSG/cas-user

--
You are currently subscribed to [hidden email] as: [hidden email]
To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user

bmelloni

CAS log4j on jBoss - HOWTO

Reply Threaded

In reply to this post by bmelloni

Some javascript/style in this post has been disabled (why?)

I couldn’t find anything explaining this, so I thought I’d share it.

In jBoss, the default configuration of CAS 3.3.1 makes its log entries to the jBoss logs as follows:

2009-10-28 03:19:07,621 INFO [STDOUT] 2009-10-28 03:19:07,590 INFO [org.jasig.cas.ticket.registry.support.DefaultTicketRegistryCleaner] - <Starting cleaning of expired tickets from ticket registry at [Wed Oct 28 03:19:07 CDT 2009]>

2009-10-28 03:19:08,106 INFO [STDOUT] 2009-10-28 03:19:08,106 INFO [org.jasig.cas.ticket.registry.support.DefaultTicketRegistryCleaner] - <0 found to be removed. Removing now.>

2009-10-28 03:19:08,106 INFO [STDOUT] 2009-10-28 03:19:08,106 INFO [org.jasig.cas.ticket.registry.support.DefaultTicketRegistryCleaner] - <Finished cleaning of expired tickets from ticket registry at [Wed Oct 28 03:19:08 CDT 2009]>

INFO inside STDOUT inside INFO… annoying at least. And you have to find log4j.properties in WEB-INF/classes if you want to tweak what gets logged.

After much banging my head against the wall I finally figured out how to make CAS use jBoss’ log:

a) Remove or rename CAS’ WEB-INF/classes/log4j.properties to something that won’t be read.

b) In web.xml comment out Log4jConfigListener.

c) In web.xml comment out log4jConfigLocation and log4jExposeWebAppRoot.

d) Remove or rename WEB-INF/lib/log4j*.jar to a non-jar extension so that jBoss’ customized log4j can take over.

Bingo! The log entries now look normal, and you can tweak what gets logged in jBoss’ conf/jboss-log4j.xml

-- 
You are currently subscribed to [hidden email] as: [hidden email]
To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user

Marvin Addison

Re: CAS log4j on jBoss - HOWTO

Reply Threaded

> I couldn’t find anything explaining this, so I thought I’d share it.

This likely should go on the Wiki. Most of the important points of
your configuration below are mentioned in the files that ship with
CAS, but I admit it would be nice to have some step-by-step
instructions to accompany the comments in the files.

> a) Remove or rename CAS’ WEB-INF/classes/log4j.properties to something
> that won’t be read.

We should explain how to do with with the Maven War overlay process.
log4j.properties has this comment at the top:

# For JBoss: Avoid to setup Log4J outside
$JBOSS_HOME/server/default/deploy/log4j.xml!

It would be helpful to demonstrate how to do that via Maven War overlay.

> b) In web.xml comment out Log4jConfigListener.

I believe that is pretty well documented in the web.xml file that
ships with CAS, but again, stepwise instructions are good.

> c) In web.xml comment out log4jConfigLocation and
> log4jExposeWebAppRoot.

This isn't strictly necessary since these context params are unused if
Log4jConfigListener is not active. It's probably a good idea to
remove them altogether, though, on JBoss.

> d) Remove or rename WEB-INF/lib/log4j*.jar to a non-jar extension so
> that jBoss’ customized log4j can take over.

I recall that this is required from when we deployed on JBoss.
http://docs.jboss.org/process-guide/en/html/logging.html doesn't
explicitly say to exclude log4j.jar from deployables, but it does say
that you MUST include log4j.jar and do classloader magic to do per-app
logging. I think it's reasonable to require the exclusion of
log4j.jar when deploying on JBoss to enable the standard
container-managed logging via jboss-log4j.xml. Again, the recommended
way to exclude a jar is via Maven War overlay.

I hope you'll consider posting stepwise instructions to the CASUM Wiki.

M

--
You are currently subscribed to [hidden email] as: [hidden email]
To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user