Jboss and jsp deployment - best practices?

System

Hi DevNetters -
We're migrating some apps from ATG to Jboss.

With ATG, we've been using .jhtml files, the ancestors to (and pretty much equivalent to) .jsp files. With Jboss, we're moving to .jsps and getting rid of the old .jhtml work.

Here's the issue:
Jhtml (and now jsp) files can contain both code (java) and content (html). With ATG, we were able to easily update the content part of jhtml pages and deploy the individual files to the app server, which would detect them pretty quickly and display the results. And because the .jhtml files are changed way more frequently for the content changes, they've been considered content more than code.

Now that we're migrating to .jsp, I'm getting a lot of pressure to no longer deploy individual .jsp files to the Jboss app servers, even when a simple static content change is made to the file. They (the Source Control folks in particular) want to get all the .jsp files into the source control system and make them a part of a .war / .ear file update to the Jboss server. This seems like a big step backwards to me in terms of the granularity of the updates we can make to our applications - and I'm pretty sure it'll really slow down the time necessary to make simple updates to the application.

And here are the questions:
- Is it possible to deploy individual .jsp files (with only 'creative' changes made to them - not code) into a Jboss enviroment without .war/.ear-ing
them up? Assume we can assure the 'code' portions of the .jsp files are not changed.
- Are there best practices / standards that I should be aware of when files are comprised of BOTH code and content?

Any thoughts are really appreciated.

Wally Box
Nike, Inc.

Bjorn

Wally -

You probably would have preferred some comments a month ago, huh?

Anyhoo, if you have a war that is already deployed, you can indeed deploy individual JSPs into that space and they will (should?) work. The risks associated with it are implementation/application specific. For example, how does the jboss instance handle something like a bounce of the jvm? If it redeploys the webapp from the war when the jvm is bounced, then you could run into versioning problems because at any point in time the JSP in the war may be different than one you've put on the app server. The same thing applies from a source code mgt perspective -- like if you deploy the JSP out, but forget to check it into the source code mgt where it will be added to the war or whatever. Next time you deploy the war, problems.

I think your question about best practices for (in a JSP-sense) scriptlets vs. content is a good one, but a lot of the best answers would be implementation specific. Also, some of it depends on how tightly the content and the code are coupled.

For instance, from what I understand of your situation, if the code parts of your JSPs rarely change, perhaps it makes more sense to keep your content in a database. The JSP pulls the content from the database and you can still make updates to that content without impacting the "programmatic architecture" of the application for which changes usually require stuff like regression testing.

If you need to use files, you're always going to run into your war problem, unless you pull the content part from the JSPs altogether and keep them as fragments/resources that your JSPs reference, but are not part of the war file. Then you'd be doing source code mgt for the war, as well as those fragments.

Also, how can you be sure there will be no changes to the JSP code accidental or otherwise? Just a thought. Pulling the content from the JSP in either of the above ways safeguards against this.

Sorry I couldn't help more. Take care.