Configuration problem: IDEA 5, Tomcat 5 virtual hosts and debugging

Hi,

I'm currently looking at upgrading from IDEA 3.0.5 to 5 and it seems to me that the Tomcat integration in IDEA 5 isn't as tight as it was in IDEA 3. This causes us a few hassles and seems to lose us some functionality - of course, I may well be missing something! I'm using IDEA 5.0.1, Tomcat 5.0.28 and Java 5 update 5.

First some background: with IDEA 3.0.5 we had a run config that would run Tomcat using its server.xml which had two virtual hosts each containing a webapp in their root context. These webapps were both part of one IDEA project and their document roots/bases were in the project directory structure. While they were well-formed enough to be run as webapps by Tomcat (they each had WEB-INF subdirectories etc.) they did not contain all the jars they required because these were kept in a separate lib directory in the project. This was fine though, because we had the 'Include project classpath' tickbox ticked on the runtime configuration which made IDEA supply the project classpath to Tomcat.

The problem is that while IDEA 3 would run the actual tomcat bootstrap class and so could easily supply the project classpath, IDEA 5 seems to have moved away a level and just runs the catalina.bat file, so it can't supply the project classpath to tomcat any more. As I see it, we have three options:

1. Edit tomcat's setclasspath.bat file so that it includes the project classpath. Then it doesn't matter that IDEA can't supply the project classpath directly to tomcat. I don't like this option because firstly I want to keep a standard tomcat installation and secondly when the project classpath changes, setclasspath.bat would need to be changed by hand.

2. Use IDEA 5's feature of building a WAR or exploded web directory. I did try this but couldn't see how to package up individual files - only jars and directories. I want to put individual files in the WAR/exploded directory. In addition, our tomcat server configuration uses virtual hosts and IDEA doesn't seem to support this - you can only specify the context to deploy the webapp to. Also, this adds another step to the build process and the nice thing about our IDEA 3 setup was that the webapp was just ready to run.

3. Integrate Tomcat as an external tool. This is the option I have taken at present. Basically, it mimics the IDEA 3 tomcat integration in that the command line I've specified runs the tomcat bootstrap class using the project JDK and specifies the project classpath by using the $Classpath$ macro. This is the closest to what we want. There are only two downsides to it. Firstly, it's not as nicely integrated - when we want to debug, we have to run tomcat as an external tool and then connect to it using a 'Remote' runtime config session which is not as convenient. Secondly, I haven't been able to debug JSPs using this approach.

