(Unfortunately, this thread is getting too unwieldly to follow on the forums, a combination of bad formatting and not being able to find recent replies to older messages. Probably not an issue for those on the mailing list (a majority it seems), but I decided to fork the thread anyway -- sorry. Dear Java.net -- get better forums. Don't want to look a gift horse in the mouth, but...)
> Interesting. Both you and Will have a similar
> thought. Can you ( or will) give a more specific use
> cases? Example: GlassFish V3 in the web tier as a web
> server also reverse proxying to GlassFish V3
> instances running business logic? Example2:
> All-in-one web server / app server to simplify
> certain deployments. Are these accurate? Can you
> provide others?
We have the dichotomy of the "classic web server" and the "web app".
Back in the day, you wanted a full featured web server fronting your application mostly for pure performance reasons. There are other reasons, of course, but performance was the primary reason. The web server would serve up the static content while the application server handled the dynamic aspects.
Today, the static aspect is pretty well handled, even by Java servers. They are "fast enough" that we use them now directly rather than burden integrating with a native, dedicated web server for our static content.
I have a love/hate relationship with the WAR and Web App structure. On the one hand, it's a nice, tidy bundle. It's a standalone chunk of functionality that, in theory, is readily deployable as a whole unit. And overall I think it works. There are many WAR files available on the internet that readily drop in to the assorted servers, and mostly work out of the box. Compare this to setting up and configuring many projects from other technologies, and when the WAR works, boy, does it work and work great.
But when it doesn't, there's much teeth gnashing.
The primary benefit of a WAR file is also its curse. I, personally, feel it is "wrong" to have to crack open a WAR file to "get it to work". It just rubs me the wrong way. When you unjar a WAR, tweak and edit XML and property files, and then rejar it, you've essentially removed the benefit of the WAR in the first place -- a stand alone application or piece of functionality. It's like having to relink an EXE on Windows to get it to work for you.
Now, certainly, an application can be written to work around these issues, but it sure seems like a LOT of work and burden for the application developer to have to write, include, and test all of that functionality just to prevent the user from having to crack the WAR and edit a property file.
But, the truth is, there are assumptions you simply can't make in the web tier. A simple example is that you can't assume to have access to ANY persistent, writable storage in a Web App. You can have access to a temporary area, but that's not guaranteed to survive a server restart.
Some applications write an external file to the HOME directory of the user that starts the server, but those applications make quite an assumption that you're even ALLOWED to do that, and if you don't want them to, there's no (guaranteed) place to tell them not to.
There's the Java Preferences API (which isn't cluster aware, of course), or, perhaps, a database (application specific schema, of course), but even with a database, you can't change the DB reference they use without cracking the WAR. So, if you're not happy with their internal alias, there's nothing you can do about it externally.
What's this have to do with the web container?
Well, for example, there's a very nice URL Rewrite filter/servlet on the web. But you'd need to deploy it within the WAR itself, and it's (normally) configured from the WAR itself. URL Rewriting is a tried and true technique to handle web application integration, handle application versioning, etc. If I had a 3rd party WAR I wanted to use, and wanted to use URL Rewriting, I would not only have to open their WAR up, I'd need to add a JAR file to their library, beat on their web.xml, rebundle, and redeploy, hoping I don't break anything.
To me, a role of the container is to aid us in deploying and integrating our applications. There's a lot of call today for mixed implementations of, say, Java and PHP. But now if I want to release that on the same server, I'm pretty much stuck using Apache on the front end talking to GF on the back end, and I don't like doing that.
Why don't I like doing that? Because I left Apache behind a long time ago. Where I once mastered the httpd.conf file, and it's mod_thisnthat, etc., I've forgotten much of it now. It's a legacy format, it's arcane.
And now I would need to remaster that as well as understanding GF administration.
But GF is SO CLOSE to being able to completely usurp Apache for sites that are predominantly Java. I'm not trying to push GF on to folks that simply want to run classic, static HTML sites or some CGI.
But for folks that MOSTLY do Java integrations, it would be nice if we didn't have to deal with Apache at all.
And I'm not asking to change the Servlet spec (even though it needs work), but I think that much of what goes on within web.xml can and should be shadowed out of the WAR (even those within EARs), and made accessible to the administrators with some sense of persistence across deploys. I think GF has the concept of "plans" which I've not looked at, and it may be close to this.
But wouldn't it be nice if I could replace BASIC authentication on a classic CGI application with FORM based authencation, and even better, integrate with GF SSO so that I could have a (almost) seamless experience between a WAR and a PHP program?
By exposing the web.xml to the administrator, I think interesting scenarios like that could be readily accomplished. For example, CGI is currently a simple Servlet anyway, so why can't it be fronted by Container authentication? The CGI won't know the difference, and the CGI servlet can handle the Session details etc.
Will this work for apps that do their own authentication? Not directly, but maybe they can be tweaked to work that way.
Also, I think this process ADDS VALUE to GlassFish, as none of this is breaking the servlet spec, or making apps non-portable. It just makes the container a better value proposition for folks integrating large and larger components. Sure you can take a WAR and plop it in any servlet container, but when you plop it in to GF, its "opened up" and made more usable than in, say, Tomcat.
So, I think, in summary:
* Expose web.xml/sun-web.xml via console of deployed WAR files (servlet and filter parameters, EJB REFs, etc.). Let us persist changes so as to survive WAR/EAR redeployment. Note, the same logic can be said for all of the EAR config files as well.
* Let us add filters, "mod_rewrite", MIME TYPEs ,etc to virtual hosts and/or specific WARs via the console. In simple terms, the virtual host should be able to have it's own "web.xml" that we should be able to play with, with its filters, container security, etc.
* Expose CGI, FastCGI functionality (I know this is on the plate already). I think the CGI part should have some kind of separate process involved, as forking a 1GB heap server can be a real problem. It's an interesting dichotomy that today we have machines with just stacks of GB of RAM, but at the same time, we have a LOT of virtualization (Solaris zones, for example), so may instances of GF are running in RAM constrained systems. Running a 512MB heaped GF in a 1GB zone and you can run in to problems forking that process if it doesn't have enough swap. Forking a small child process, however, is cheap to exec a CGI script.
That's where I'm coming from on this. Embrace the specs we have but expose them in new ways beyond the bare minimums to make administrations and, especially today, integration easier. It would be great to have PHP, RoR, and Java WARs and EARs all within the same management console, splattered across a cluster of servers behind a load balancer with all the power that a good app server and web server can give us.
[Message sent by forum member 'whartung' (whartung)]
http://forums.java.net/jive/thread.jspa?messageID=244147