You know Chuck, it would probably work if I put Auto-deploy to "true" instead of false. (tried and it works).
On Wed, Aug 26, 2009 at 10:32 AM, Josh Gooding <josh.good...@gmail.com>wrote: > Wait a sec. The only <Context> element I have defined in my server.xml > file is here: > > <Engine name="Catalina" defaultHost="localhost"> > <Host name="localhost" appBase="d:/webapps/" > unpackWARs="true" autoDeploy="false" > xmlValidation="false" xmlNamespaceAware="false" > > > <Context docBase="ROOT" path="" /> > </Host> > > So I understand why they are not being ignored. I still figure that I > should be able to deploy a new project on the fly though and not have to > restart tomcat. > > > On Wed, Aug 26, 2009 at 10:29 AM, Josh Gooding <josh.good...@gmail.com>wrote: > >> Chuck, >> >> On this: >> >> > each of those has their own context.xml defined in the META-INF >> > directory of the project. >> >> > And those will be ignored, since you have them in server.xml. >> >> Something that I am not understanding. If the context.xml files are truly >> ignored how can each of the companies be able to login? >> Each company has their own DB/DB user/ and password defined in the >> <Resource> tag. I think I either did something REALLY weird on my tomcat or >> otherwise. >> >> You're saying if I create the conf/Catalina/[host]/[appName].xml I can add >> them on the fly? >> >> Next Q. >> >> would it be something like conf/Catalina/localhost/xyzcompany.xml? Isn't >> this for JAAS type realm? Means I have to switch my JDBC realm type to JAAS >> which I know nothing about. Could be a good time to learn it, but I'd rather >> keep the JDBC realm authentication if possible. >> >> I just changed the files (without changing the realm type) and it looks >> like nothing is going to work / authenticate. I am getting JAAS errors >> >> :Aug 26, 2009 10:07:46 AM org.apache.catalina.realm.JAASRealm authenticate >> SEVERE: Unexpected error >> java.lang.SecurityException: Unable to locate a login configuration >> at >> com.sun.security.auth.login.ConfigFile.<init>(ConfigFile.java:93): >> >> Let me ask this >> >> I know best practice is keeping the webapps directory inside of >> $CATALINA_HOME. In my situation, that's just not possible. I have a JDBC >> realm configured for authentication (not JAAS). I have my webapps stored on >> a physically separate drive for backup and restore reasons. What would I >> have to change in my configuration to be able to serve new projects under >> the new displaced webapps folder, keeping my JDBC realm configuration, and >> without having to restart tomcat each time I add one. Is it possible? >> >> It seems as though when I used the webapps folder in $CATALINA_HOME I >> could add and remove folders in the webapps folder and I didn't have to >> restart tomcat each time. >> - J >> >> >> On Thu, Aug 13, 2009 at 5:33 PM, Caldarale, Charles R < >> chuck.caldar...@unisys.com> wrote: >> >>> > From: Josh Gooding [mailto:josh.good...@gmail.com] >>> > Subject: Re: slight problem with Tomcat and Httpd working together. >>> > >>> > *Wait a sec, illegal as in (will throw an exception) or just bad >>> > practice? >>> >>> Illegal in that predictable behavior cannot be guaranteed. Tomcat is >>> pretty good about ignoring invalid attributes, but it's not perfect in that >>> regard, and problems may result. >>> >>> > I have a <context> defined in my server.xml's <host> for the >>> > deployments being hosted outside of $CATALINA_HOME/webapps >>> > directory >>> >>> That isn't illegal, but is extremely bad practice, since you can't modify >>> them without restarting Tomcat. By placing the <Context> elements in >>> conf/Catalina/[host]/[appName].xml, you can modify them as needed while >>> Tomcat is running. >>> >>> > each of those has their own context.xml defined in the META-INF >>> > directory of the project. >>> >>> And those will be ignored, since you have them in server.xml. >>> >>> > Are you saying that, that is wrong? >>> >>> Yup. >>> >>> - Chuck >>> >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >>> For additional commands, e-mail: users-h...@tomcat.apache.org >>> >>> >> >
