Re: Configuration free persistence?
From: Shapira, Yoav [EMAIL PROTECTED] Sent: Wednesday, May 12, 2004 6:27 AM Here's another take that's not seen often, but is intriguing: the java.util.prefs API. It uses the Registry on Windows, and the filesystem on unix, by default, but that can be changed. If you're running on Windows this is a decent approach (but then again if you're only running on windows you might make a whole set of choices based on that). No, that's very clever. I had forgotten about that API completely, and it handily solves the basic problem. I'll have to see how this works on a UNIX box (i.e. does it write to a ~/.java_prefs directory, or what). By using this API, you can plop a WAR on a server, then when the user first tries to use it, run them through a configuration wizard. Perfect. Thanx! Regards, Will Hartung ([EMAIL PROTECTED]) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Configuration free persistence?
Quoting Will Hartung [EMAIL PROTECTED]: From: Shapira, Yoav [EMAIL PROTECTED] Sent: Wednesday, May 12, 2004 6:27 AM Here's another take that's not seen often, but is intriguing: the java.util.prefs API. It uses the Registry on Windows, and the filesystem on unix, by default, but that can be changed. If you're running on Windows this is a decent approach (but then again if you're only running on windows you might make a whole set of choices based on that). No, that's very clever. I had forgotten about that API completely, and it handily solves the basic problem. I'll have to see how this works on a UNIX box (i.e. does it write to a ~/.java_prefs directory, or what). By using this API, you can plop a WAR on a server, then when the user first tries to use it, run them through a configuration wizard. You can also use Prevayler for object Prevalence... http://prevayler.codehaus.org/ If you use Prevayler in-memory only, then no configuration will be needed. Otherwise, if you want to persist across application restarts, then you will have to configure a directory to be writable. Of course, you can always use the configuration wizard to do this. Jake Perfect. Thanx! Regards, Will Hartung ([EMAIL PROTECTED]) - 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 free persistence?
To get the server info: ServletContext.getServerInfo() Personally - I would state my webapp needs a directory[or database] to write/load its configuration. The directory or datasource would be setup using JNDI. Then its up to the system admin to use the Container specific functionality to setup the JNDI space. No war file code/config to change. -Tim Will Hartung wrote: This is blasphemy, I know...but... As far as I know, there is no portable way that a generic Webapp bundled in a WAR, and dropped into a random container can persist information from one run of the container to another. On the one hand, there is no requirement that a WAR be exploded on deploy, and you certainly can't write to a resource that's bundled in a Jar file. On the other hand, you can get access to a Temp directory, and persist information there, but there is no guarantee that the information will be there when the container restarts. What this means is that you can not take a portable WAR, plop it into an arbitrary container, and then let the Webapp self configure with either reasonable defaults, or even through a web page. So, in order to get any portable persistence, you must: a) Explode the WAR, change the web.xml to add/change a parameter, and rebundle it and then deploy it. b) Require that a database be present and publish the datasource name that the web app is looking for, and assume that the user will configure their container properly (and, of course, your web app must be compatible with that database). c) set a system property on the command line telling the Webapp its persistence information d) create a less portable Webapp and rely on container specific behaviors on which you can make assumptions. Actually, is there even an API that lets the Webapp identify its container? There must be something somewhere, I just haven't looked. So, what are you folks trying/doing to make easily deployed WARs that needs to save setup options or even other real data? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Configuration free persistence?
Hi, It's not blasphemy ;) It's a good question. Many people take shortcuts / cut corners to get around this ;) b) Require that a database be present and publish the datasource name that the web app is looking for, and assume that the user will configure their container properly (and, of course, your web app must be compatible with that database). This option is the one most inline with the J2EE specification and spirit. Some people go further and include a DB with their application (e.g. MySQL, or postgreSQL), and then require the client/sysadmin to configure a directory where the DB can write. This is similar to your system property approach (option c in your original post). Here's another take that's not seen often, but is intriguing: the java.util.prefs API. It uses the Registry on Windows, and the filesystem on unix, by default, but that can be changed. If you're running on Windows this is a decent approach (but then again if you're only running on windows you might make a whole set of choices based on that). Yoav Shapira This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Configuration free persistence?
This is blasphemy, I know...but... As far as I know, there is no portable way that a generic Webapp bundled in a WAR, and dropped into a random container can persist information from one run of the container to another. On the one hand, there is no requirement that a WAR be exploded on deploy, and you certainly can't write to a resource that's bundled in a Jar file. On the other hand, you can get access to a Temp directory, and persist information there, but there is no guarantee that the information will be there when the container restarts. What this means is that you can not take a portable WAR, plop it into an arbitrary container, and then let the Webapp self configure with either reasonable defaults, or even through a web page. So, in order to get any portable persistence, you must: a) Explode the WAR, change the web.xml to add/change a parameter, and rebundle it and then deploy it. b) Require that a database be present and publish the datasource name that the web app is looking for, and assume that the user will configure their container properly (and, of course, your web app must be compatible with that database). c) set a system property on the command line telling the Webapp its persistence information d) create a less portable Webapp and rely on container specific behaviors on which you can make assumptions. Actually, is there even an API that lets the Webapp identify its container? There must be something somewhere, I just haven't looked. So, what are you folks trying/doing to make easily deployed WARs that needs to save setup options or even other real data? Regards, Will Hartung ([EMAIL PROTECTED]) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
