[Andrew Freeman]

I currently use Tomcat as the application server for all of my web projects. I like it because it is easy to hack the server.xml file to configure my application’s context, but doing such introduces configuration management problems because the changes are occurring outside of the project folder. This problem compounds itself when I deploy to multiple servers since they don’t usually have the same exact configuration. It would be nice, but is probably asking a lot, to be able to have a tool within ME that does all of this for me.

Anyway, since a tool is probably not going to be a short term option, what can I do with MyEclipse today to better manage this problem? I have considered writing an Ant task that copies a tomcat-context.xml out to the server. If I do this, though, what is ME’s deployment button offering me that I can’t do with Ant? Is there a way to associate an Ant task with the deployment button? If there was, I could set up the deploy button to deploy the correct context for the server.

The problem I have with the Ant task is that it becomes one more artifact to maintain from project to project. I guess the Maven-heads will provide me a solution for that one. 🙂

I hope someone can offer me some ideas as to how to better manage these problems.

Thanks,
Andy

[Riyad Kalla]

Andy,

A few quick things:
1) The ant-task-relating-to-ME-functionality is an addition that the ME team is looking at. Someone asked about this last week and some other people said they wanted it too. So its on its way, but not here now.

2) I’m a little confused by the functionality you are asking for… if you have developed a webapp, in my experience the context that you configure for that webapp should (needs to?) be the same on every container you deploy that webapp to. For example, the user permissions, JNDI data sources, etc. will all be the same. Why do you have differeing contexts from container to container? Maybe standardizing on one context would be the best idea? Or are you deploying for testing reasons to multiple containers? There is no need to keep setting these contexts up over and over. You can set them up once and be done with it. BUT, in the case where you have a webapp in a WAR file, and you want to package it in such a way that you can drop it into a container and have it run, even if it requires a JNDI data source and other context options that are usually part of the server.xml (Tomcat 4) or the /conf/Catalina/localhost/webapp.xml file: I believe I’ve read a way to actually include the webapp’s context configuration IN the WEB-INF dir, such that when its exploded by the container, its context settings are imported into the container. The old way I read to do this in Tomcat 4 was to create an xml file with exactly the same name as the war file, and put just the <context></context> entry in it. I never got this to work on Tomcat 4, but maybe you can read up on Tomcat 5 how to do it? I don’t know how this works with other containers.

BUT my point is you could have multiple context files:
tomcat4-webapp.xml
tomcat5-webapp.xml
resin2-webapp.xml
jboss3-webapp.xml

and in your ant script you could create a /dist directory that all files from the webapp get copied into, you rename the appropriate .xml file to the webapp’s name, then create a WAR file out of that /dist directory, and deploy THAT war file to the appropriate container (based on your target).

This sounds like a whole lot of work, so maybe just setup your contexts in the containers, and forget about it? 🙂

[Andrew Freeman]

rkalla,

Thanks for the update on the “ant-task-relating-to-ME-functionality”. I had missed that one.

As to your second point, I currently deploy my applications to a DEV, TEST, and PROD environment. Each of these environments has a different database, mail server, etc.. This being the case, I do indeeed have different JNDI settings for each environment. My applications also have different logging requirements when I am in development mode versus production mode. With that said, I have to have seperate content settings for each environment. Do you truly have only one database for all of the environments that you deploy your applications? Yek.

As for using an Ant task to deploy the application’s context, as I said in my initial posting, I have considering doing that. The problem with that solution is, as you said, it requires a lot of work. I was hoping to hear a simpler solution. Figures. 😉

Thanks,
Andy

[Andrew Freeman]

BTW, the AppFuse (http://raibledesigns.com/wiki/Wiki.jsp?page=AppFuse) project’s build.xml has a “setup-tomcat” target that demonstrates what needs to be done to copy the application’s context file out to a 4/5 server.

Andy

[Riyad Kalla]

Woops, yes Andy you are correct I can see why you need different context. I don’t know why that didn’t occur to me….

Anyway, back to my original question… why not just setup the contexts on all 3 machines permanently via the administrator and just leave them there? Why do you need to keep deploying the context configurations?

And yes, at this point I have no idea how to make this easier, I’m just curious why you are doing it.

[Andrew Freeman]

The problem of leaving the context on the app server is that I need to occasionally rebuild my servers. 😉 Rebuilding the context each time is really not an attractive option when a lot of things are mapped in JNDI. Sure I can copy and paste configurations each time, but that doesn’t help me if my server crashes. There has also been many occasions where I have multiple integration builds running at the same time.

Last night I was using the copy/paste approach on my server and I accidently pasted the context twice. Such a stupid thing cost me quite a bit of time.

The bottom line is that I need a simple way to manage this and ME is currently not making it simple.

[Riyad Kalla]

Ok, yes I can see why you want to automate this process. Maybe if you outline clearly what you want, and post it in the feature forum Scott/Michael can evaluate it?

[Scott Anderson]

Here’s a thought. You could install multiple versions of Tomcat, for example, one configured like development and one configured like production. Then, to retarget just change the install directory listed on the server preference page and redeploy. A little odd, but probably better than playing around with file edits alot.

–Scott
MyEclipse Support

[Andrew Freeman]

@scott wrote:

Here’s a thought. You could install multiple versions of Tomcat, for example, one configured like development and one configured like production. Then, to retarget just change the install directory listed on the server preference page and redeploy. A little odd, but probably better than playing around with file edits alot.

Interesting solution Scott. I will give that and the Ant approach a try.

Thanks,
Andy

[dmiller]

I am having the same problem.

Background info:
For deploying to Tomcat5, the context.xml file can be placed in the META-INF directory. When the war file is deployed to Tomcat, the context.xml file is automatically copied into the server’s conf/Catalina/localhost directory and renamed to the name of the context root. This is the recommended way to customize the context for a given web app in Tomcat 5 (as opposed to editing the server.xml file directly).

This is what I would like ME to do:
On deploy to Tomcat5:
When there is a context.xml file in the META-INF directory (in the web root of the project), copy that file into the ${tomcat.home}/conf/Catalina/localhost directory.

On undeploy:
Delete the context file from ${tomcat.home}/conf/Catalina/localhost

I think that would do the trick. I can see one caveat here though: multiple deployments will need separate conext.xml files. It would be nice there would be a way to associate a different context.xml file with each deployment configuration (it could be specified on the New Deployment dialog when creating a deployment). Maybe the META-INF/context.xml should just be the default location to look if none is specified in the New Deployment dialog.

[Riyad Kalla]

miller,
Unfortunately this behavior is not only very specific to Tomcat 5, but very specific Tomcat 5 behavior… it is not likely (honestly) that we would add functionality in ME to support this. If we broached this topic it opens us up to 100s of enhancement requests for every app server we support.

I think your best bet is to use a Ant script to do this.

[dres1011]

@support-rkalla wrote:

miller,
Unfortunately this behavior is not only very specific to Tomcat 5, but very specific Tomcat 5 behavior… it is not likely (honestly) that we would add functionality in ME to support this. If we broached this topic it opens us up to 100s of enhancement requests for every app server we support.

I think your best bet is to use a Ant script to do this.

I can’t get it to work yet but the tomcat 5 docs state that instead of placing the context config in${tomcat.home}/conf/Catalina/localhost you can “put them in the META-INF/context.xml directory of your WAR file”. If this is true ME, does not have to do anything except deploy as a WAR. Caveat, I have not gotten this to work.

As for different context.xml values, generic ant support in ME deployments would enable token replaces of depolyment dependent values.

[Author]

Posts