> From: "Justin Ruthenbeck" <[EMAIL PROTECTED]> > Sent: Wednesday, February 19, 2003 3:15 PM > Subject: Re: Best Logging practices
> I'm sure this is a contentious topic ripe for disagreement, but I see no > reason why a .war file should be read-only. The point of packaging your > application in such a way is to make a single cohesive unit that is > deployable across various vendors, right? Then why should users be forced, > if they don't want, to store application-SPECIFIC data outside of that > application. Seems to me that it only moves us away from our original > intention. My view is that the WAR file is identical to an EXE file (on Windows). A single, atomic unit that represents the application. Looked at in this way, you'll notice that most (if not all) applications never see the "inside" of the EXE file. They simply don't care. The reason that a WAR is not writeable is that there is simply no guarantee that the WAR is placed upon a writeable medium. One (albeit contrived) example is that the WAR could be shared across several different servers running simultaneously. So, in a Unix environment, you might have the WAR file in /usr/local/war/App.war. And its permissions might simply be -r--r--r--. Since there is no guarantee that the container even explode the WAR file, here you have a case that would prevent your application from writing. Also, in this example, you'd have a problem with multiple servers updating shared state in the common WAR. The other extreme may be that the WAR is buried in ReadOnly FLASH on a small embedded server someplace. All sorts of scenarios come to mind as to why a WAR could be read only. > In a large application, I'd agree that writing to resources inside the .war > file has limited advantages -- it's not like you want to store data inside > the war file instead of a database. But even large applications (such as > the one I'm working on) can eventually acquire awareness of their > surroudings and environment that they discover over time. If you force > users to supply this information by setting param values in the web.xml or > using external xml configuration files or properties files, then you've > lost the simplicity of a single application archive. Since the application > has no portable place to store this data, you're stuck specifying a > location outside the war and we're back to the same problem. Yup! Pain in the neck. Plus, you can not provide a "configuration free" web interface to adjust those parameters. You will always need at least ONE parameter from the user (where and how can I persist information). If they need to supply The One parameter, might as well toss in the rest as well. > Seems better to me to allow an application to change its own configuration > in cases like this -- regardless of whether the app is packed or > unpacked. Think of this as application meta-data -- data that an > application would want to store persistently and, for sake of consistency, > should be stored along with other application configuration information > inside the war. For small applications with very limited data, this could > even be a central data store and would allow the movement of applications > between servers and hosts without the need to worry about file > compatibility, directory structures, or permissions. Now, I'm not really up to speed on this (I only know it exists, and I've read a couple paragraphs of the spec). In many ways the new Preferences API handles some of this. It seems that the Pref API is supplied, and implemented by JDK 1.4. I suppose that it's configurable in some way at the JVM level, being as it's supposed to be backend neutral. But it seems like it offers a "free", simple Windows Registry-esque functonality to Java programs, including WARs. If you don't mind limiting your WAR to JDK 1.4+, then you have this capability now: a simple mechanism to save configuration options and what not. This mechanism addresses a lot of issues for WARs I think. I, too, would like to have a "standard" mechanism to help configure WARs that is external to the WAR, yet perhaps maintained by the container. For example, (maybe Tomcat does this, I'd have to look), it would be nice to have access to the JNDI namespace (like env-entry's) at, say, the Context level within the container that lets you specify local configuration options without cracking the WAR. The trick, of course, would be to not have the WARs env-entry's overwrite the locally specified ones. But, if the Preferences API is guaranteed to persist some small amount of information, portably, across implementations, then that can be a good start. You can have the defaults buried in your WAR, persist them into preferences, and then have your app pop up a configuration page as soon as it's started to ask for the magic "Where to save LOTS of data" parameters. I think that access to volumes of persistent data will always be a application specific configuration issue. Someone will always have to provide some kind of information (Directory name, JDBC URL, JNDI, whatever). You'll never be able to assume (portably) that you have persistent volume storage available without configuration. Regards, Will Hartung ([EMAIL PROTECTED]) --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
