Re: configuration files for war deployments
thanks for all your suggestions on this. it seems that an exploded format is what most people deploy with just to make configuration easier?? anyway, i'll think through some of these ideas. much appreciated, patrick On 8/27/05, QM [EMAIL PROTECTED] wrote: On Fri, Aug 26, 2005 at 11:47:54PM -0700, Patrick Lacson wrote: : jdbc config options, common file system info, http urls for external : sites, things of that nature. we have a complex multitenant system : that needs to be configured by our sysadmins. What about having separate config files that can be compiled into the WAR at build time? A little Ant magic, a few replacement rules, and you're in business. Your sysadmins will (hopefully) like that more because there would be less for them to do. : currently we are hosting it on tomcat and later possibly websphere. i : was wondering if there was a way to do this portably. Portability is a broad term; you must decide the direction and depth of your portability and go from there. For example: using an external file means you have to specify an absolute path. That's portable between containers but not OS flavors. : how about reading comments from an external url? has this been done before? URL is also an option, silly me for not having mentioned it. -but again, your app has to somehow bootstrap this information, which means you must include the URL in your app at build time. Furthermore, the service that responds to the URL call must be available at all times or your webapps won't start. =) You could get creative with the URL bit: include the context name as a parameter, let the remote service analyze the incoming IP address, etc... but that would require some serious planning and design such that you don't end up with a nightmare long-term. Using an exploded-dir format webapp would require the least work on your part. While it's not techically required by the spec (only WAR files are required, when I last checked), I'd doubt there are any containers that don't support it. Pick your poison. -QM -- software -- http://www.brandxdev.net/ tech news -- http://www.RoarNetworX.com/ code scan -- http://www.JxRef.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Patrick - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: configuration files for war deployments
Hi Patrick, On 26 Aug 2005 at 17:24, QM wrote: On Fri, Aug 26, 2005 at 02:16:26AM +0800, Patrick Lacson wrote: : I know that's typically where they go, but if the file is inside the : .war, how is the file going to be configured by the sysadming folks? Our approach to this problem has been to: 1. Have a configuration file with application-specific properties that lives in the WEB-INF tree and is loaded in the usual way via a context-parameter reference in web.xml. This file contains properties that vary from one application to another, but are the same for every server. 2. Within our application-specific properties file (I'll call it myapp.properties, we define a relative reference to a server- specific properties file (myapp.local.properties). That file is then located and loaded by code that tries several different ways to locate the local properties file - see below On our app server, we define a directory that contains all of our configuration files. Each application's configuration files is in its own subdirectory under the main config directory. So, for example, if our main config directory is c:\serverconfig, under this will be a subdirectory for each web application, containing that web application's configuration file(s) - c:\serverconfig\myapp1 etc.. The main configuration path (c:\serverconfig in the example above) is then placed in Tomcat's class path - in my development environment (windoze) I do this by opening the Tomcat configuration applet and adding it to the Java Classpath on the Java tab. As mentioned before each application's properties file contains a relative reference to it's local properties file. So our application myapp1 will have in its myapp1.properties file (in its WEB-INF directory) a property called local-properties-path with the value myapp1/myapp1.local.properties. In our application, we locate the local properties file by: 1. using the .getClassLoader().getResourceAsStream(..) method first (using the relative path loaded from our application properties file, it could also probably come straight from a context-parameter in web.xml I guess); 2. If that fails to locate the file, we then recursively load the classloader's parent (using the .getClassLoader().getParent() method) and use that to try and load the file, either until we find it, or until we reach the top parent; 3. If we've still not located the file, we try simply instantiating a File object using the relative path; Using this methodology, we've been able to load local server-specific properties files in Tomcat on Windows and in OC4J on Windows and Unix (don't have the actual OS to hand sorry). HTH, Rob Hills MBBS, Grad Dip Com Stud, MACS Senior Consultant Netpaver Web Solutions Tel:(08) 9485 2555 Mob:(0412) 904 357 Fax:(08) 9485 2555 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Problem using FORM based authetication (Tomcat 4.1)
I have a small database application that I am developing. I have set up a JNDI resource in order to access it in the application. This is defined just inside host ... level in server.xml (password changed) Resource auth=Container name=jdbc/family_tree type=javax.sql.DataSource/ ResourceParams name=jdbc/family_tree parameter namefactory/name valueorg.apache.commons.dbcp.BasicDataSourceFactory/value /parameter parameter namedriverClassName/name valueorg.postgresql.Driver/value /parameter parameter nameurl/name valuejdbc:postgresql://127.0.0.1:5432/family_tree/value /parameter parameter nameusername/name valuetomcat4/value /parameter parameter namepassword/name valuexxx/value /parameter parameter namemaxActive/name value20/value /parameter parameter namemaxIdle/name value10/value /parameter parameter namemaxWait/name value-1/value /parameter /ResourceParams I have decided to try and use the same database to authenticate users to a certain part of the web site. So added the appropriate user and user_role tables, and added the appropriate Realm statement into my server.xml file (just inside the Context ... tag ) Thus: Realm className=org.apache.catalina.realm.DataSourceRealm debug=99 dataSourceName=java:/comp/env/jdbc/family_tree userTable=users userNameCol=user_name userCredCol=user_pass userRoleTable=user_roles roleNameCol=role_name/ I have got it set up so that the particular pages I want to protect are in a subdirectory and can therefore use a url pattern to invoke the handler. security-constraint web-resource-collection web-resource-nameEdit part of application/web-resource-name url-pattern/security/*/url-pattern /web-resource-collection auth-constraint role-nameeditor/role-name /auth-constraint /security-constraint login-config auth-methodFORM/auth-method realm-nameFamily Tree Editor/realm-name form-login-config form-login-page/Login.page/form-login-page form-error-page/Error.page/form-error-page /form-login-config /login-config security-role descriptionThe role for Family Tree Editor/description role-nameeditor/role-name /security-role When an attempt is made to access these urls, my Login.page (I am using tapestry with friendly URL direction - so these names cause tapestry to display the form with my own site border round them) is correctly displayed. However whatever I do to login the Error.page is activated. Looking at the logs I get a message saying that the jndi name can't be found 2005-08-28 08:32:07 DataSourceRealm[/famtree]: Exception performing authentication javax.naming.NameNotFoundException: Name java:comp is not bound in this Context at org.apache.naming.NamingContext.lookup(NamingContext.java:764) at org.apache.naming.NamingContext.lookup(NamingContext.java:147) at org.apache.catalina.realm.DataSourceRealm.open(DataSourceRealm.java:421) at org.apache.catalina.realm.DataSourceRealm.authenticate(DataSourceRealm.java:269) at org.apache.catalina.authenticator.FormAuthenticator.authenticate(FormAuthenticator.java:227) ... However, I know that this name works for my application where I am using iBATIS to access the database. The following transactionManager type=JDBC dataSource type=JNDI property name=DataSource value=java:/comp/env/jdbc/family_tree/ /dataSource /transactionManager is some simple XML that defines to iBATIS where to find the database, and this is working. Can someone tell me what I am doing wrong. I have scanned all the docs I
RE: configuration files for war deployments
Patrick, Sorry for the late response. You have received quite a few ideas, but I did not see one quite like what we do. We use the deployer utility to deploy our application and have customized (just added a task actually) the build.xml file to make system-specific changes to our war and then re-jar/war it. In case you are not familiar with the tomcat deployer it is a companion download. For example if you downloaded jakarta-tomcat-5.5.9.zip, there is a corresponding jakarta-tomcat-5.5.9-deployer.zip to download. The deployer is really just a few jar files with tomcat-specific ant tasks, a build.xml and and example deployer.properties file. The ant build file has targets to compile (including JSPs), undeploy and deploy an application to one or more tomcats. The deployer.properties file controls this if the defaults are not good. We just added a coupld of ant replace and copy tasks that modify various properties and xml files for the target host. It means that on each host that needs specific configuration you: - explode the war file - run ant compile undeploy deploy You now have a customized web application installed. Hope it helps - Richard -Original Message- From: Patrick Lacson [mailto:[EMAIL PROTECTED] Sent: Thursday, August 25, 2005 8:32 AM To: Tomcat User-List Subject: configuration files for war deployments hi All, If I were to deploy my application as a .war file, where do I place the .properties configuration files? I know there's the option of auto-expanding the war file at deployment, but is there a way to keep the war file unexpanded and provide an external .properties file for the web app to read from? Many thanks -- Patrick - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Where can I find specs for ALL the xml tags that can be used in server.xml.
Where can I find specs for all the tags in server.xml In particular, trying to find out why I used to be able to access a JNDI datasource and now can't. All I did was move the resource ... tag from the local Context ... to the GlobalNamingResources. Move it back and it starts working again. -- Alan Chandler http://www.chandlerfamily.org.uk - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
very strange 'documentroot' problems
Hi, I installed Apache Tomcat/5.0.28 and got it running, when i visit localhost:8080, i get the standard 'If you're seeing this page via a web browser, it means you've setup Tomcat successfully. Congratulations!' message. So far so good. Then it says: 'As you may have guessed by now, this is the default Tomcat home page. It can be found on the local filesystem at: $CATALINA_HOME/webapps/ROOT/index.jsp' When i start it says Using CATALINA_HOME: '/usr/local/jakarta-tomcat-5.0.28' So it seems logic the default Tomcat home page would be /usr/local/jakarta-tomcat-5.0.28/webapps/ROOT/index.jsp. And if i open that file, it indeed looks like the default Tomcat home page... BUT when i edit the file, or even completely remove it, i still get to see 'If you're seeing this page via a web browser, it means you've setup Tomcat successfully. Congratulations!' -messages! And even stranger, i completely searched the whole harddisk with grep -r string * to see if Tomcat maybe is using another index.jsp, but without any succes... Anyone any idea??? Thanks!
RE: very strange 'documentroot' problems
From: Arjan [mailto:[EMAIL PROTECTED] Subject: very strange 'documentroot' problems BUT when i edit the file, or even completely remove it, i still get to see 'If you're seeing this page via a web browser, it means you've setup Tomcat successfully. The .jsp files of the ROOT app (as well as those of most of the other sample apps) is precompiled. What's actually being executed is org/apache/jsp/index_jsp.class, which can be found in webapps/ROOT/WEB-INF/lib/catalina-root.jar. You should be able to just delete (or change the extension of) that jar, and then the .jsp file will be used. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
When would TC (5.0.19) not send back (or even log) a response?
I saw this interesting request show up in my log file: 2005-08-28 20:11:08 RequestDumperValve[catalina]: REQUEST URI =/cgi-bin/jud.cgi 2005-08-28 20:11:08 RequestDumperValve[catalina]: authType=null 2005-08-28 20:11:08 RequestDumperValve[catalina]: characterEncoding=null 2005-08-28 20:11:08 RequestDumperValve[catalina]: contentLength=-1 2005-08-28 20:11:08 RequestDumperValve[catalina]:contentType=null 2005-08-28 20:11:08 RequestDumperValve[catalina]:contextPath= 2005-08-28 20:11:08 RequestDumperValve[catalina]: header=host=www.worldandsearch.com 2005-08-28 20:11:08 RequestDumperValve[catalina]: header=accept=*/* 2005-08-28 20:11:08 RequestDumperValve[catalina]: header=pragma=no-cache 2005-08-28 20:11:08 RequestDumperValve[catalina]: header=user-agent=Mozilla/4.0 (compatible; MSIE 4.01; Windows NT) 2005-08-28 20:11:08 RequestDumperValve[catalina]: locale=en_US 2005-08-28 20:11:08 RequestDumperValve[catalina]: method=GET 2005-08-28 20:11:08 RequestDumperValve[catalina]: pathInfo=null 2005-08-28 20:11:08 RequestDumperValve[catalina]: protocol=HTTP/1.1 2005-08-28 20:11:08 RequestDumperValve[catalina]:queryString=null 2005-08-28 20:11:08 RequestDumperValve[catalina]: remoteAddr=61.221.32.114 2005-08-28 20:11:08 RequestDumperValve[catalina]: remoteHost=61.221.32.114 2005-08-28 20:11:08 RequestDumperValve[catalina]: remoteUser=null 2005-08-28 20:11:08 RequestDumperValve[catalina]: requestedSessionId=null 2005-08-28 20:11:08 RequestDumperValve[catalina]: scheme=http 2005-08-28 20:11:08 RequestDumperValve[catalina]: serverName=www.worldandsearch.com 2005-08-28 20:11:08 RequestDumperValve[catalina]: serverPort=80 2005-08-28 20:11:08 RequestDumperValve[catalina]: servletPath=/cgi-bin/jud.cgi 2005-08-28 20:11:08 RequestDumperValve[catalina]: isSecure=false == And then there's nothing noting what the response was, which should have been a 404 since I've no such host defined. I've got a valve defined that will intercept requests for a host not defined in server.xml and send back a 404 response instead of allowing the request to flow to the default host for the engine. Under what conditions will Tomcat (5.0.19) not send (or log) any response?
Re: very strange 'documentroot' problems
Caldarale, Charles R wrote: The .jsp files of the ROOT app (as well as those of most of the other sample apps) is precompiled. What's actually being executed is org/apache/jsp/index_jsp.class, which can be found in webapps/ROOT/WEB-INF/lib/catalina-root.jar. You should be able to just delete (or change the extension of) that jar, and then the .jsp file will be used. Thanks a lot! Maybe something to be documented, i couldn't find anything in the docs and i asume i'm not the only Tomcat-newbie in this world ;) Thanks again.
Re: Where can I find specs for ALL the xml tags that can be used in server.xml.
On 8/29/05, Alan Chandler [EMAIL PROTECTED] wrote: Where can I find specs for all the tags in server.xml I use these pages. it explains the elements used in the server.xml. http://jakarta.apache.org/tomcat/tomcat-5.5-doc/config/index.html -- rgds Anto Paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
