[Milind Rao]

I couldn’t launch Tomcat from Eclipse. I used the -vm option on Eclipse to use the Sun JDK 1.4.2 instead of the IBM JDK 1.3.1. And that fixed the problem.

I’d rather use the IBM JDK, since it’s faster. Is there any way to fix this so that when launching Tomcat, the specified JDK is used instead of the JDK with which Eclipse is launched?

Also, I would like to use variables to set the classpath in the Tomcat configuration e.g. %TOMCAT_HOME%\common\lib\servlet.jar. Also, I’d like this to be persistent in CVS so that other people on the team can share the settings without having to do it from scratch on every machine.

[Scott Anderson]

Is there any way to fix this so that when launching Tomcat, the specified JDK is used instead of the JDK with which Eclipse is launched?

Navigate to Window > Preferences > MyEclipse > AppServer > Tomcat > JDK and specify whichever JDK you like. However, I’d still use JDK 1.4.2 so I could use HotSwap debugging, which won’t work with the IBM JDK. Speed of the JVM is secondary, to me at least, during development. I’d much rather be able to edit code on the fly without restarting my application server. In either case, the preference page will allow you to specify the one you’d like.

Also, I would like to use variables to set the classpath in the Tomcat configuration e.g. %TOMCAT_HOME%\common\lib\servlet.jar.

servlet.jar and all the rest of the items needed to run Tomcat are already on its launch classpath. You should really only be adding external, additional items unique to your Tomcat configuration. You most likely don’t need to add anything.

Also, I’d like this to be persistent in CVS so that other people on the team can share the settings without having to do it from scratch on every machine.

You can use the ‘Export…’ button on the preference pages to save your settings externally and then check them into CVS.

–Scott
MyEclipse Support

[Milind Rao]

The JDK for Tomcat was already set to JDK 1.4.2. The JDK for running Eclipse was IBM JDK 1.3.1.

With this setup, Tomcat doesn’t start and I get the
java.lang.AbstractMethodError: com/genuitec/eclipse/easie/tomcat/C.ā
exception in the eclipse log. To get it working, I had to use the -vm option (using JDK 1.4.2) to start eclipse.

In other words, it works only if both the Tomcat JDK and the JDK while running Eclipse are 1.4.2. I was wondering if I could use IBM’s JDK to start Eclipse and have Eclipse use the specified JDK (1.4.2) for starting Tomcat.

>> Also, I would like to use variables to set the classpath in the Tomcat
>> configuration e.g. %TOMCAT_HOME%\common\lib\servlet.jar.

servlet.jar and all the rest of the items needed to run Tomcat are already on its launch classpath. You should really only be adding external, additional items unique to your Tomcat configuration. You most likely don’t need to add anything.

And so it is. But I also need some jars (like DB2) and other projects in the classpath. Those paths have to be hardcoded. Which means that my colleagues have to change them in their environment. Eclipse does a nice job with the projects and libraries pages in the “Java Build Path” notebook of a project’s properties. I’d like to see something similar for setting up app servers.

Export… is a workaround. Again, it would be nice if it were integrated in some “.appserver” file or something like that so that these would be automatically picked up by every one in the team. I haven’t thought this through since app server settings are for all web projects and conf files are currently on a project basis, but you get my intent.

Regards
Milind

[Scott Anderson]

Milind,

With this setup, Tomcat doesn’t start and I get the
java.lang.AbstractMethodError: com/genuitec/eclipse/easie/tomcat/C.ā
exception in the eclipse log.

This is a known bug in IBM’s JDK implementation. Unfortunately the only workaround is not to use it.

But I also need some jars (like DB2) and other projects in the classpath. Those paths have to be hardcoded. Which means that my colleagues have to change them in their environment.

Good point. Support for variable-based classpath entries would be a nice enhancement.

Export… is a workaround. Again, it would be nice if it were integrated in some “.appserver” file or something like that so that these would be automatically picked up by every one in the team.

While I see what you’re getting at, it’s no more a workaround for our server configurations than it is for all the other preference settings on the platform. Basically since these are configured as preferences we’re using the standard preference store mechanisms to manipulate them. You basically have the same problem with your code generation settings, your team settings, and everything else too. I believe this is actually why Eclipse allows the settings to be exported and imported now. However, I do agree that a more elegant solution would be better.

–Scott
MyEclipse Support

[Author]

Posts