> From: "Jim Carlson" <[EMAIL PROTECTED]> > Sent: Tuesday, February 04, 2003 12:06 PM > Subject: Re: WAR format question
> Thanks. This answers my question, but I'm still left with the > impression that I'll need to go beyond the WAR format if I want to write > to a log or flat file DB (i.e., non-temp application file). Also, since > containers don't guarantee support for an unpacked WAR (are there any > containers that truly don't support this?), putting conf files that > change after deployment in the WEB-INF seems a little sketchy. At the > minimum, it adds the hassle of extracting and re-archiving the conf file > to every edit. This is an issue with application deployment in general. The one thing that the servlet spec does not promise you is a place where you can permanently store infromation. It gives you a temp directory, but that information is not guarateed to survive a server restart. This means that a self-contained WAR of any reasonable complexity can not be deployed into a Generic Container without direct involvement of a user. In J2EE terms, this user is considered the "Assembler". It appears to me that the overall goal was that through the use of the XML files, a Container Specific tool would be created to facilitate the manipulation of WAR, probably through a GUI. Doesn't the Tomcat Admin console do something like this? Anyway. Beyond that, however, it is pretty clear the that at the application level, you really have little access or control over how the WAR itself is deployed. The only time that all of these constraints would really be practical would perhaps be in the embedded environment. Ideally, one should be able to deploy a WAR to a compatible cell phone. > My impression is that WAR was designed around the best-practices > scenario of having web app instances that don't save local state to the > filesystem, but use a DB or some J2EE storage mechanism, for ease of > clustering. Such apps would probably get their conf from a JNDI resource. > However, I still think that the correct location for log files is > resolved in this scenario. Those of you using WAR along with file logs > -- where do you put them? Since the spec gives you little latitude over how the WAR is deployed, then it should be clear that you can not rely upon how the WAR is deployed in your application, and instead must rely on user specified parameters. So, the simple answer to "wear do my log files go" is "whereever the user tells you to put them". One way is to take advantage of the various means within the WAR file, such as the context parameters or env-entry tags. Of course this requires either an availble utility, or simply having the user unjar, edit, and rejar your WAR file. Another option I would think would be to place a file someplace along the myriad of classpaths that you app can load with getResource, and use that for parameters. Of course, you can't count on that. The biggest problem, however, with both of these techniques is simply that your application can not manage them directly. The application can not write back any changes it might want to. If you application has a plethora of options and configuration parameters, AND you feel pretty certain that you will have access to some persistent medium (local file storage or remote database access), then all you would have the user do is tell you how to get to that persistent storage (pathname on the local system, or the jdbc URL perhaps). Then you can default your properites to the persistent medium, and provide your own interface. If you have no wish to rely on the existence of a peristent storage, then the user will need to make their changes to the WAR directly. However, the key is that once you've got your WAR bundled...that's it. Everything else will need to be routed through the classes in the WAR. You can't create static content and expect the container to implicitly deliver it. So, that mean you only need to know about where the resources that you manage are located, and can care less over where the resources that the container manages (specifically, your WAR). The biggest issue with this is that it makes it just that little bit more harder for novice users to deploy applications. I don't think you could deliver a simple WAR to random end users running against random containers and expect the installation process to go smoothly. It's almost easier to deliver the entire thing (webapp and container) as a stand alone server, then have an installation program ask the questions and do the work. Regards, Will Hartung ([EMAIL PROTECTED]) --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