So, what I would love is basically what IDEA 3 gave us - a way to run webapps in tomcat virtual hosts straight from our project with no additional packaging required, tightly integrated with IDEA, including debugging. My question is, how can I achieve this? Can I enable JSP debugging somehow with option 3 above? Or am I missing something with option 2 that would let me achieve this (although I still don't like the extra packaging step). Any help would be appreciated.

I had a brief look at the JSR45 integration as it lets you specify package names for JSP's, but it didn't seem like this type of runtime config would buy me any tighter integration with tomcat than the tomcat server integration - which is unsurprising I guess!

I should say that I think IDEA is great and I've been a very happy user for a few years now. I love some of the new features and improvements that 5 has added. The webapp integration is really the only area that I haven't quite managed to configure to my satisfaction.

Sorry about the rather lengthy post - I wanted to be as clear as possible. Even so, let me know if I've left anything unclear or if more information would be useful.

Thanks,

Tim.

8 comments

Norris Shelton posted this in another thread:

By looking at your thread, it looks like you are abusing TC like we were.

Let's take a look at your problems:

  • Running applications as the root ('/') context.

This seems like a good idea at first, but you REALLY need to move beyond that. We did that for years.
We were eventually forced (kicking and screaming) to start running our webapps with their own unique
context. A better solution is to use Apache as your web server and let it handle your oddities.
o You will need to wrap your URLs (images, css, .js, forwards etc) with c:url tags.
It's a pain at first, but you will adapt to it fairly easily.

  • It sounds like your libraries are not in each context's

/WEB-INF/lib directory. We used to have our libraries specified
in the system classpath, then beat TC with an ugly stick to make
it use that for EVERYTHING.
o Having your application conform to the standard layout will
reap tons of benefits. You can't imagine how good JSP editing has become with IJ.

This is not intended to criticize or critic how you have your webapps
configured. We used to do the same thing.


Sorry the forum quoting messed up the layout (and it repeated bits of text but I think I managed to fix all that).

Thanks for your reply. I should assure you that our setup is only like this on our individual development machines! On production machines we have Apache in front of Tomcat and we do indeed build and deploy self-contained WAR files. However, we do have two separate Apache virtual hosts (different domain names/IP's) and two matching Tomcat virtual hosts, one webapp at each virtual host's root context. I don't see anything inherently wrong with having the one webapp for a virtual host running at that virtual host's root context - or am I missing something?

The reason we have used Tomcat virtual hosts in our development setup is to mirror the production environment as closely as possible as far as Tomcat's server.xml goes. Also, due to business requirements, each webapp is aware of its hostname (yeah, I know... but at least the names are dynamic properties set by ant tokens). Therefore, they can't just be run on our dev machines using e.g. localhost:8080/app1 and localhost:8080/app2. Actually, now I've written that, I wonder if they could be. I'll have a think about that.

You are right that on the development machines not all libraries are in the WEB-INF/lib directory. This is because for ease of version control we only have one copy of a jar in a project-level lib dir. However, IDEA 3.0.5 supported this very nicely by having a tickbox for passing the project classpath to Tomcat. We could use IDEA 5's packaging features to build a WAR/exploded dir but as I mentioned it didn't quite do all that I wanted it to. Another alternative would be an ant target that copied jars from the project lib dir to the WEB-INF/lib dirs but this just seems a bit messy and inconvenient and just something else to maintain.

Hopefully this makes my problem a little clearer. If not, let me know!

Any more insights gratefully received!

Tim.

0

Now we are getting somewhere. The libraries can be handled pretty
easily. I would have IJ build an exploded directory for your
development. We also have "standard" libraries. Some are on each
developer's machine (CVS sandbox), while others are on servers that
everyone has access. Access these via IJ libraries (module, project or
global):


The module library is pulled from V:\ which is actually on a Linux
server. Most of the global libraries are on my local machine (CVS
sandbox), while a few are accessed from servers. This allows IJ to
compile your code, which you must be able to do already.

Is that clear for the libraries.

ALSO, DO NOT TRY TO MIGRATE YOUR PROJECT. RECREATE IT FROM SCRATCH. I
cannot say that enough. 3 -> 4 -> 5 project migrations never worked for
me. Save yourself the hassle.


Is there a requirement to be able to run both of the webapps at the same
time? If not, then IJ can very easily handle any webapp being in the
root context. This worked well for us when we had each webapp as the
root context.


Tim Parish wrote:

Norris Shelton posted this in another thread:

>

>> By looking at your thread, it looks like you are abusing TC like we were.
>>
>> Let's take a look at your problems:
>>
>> * Running applications as the root ('/') context.
>> This seems like a good idea at first, but you REALLY need to move beyond that. We did that for years.
>> We were eventually forced (kicking and screaming) to start running our webapps with their own unique
>> context. A better solution is to use Apache as your web server and let it handle your oddities.
>> o You will need to wrap your URLs (images, css, .js, forwards etc) with c:url tags.
>> It's a pain at first, but you will adapt to it fairly easily.
>> * It sounds like your libraries are not in each context's
>> /WEB-INF/lib directory. We used to have our libraries specified
>> in the system classpath, then beat TC with an ugly stick to make
>> it use that for EVERYTHING.
>> o Having your application conform to the standard layout will
>> reap tons of benefits. You can't imagine how good JSP editing has become with IJ.
>>
>> This is not intended to criticize or critic how you have your webapps
>> configured. We used to do the same thing.
>>
>>
>

Sorry the forum quoting messed up the layout (and it repeated bits of text but I think I managed to fix all that).

>

Thanks for your reply. I should assure you that our setup is only like this on our individual development machines! On production machines we have Apache in front of Tomcat and we do indeed build and deploy self-contained WAR files. However, we do have two separate Apache virtual hosts (different domain names/IP's) and two matching Tomcat virtual hosts, one webapp at each virtual host's root context. I don't see anything inherently wrong with having the one webapp for a virtual host running at that virtual host's root context - or am I missing something?

>

The reason we have used Tomcat virtual hosts in our development setup is to mirror the production environment as closely as possible as far as Tomcat's server.xml goes. Also, due to business requirements, each webapp is aware of its hostname (yeah, I know... but at least the names are dynamic properties set by ant tokens). Therefore, they can't just be run on our dev machines using e.g. localhost:8080/app1 and localhost:8080/app2. Actually, now I've written that, I wonder if they could be. I'll have a think about that.

>

You are right that on the development machines not all libraries are in the WEB-INF/lib directory. This is because for ease of version control we only have one copy of a jar in a project-level lib dir. However, IDEA 3.0.5 supported this very nicely by having a tickbox for passing the project classpath to Tomcat. We could use IDEA 5's packaging features to build a WAR/exploded dir but as I mentioned it didn't quite do all that I wanted it to. Another alternative would be an ant target that copied jars from the project lib dir to the WEB-INF/lib dirs but this just seems a bit messy and inconvenient and just something else to maintain.

>

Hopefully this makes my problem a little clearer. If not, let me know!

>

Any more insights gratefully received!

>

Tim.



Attachment(s):
moz-screenshot.jpg
0

Thanks for your reply. Unfortunately, we do need to be able to run both the webapps at the same time while developing, which is one reason why I gave up on the IDEA WAR-creation/exploded-directory-building feature as you can only specify context to deploy to, not virtual host as far as I could see. Mind you, I suppose I could try having IDEA build the exploded dir, but not deploy the modules automatically on Tomcat startup, and have the root contexts in the Tomcat 5.0\conf\Catalina\virtualhost1\ROOT.xml and Tomcat 5.0\conf\Catalina\virtualhost2\ROOT.xml files point at the exploded directories. That might actually do the job.

However, there are three things I don't like about IDEA building the WAR/exploded directory - firstly, it seems a shame to duplicate everything in an exploded directory/WAR when it's all there in the project already (even if it's not all in the 'right' place). Secondly, I worry about performance - I don't want to have to wait around for IDEA to synchronise the exploded directory or build the WAR. I guess the only way of seeing how bad this will be is to try it though! Have you found it slow/fast? Thirdly, the packaging is a bit clunky - I want to specify individual properties files to be dropped in the WAR/exploded directory but as far as I can see IDEA only lets me specify directories or jars.

What would fix everything for me would be for IDEA 5.0 to allow Tomcat to be run in the way that IDEA 3.0.5 did (pleeeease JetBrains)! I guess that's not likely though.

Your comment about not migrating the project is interesting. I did do this and it generally all seems to work fine - although I do intermittently have IDEA claiming that either or both my webapps' web.xml files don't exist when they do and I have been wondering if this was a quirk caused by something about my migrated project. Maybe I'll try recreating the project from scratch.

In any case, thanks for your suggestions - they've been useful and have given me a few more ideas too. I'll let you know how it goes.

Tim.

0

exploded war - I used to run my webapps from my development directory,
but I stopped when we went to CVS. The exploded directory was what I
deployed. Now we are starting to use Ant and I am able to build
directly from CVS.

performance - we have not had any performance difficulties. I think our
largest webapp is mine with about 500 jsp/tag files. The rebuild takes
about 5 seconds. That is probably more constrained by your system.
Mine is a dual 2.8Ghz Xeon. : )

packaging - My project used to have a bunch of property files. Now I
have one. Everything is in the web.xml or I pull it from the database.
It got to be a pain to redeploy/restart the webapp when a property
changed. Now I go to an admin page and reset my caches and it re-reads
the values from the database. Much faster and very clean. Of course, I
had to make the pages that allow the values to be edited.


Here is an idea. You obviously have Tomcat running by itself. Why not
just start tomcat and connect to it remotely for debugging? Is that
what you were talking about using a macro for?

Tim Parish wrote:

Thanks for your reply. Unfortunately, we do need to be able to run both the webapps at the same time while developing, which is one reason why I gave up on the IDEA WAR-creation/exploded-directory-building feature as you can only specify context to deploy to, not virtual host as far as I could see. Mind you, I suppose I could try having IDEA build the exploded dir, but not deploy the modules automatically on Tomcat startup, and have the root contexts in the Tomcat 5.0\conf\Catalina\virtualhost1\ROOT.xml and Tomcat 5.0\conf\Catalina\virtualhost2\ROOT.xml files point at the exploded directories. That might actually do the job.

>

However, there are three things I don't like about IDEA building the WAR/exploded directory - firstly, it seems a shame to duplicate everything in an exploded directory/WAR when it's all there in the project already (even if it's not all in the 'right' place). Secondly, I worry about performance - I don't want to have to wait around for IDEA to synchronise the exploded directory or build the WAR. I guess the only way of seeing how bad this will be is to try it though! Have you found it slow/fast? Thirdly, the packaging is a bit clunky - I want to specify individual properties files to be dropped in the WAR/exploded directory but as far as I can see IDEA only lets me specify directories or jars.

>

What would fix everything for me would be for IDEA 5.0 to allow Tomcat to be run in the way that IDEA 3.0.5 did (pleeeease JetBrains)! I guess that's not likely though.

>

Your comment about not migrating the project is interesting. I did do this and it generally all seems to work fine - although I do intermittently have IDEA claiming that either or both my webapps' web.xml files don't exist when they do and I have been wondering if this was a quirk caused by something about my migrated project. Maybe I'll try recreating the project from scratch.

>

In any case, thanks for your suggestions - they've been useful and have given me a few more ideas too. I'll let you know how it goes.

>

Tim.

>

0

Interested to hear about your findings with performance. Though I have a lowly 3GHz Pentium 4. It can take 10-15 seconds for IDEA to synchronise files and come to life when I switch focus back to it (I know I can turn this off).

Our properties rarely change for a particular environment. What we really use them for is in combination with ant tokens so that we generate a properties file specific for the environment we wish to run our system in (dev. pc/in-house server/live server etc.).

As far as running Tomcat and attaching a debugger to it, that's exactly what we're doing at the moment (point 3 in my original post). The only drawback is I haven't got JSP debugging to work in this setup. But then we don't generally do too much JSP debugging. It's also just not as nicely integrated with IDEA as it would be if I could use the built-in Tomcat integration for debugging. My other thread about the macro was so I could do a make before running Tomcat as an external tool.

Tim.

0

Please turn off that auto resync. It drive me crazy just knowing you
have it. : )

It's been a while since i used Tomcat directly. Maybe some people on
this list can get your Tomcat working. Debugging JSP's is OK, but
debugging code is indispensable.

What version of TC are you using?

Tim Parish wrote:

Interested to hear about your findings with performance. Though I have a lowly 3GHz Pentium 4. It can take 10-15 seconds for IDEA to synchronise files and come to life when I switch focus back to it (I know I can turn this off).

>

Our properties rarely change for a particular environment. What we really use them for is in combination with ant tokens so that we generate a properties file specific for the environment we wish to run our system in (dev. pc/in-house server/live server etc.).

>

As far as running Tomcat and attaching a debugger to it, that's exactly what we're doing at the moment (point 3 in my original post). The only drawback is I haven't got JSP debugging to work in this setup. But then we don't generally do too much JSP debugging. It's also just not as nicely integrated with IDEA as it would be if I could use the built-in Tomcat integration for debugging. My other thread about the macro was so I could do a make before running Tomcat as an external tool.

>

Tim.

>

0

Yeah, I'm seriously considering turning off the resync on frame activation! It seems slower than IDEA 3 - maybe it's doing more behind the scenes.

If you're under the impression that I can't do any debugging of webapps using my "approach number 3" (tomcat as external tool) from the first post in this thread then I should reassure you that it's just JSPs I can't debug. I can debug everything else - servlets, struts actions etc. though I didn't specifically say this in the first post, just said I couldn't debug JSPs. So my current solution is a workable solution - it's just the debugging of JSP's and the rougher integration with IDEA (using my approach I have to run tomcat as external tool, then run remote debug, instead of just running a tomcat runtime config in debug mode if the builtin tomcat integration did what I wanted) that is a hassle. Hopefully I've made that clearer this time. Let me know if not!

Thanks,

Tim.

0

This might not be a problem with virtual hosts, but I have seen a problem with multiple webapps running in the ROOT context on the same host (different ports): browsers mixing up session cookies. Some browsers don't include the port when distinguishing cookies. The same host name was used to avoid the need for multiple SSL certificates. The best solution was to use named contexts instead of ROOT.

Cheers,
11011011

0

Please sign in to leave a comment.