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]
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]
Re: configuration files for war deployments
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. granted this app is hosted and not deployed at customers, but currently we are hosting it on tomcat and later possibly websphere. i was wondering if there was a way to do this portably. how about reading comments from an external url? has this been done before? thanks for the comments. On 8/26/05, QM [EMAIL PROTECTED] 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? Webapps are meant to be fairly standalone. If you require that one be configured after it has been compiled, you really have two options: 1/ give it to the sysadmins in exploded-dir format so they can tweak the files, then just run the app as such 2/ create some resource outside of the app (database, file) that the app knows to load on startup. The downside to #2 is that it still requires your app to have some knowledge of the filesystem outside of itself. That inhibits portability, not to mention running separate instances of the app (with separate configurations, that is). Furthermore, to be completely portable across containers (though not necessarily operating systems) your app must operate on the fully-qualified path to the external file. There's no such idea as a relative file location when it comes to webapps. What would be in this external config file? -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
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]
Re: configuration files for war deployments
Patrick Lacson wrote: 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? Most likely, in the WEB-INF/classes dir, where it can be picked up by the classloader. Nix. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: configuration files for war deployments
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? Webapps are meant to be fairly standalone. If you require that one be configured after it has been compiled, you really have two options: 1/ give it to the sysadmins in exploded-dir format so they can tweak the files, then just run the app as such 2/ create some resource outside of the app (database, file) that the app knows to load on startup. The downside to #2 is that it still requires your app to have some knowledge of the filesystem outside of itself. That inhibits portability, not to mention running separate instances of the app (with separate configurations, that is). Furthermore, to be completely portable across containers (though not necessarily operating systems) your app must operate on the fully-qualified path to the external file. There's no such idea as a relative file location when it comes to webapps. What would be in this external config file? -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]
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]
RE: configuration files for war deployments
Your classpath, i.e. WEB-INF, or classes. -Original Message- From: Patrick Lacson [mailto:[EMAIL PROTECTED] Sent: August 25, 2005 11: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] !DSPAM:430de46a9881311912864!
Re: configuration files for war deployments
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? Surely we can't expect them to run jar xvf web/WEB-INF/myconfig.properties myapp.war Is there another location that is external from the .war file itself? Ideally I'd like something like tomcat webapps myapp.war conf myapp.properties is there a way for the webapp myapp.war to read the myapp.properties in a portable way across web containers (not just tomcat). thanks much. On 8/26/05, Phillip Qin [EMAIL PROTECTED] wrote: Your classpath, i.e. WEB-INF, or classes. -Original Message- From: Patrick Lacson [mailto:[EMAIL PROTECTED] Sent: August 25, 2005 11: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] !DSPAM:430de46a9881311912864! -- Patrick - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
