On Tue, 20 Jul 2004 15:35:51 -0700, Jim Barrows <[EMAIL PROTECTED]> wrote:
> We have PDF's that can be created by one webapp, but must also be served by other > webapps. Forgive me for coming in late, but it's not obvious to me how big a problem the "other webapps" part of this really is. Lets use the term "consumer webapp" to be the webapp that wants to return the PDF in response to a request, while the "producer webapp" is the one that generates it on demand. (Note that, in a properly designed environment, no consumer should ever be able to tell whether the PDF was actually generated on the fly, read from a BLOB, or read from a file -- all the consumer knows is a URL, and it is up to the producer to decide what to do.) The first rule is that the consuming webapp has to know the name of the PDF that it wants. You could look this up in a database, if you wanted it to be dynamic -- but it will typically be a simple relative URL like "bar.pdf", right? Next, lets assume the consuming and producing webapps are on the same server, but distinct from each other. If the producing webapp has a context path of "/foo", then the relative URL for this pdf becomes "/foo/bar.pdf" instead of "bar.pdf" -- again, the host is implicit, so this URL should work in development, test, and production environments with no changes as long as producer and consumer are guaranteed to be on the same machine. The most general case is where producer and consumer webapps might be on different servers. An easy way to generalize this would be to configure the "root" part of the path (http://myhost/foo) in a context init parameter (or a JNDI environment variable), and make the consumer webapp glue that together with the relative path of the pdf in question on demand. Then, at most, you have to change one configuration setting as you migrate from development to test to production -- and, if you use a JNDI environment variable, the change is totally external to the WAR file that you're deploying, because you can configure it using the server's admin tool. Is it really any harder than this? If it is, I must be missing something. Craig --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
