[dickon]

In-Place Deployment

Let me define what I mean by ‘In-Place Deployment’. When you deploy a project to a JSP container (tomcat, for example), you copy all files under the dev root to the webapps root directory. However, many containers don’t require this. In Tomcat, all you need to do is define a context in the server’s configuration file to explicitly create a context, who’s document root is XXX. This is an example of ‘In-Place Deployment’: you deploy through configuration not through copying. For reference, have a look at the Tomcat-Plugin for Eclipse (http://www.sysdeo.com/eclipse/tomcatPlugin.html). Once you’ve made a Tomcat project, you don’t need to deploy or synchronize: just start tomcat and it’s there.

One advantage of this is not having to deal with synchronization issues.

I mention this as a possible feature for those who are deploying large projects: in my case, 800 JSP, 1200 HTML, 200 properties, 300 becauseJavaScript, 400 images, etc, etc, etc. Over 3000 files, over 35 Mb.

I’m sure Tomcat isn’t the only container for in-place deployment.

What does the rest of the community think: would this be advantagious to them?

JDG

[support-michael]

We are very familiar with this model and have used it prior to MyEclipse.

The issues that I’m aware of with in-place deployment are:

1) There is not a general solution across all of the appservers. The more uniform the various development processes of MyEclipse the easier it is to use across a suite of appservers.

2) Automating the edit of a server’s configuration is adhoc in most cases and very risky. Get it wrong and you’ve not only failed in deploying your project but worse the server is now dorked. Recovering from a corrupted server can be a super pain.

3) Appservers frequently lock directories and files of an exploded deployment. If this happens to your Eclipse project you could be forced in a worse case scenario to have to recyle your server, Eclipse, and in a few cases that I have seen, your machine.

I elaborate on this topic since I have a lot of 1st hand experience using Eclipse on a number of servers. When I worked in Genuitec professional services I frequently assisted clients in setting up the EASIE plugins for in-place deployment. I also assisted clients recover from dorked Tomcat server.xml files when the early versions of the Sysdeo Tomcat plugin used to leave them in an inconsistent or corrupted state. In 99% of all cases the risks do not out weigh the reward for in-place deployment, especially if you take advantage of the fast MyEclipse incremental deployment capability. I realize that the initial deployment takes a little more time and you double your disk space usage. We model the sync-on-demand mechanism directly off of the JDT’s incremental compilation model which exploits the fact that most project changes are very small, affecting only 1 to a few files at any one time.

For users that wish to optimize their deployment using in-place deployment you can by-pass the MyEclipse deployer and configure your appserver to deploy directly from your project output location. Just remember that each appserver has its own peculiarities that you should be aware of before embarking on such a practice.

Michael
MyEclipse Support

[erayl]

Michael,

Your comments are well appreciated, but tjhe risk is only on the part of the IDE and whether it can properly write to the application server’s server.xml. JDeveloper has done in-place deployment to its 9i/AS for several years with ZERO problems. Sysdeo no longer exhibits any deployment problems to Tomcat 4 or 5. Why can’t MyEclipse to this for certain supported servers? In-place deployment it just to convenient to ignore.

[tisc]

We also need in-place-deployment because our application is not an “ordinary” WebApp and simply
cannot be deployed (because we’re writing our own logfiles, need to read configuration etc.).

Bye, Tino.

[Author]

Posts