Dynamic JSP Creation and Execution

[Ricky Veach]

Is it possible to create/modify JSPs dynamically (like inside the java code) without redoing the EAR/WAR each time?

Basically in PHP, you can create new PHP files that can be executed on the fly (from being uploaded or created in another php script) without having to pack it up and submit it to the server by hand. They have file managers on the server that allow you to create new php pages right there.

Is it possible to do this similarly in JSP? If not, then why was JSP manufactured in this way?
Ifs because of the way the webservers are made that host the data, are there any webservers that break away from this model and can host dynamic JSP files directly from the file system like PHP does?

Thanks for the information.

[Bear Bibeault]

I guess, though it seems like an odd thing to do. If the code creates or changes a JSP page, it will be translated and compiled on its first access.

Good luck when it comes to updating and re-deloyment, though. I'd reconsider the approach. Having a self-modifying web app is going to be a world of hurt.

This all assumes that the war is expanded. If run from an non-expanded war, there's no file system, so no file writing.

[Paul Clapham]

Back in the old days we used to modify JSP code and copy the new version directly over to the production system, where it would take effect immediately (or anyway the next time somebody used it). Nowadays, though, a lot of companies would consider that rather a cowboy approach to system upgrading. And when you start running your code on a cluster of servers it gets even harder to do that correctly. But I would bet there are still companies out there who are doing "ninja installs" of JSP code like that.

But having other code generate a JSP? Nope, I haven't heard of that either.

[J. Kevin Robbins]

Paul Clapham wrote:But I would bet there are still companies out there who are doing "ninja installs" of JSP code like that.

We're a Fortune 500 company and this is business as usual. In fact, the fastest way to break our web application would be to redeploy the entire war file.

[Ricky Veach]

Bear Bibeault wrote:I guess, though it seems like an odd thing to do. Good luck when it comes to updating and re-deloyment, though. Having a self-modifying web app is going to be a world of hurt.
This all assumes that the war is expanded. If run from an non-expanded war, there's no file system, so no file writing.

I don't consider it odd since this is how PHP has worked for a while, since I can remember. And according to w3techs.com, PHP is still the preferred method online but Java is used for more high traffic sites.
Why would it be a world of hurt? Most website hosting companies that give you free web space basically implement this model and it has worked fine for them.
Obviously to go with this approach you'd probably have to abandon the WAR/EAR method and have single files on the server's filesystem directly, but theres no reason the WAR can't expand since it is just a fancy ZIP file.

Paul Clapham wrote:But I would bet there are still companies out there who are doing "ninja installs" of JSP code like that.

You could also say the way we install WARs is bloated and non-cloud friendly. To update one JSP page, you need the JRE (40 megs) and Eclipse (250 megs), and jboss for testing (140 megs), just to create a fancy zip file and upload it. You couldn't do this on a public PC away from home. Obviously this method wasn't made for non-professionals in mind, but it does seem slightly silly you need almost a copy of the server environment just to update it.
While with PHP, all you need is a file manager installed on the server (lets say ~100 kb at most) and you can manage your server and its code from anywhere.

---

But thanks for the information. I guess this style of server just doesn't exist.

[Bear Bibeault]

How could you possibly have proper testing and version control by administering files willy-nilly on the server? The mere thought makes my skin crawl. But, hey, whatever floats your boat.

Ricky Veach wrote:I guess this style of server just doesn't exist.

You don't listen very well. I've already pointed out that you can create and modify JSPs up the wazoo if you want.

[James Boswell]

Ricky Veach wrote:To update one JSP page, you need the JRE (40 megs) and Eclipse (250 megs), and jboss for testing (140 megs), just to create a fancy zip file and upload it

But in reality, you are never just updating a single JSP.

Ricky Veach wrote:but it does seem slightly silly you need almost a copy of the server environment just to update it

Normally, an update is a vast number of changes which needs to be tested in the same environment as production so a copy of the server environment is essential.

[Ricky Veach]

Bear Bibeault wrote:How could you possibly have proper testing and version control by administering files willy-nilly on the server?

I was just talking bare bones. You could still have proper testing by having two separate development and a production versions and use some repository control by SSHing to the server to be more cloud friendly.

James Boswell wrote:But in reality, you are never just updating a single JSP.
Normally, an update is a vast number of changes which needs to be tested in the same environment as production so a copy of the server environment is essential.

I would say "usually" and not "never" really in your first sentence, but I was just using JSP as the hardest example. If I can create JSP on the fly, then I could also create new images, css, js, etc. I am leaving updating pure Java code out of the discussion for now.
Like I said above, testing could be done server side by having a seperate area for development and not needed on every local machine that you would develop from.

I'm not saying this model is better than the current Java model, each has its ups and downs. I was mainly just looking how to do something similar to PHP with JSPs and such.

Bear Bibeault wrote:You don't listen very well. I've already pointed out that you can create and modify JSPs up the wazoo if you want.

You never specifically said in your post it was possible, that I saw. I assume you are talking about the line "This all assumes that the war is expanded"? I didn't take that to mean it was possible at first glance.
How do you go about doing this? If you need an example server, than how about JBoss 5. Just create a folder in the deploy directory and put the unpacked war into there? Then just the file location in the JSPs to write new files there?

[Paul Clapham]

Ricky Veach wrote:Like I said above, testing could be done server side by having a seperate area for development and not needed on every local machine that you would develop from.

Well, yeah. That's true, and that's in fact how a lot of Java programming and testing is done. It's helpful to have a test environment on your local machine, but it certainly isn't necessary and in many organizations there are machines which are devoted to testing. And when you have a system which is being developed by more than one person, it's almost essential to have a centralized test environment where the configuration is controlled to match the production environment. There's so much configuration required to set up a JEE server that it's very easy to miss something in setting up your local test environment. I fondly remember (NOT) those sessions with my former co-workers where we tried to go through all of the configuration options to see why the application was working differently on their machine versus mine.