OK glad you've got that off yr chest ;) I can sort of see yr point, but these are not issues that have troubled me personally. I tend to look at TC from the point of view of "I'm just pleased that someone else wrote TC for me for free and it works v well at what it is designed for". Every product has limitations, and can't cover every feature that we would all like, and I find it amazing that TC has so few limitations given that it is produced on the backs of volunteer contributions. I'd rather have one TC that 2 IIS's ;)
If you're serious about pursuing a solution for this, Maybe there's an alternative, how about this. (It's not pretty but saves some of the reinvention that you describe). Let's say it's an acceptable limitatio to create all your new JSPs to a separate webapp folder. This webapp only has a single servlet initially, which is a type of "Invoker" that you write yourself, eg /dynamicWebApp/JspInvoker, which could be mapped to serve all request URIs of the form /dynamicWebApp/*.jsp Now, when /dynamicWebApp/dnynamicFile.jsp is invoked, the JspInvoker looks to see if a JSP called dynamicFile.jsp exists under that special folder. If it does, then your code translates/compiles/instantiates it (if not done already) and the request is forwarded to it's doPost method. I'm not saying this is easy, but it could be done. You'd be reinventing the classloading and service methods rather than all the other stuff. You might be forced to use SingleSignOn depending on your app, which could be a negative. Perhaps my answer is worse than yours ;) If its any consolation, one of the annoyances I have encountered in the last few months is that I have a particular webapp feature that I can't code well because Java does not provide multiple inheritance. I've done it, but the code is ugly. I've tried 99 ways of doing it different but don't have a better one. However, I realise that full multiple inheritance was deliberately excluded from Java for specific reasons, so I have to decide whether to stop using Java or accept it as good at what it is designed for. And that's an easy choice to make :) > -----Original Message----- > From: Will Hartung [mailto:[EMAIL PROTECTED] > Sent: Friday 27 May 2005 20:38 > To: Tomcat Users List > Subject: Re: Adding content/JSPs on the fly > > > > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
