> From: "Steve Kirk" <[EMAIL PROTECTED]> > Sent: Friday, May 27, 2005 11:44 AM
> It sounds reasonable, but probably isn't tested or "by design", so probably > best to just have a go. Re portability, the best advice I can offer is an > old chestnut: read the servlet spec. This is particularly relevant in this > case. The spec is generally pretty good at telling you you pretty > accurately if (a) what you want to do should/must be supported or (b) what > you want do do is forbidden. Of course there are some areas that it does > not have a view either way on, but I find it to be an invaluable document - > I have it on shortcut from my taskbar and consult it often. It's at least > as useful as the javadocs or TC docs. > > For those of you that don't know where to find it, it's here, under > "specifications". > http://java.sun.com/products/servlet/reference/api/index.html > > Choose the servlet spec version appropriate to your TC version as described > in the table on the tomcat home page: > http://jakarta.apache.org/tomcat/index.html I'm reasonably familiar with the specification. One of the notable bits about it is simply the fact that within the spec, you're pretty much not guaranteed writeable access to the file system at all (save for a temporary area, and it's simply that -- temporary). But the reality is that most engines give you access to the disk that way. > Just one more specific point on your note Will - I would have thought if > anything that you want it to be a precondition that the webapp NOT be > deployed as a war. I've a feeling that if TC explodes the war, then it > might not check the exploded FS for changes. Don't take this as gospel > though, this is a hazy half-remembered bit of info. As far as I know, the Servlet spec doesn't have a deployment method outside of a WAR. It's pretty much a container behavior to actually explode the WAR on to the file system, yet, most obviously do for performance reasons. But it does bring up a basic problem, for example, if by some fluke the app is redeployed, all of that new data is blasted away by the WAR..that would be Bad. But I can't see another (easy) way to create JSPs on the fly, or in fact to create any other content that can be served directly the server. It's an annoying nit of the spec, to me, that it doesn't expose this behavior to the developer. For example, unlike EJBs (which has a specified limitation on accessing the disk), the Servlet spec does allow you to access the disk, though perhaps not within the WAR hierarchy. But, there is no way to, say, "forward" to a static resource that the server can then handle in its own "internally optimal" way. Rather, I have to open the static resource, determine the content type (I can get that from the Servlet spec), and then feed it into the output stream, when in fact it would simply be easier to do "req.serveStatic("/tmp/mynewgraphic.gif")" or some such thing, or be able to forward outside of the web app (i.e. to a actual file rather than a URL). Simply, the application structure and such are pretty much isolated from the developer. I can't add anything dynamically to the security domain, for example, which means if I want that kind of capability in my application, I have to essentially implement ALL of the container security -- mapping, role checks, etc. Container security is an all or nothing. Be happy with its limited funcitonality or dump it entirely. So, now if I want dynamic templating in my Webapp, I, technically, have to dump JSP completely and switch to something like Velocity. All of the power of JSP, tag libraries, etc. is gone. I imagine that I could mimic the JSP environment, compile the JSP myself, compile the java myself, load the class myself and feed the output into the standard output stream, but that seems like a silly wheel to reinvent when I have a full container here that DOES THAT ALREADY, doncha think? Mind, I may still just Do It, open up paths to the disk and plonk files and JSPs in place and see what happens, but it's a flaming hoop I wish I didn't have to jump through. Regards, Will Hartung ([EMAIL PROTECTED]) --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
