struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Kiley <jhki...@summa-tech.com>
Subject Re: Convention for keeping passwords out of struts.xml
Date Thu, 12 Mar 2009 18:49:53 GMT
Dave's right -- a good choice here is to keep that kind of data in a server
settings config file, and set up your application to pull the database
context info out of the JNDI context.  Check out
http://tomcat.apache.org/tomcat-5.5-doc/index.html
<http://tomcat.apache.org/tomcat-5.5-doc/index.html>for
details on this sort of thing.
jk

On Thu, Mar 12, 2009 at 2:50 PM, Security Management <
list-subscriptions@secmgmt.com> wrote:

> OK, my bad, I meant out of the applicationContext.xml
>
> I basically want to be able to tell someone to deploy a war file, edit a
> file outside of the "webroot" that has the settings in it, and startup
> tomcat.
>
> Then, my app would load that properties file and make the connection.
>
>
>
> -----Original Message-----
> From: Dave Newton [mailto:newton.dave@yahoo.com]
> Sent: Thursday, March 12, 2009 2:40 PM
> To: Struts Users Mailing List
> Subject: Re: Convention for keeping passwords out of struts.xml
>
> Security Management wrote:
> > What's the convention for keeping database settings out of struts.xml?
>
> Hmm, I guess I never even considered putting them in there.
>
> JNDI, Spring, and property files are the obvious choices, most DB
> technologies support creating a datasource in their own config as well.
>
> Dave
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>


-- 
Jim Kiley
Senior Technical Consultant | Summa
[p] 412.258.3346
http://www.summa-tech.com

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message