Backing up slightly, maybe the first step should be to confirm whether the Web
Tools Platform, Sysdeo, or other plug-in is being used for the Tomcat server
support.
The fact that C:\Program Files\Apache Software Foundation\Tomcat
6.0\conf\tomcat-users.xml is being renamed suggests that if WTP
-Original Message-
From: Steve Cohen [mailto:[EMAIL PROTECTED]
Sent: Monday, September 08, 2008 1:34 PM
To: Tomcat Users List
Subject: stupid tomcat/eclipse question
I've had a stable development environment running Tomcat 6.0 within
Eclipse 3.3.
I did something stupid to
-Original Message-
From: Bai Shen [mailto:[EMAIL PROTECTED]
Sent: Wednesday, September 24, 2008 2:54 PM
To: Tomcat Users List
Subject: Tomcat unable to find jars when deployed from Eclipse
I'm running Eclipse 3.4 with Tomcat 6.0.18 configured as a server.
After a
bit of
Be aware that in Eclipse WTP, your web project is published to the server to
be served. Jars that are added to the project as runtime dependencies will be
copied to the WEB-INF/lib of the published webapp. Just adding a jar to
the build path of the web project DOES NOT add the jar as a runtime
I believe the message:
java.lang.UnsupportedClassVersionError:
com/sun/tools/javac/Main (Unsupported major.minor version 49.0)
indicates that while running with 1.4.2, you are attempting to
use a tools.jar from a JDK 1.5.x. The simplest way I know to
encounter this is to install Tomcat using
Sid,
The code where the exception is occurring is:
private final String getAbsolutePathRelativeToContext(String
relativeUrlPath) {
String path = relativeUrlPath;
if (!path.startsWith(/)) {
String uri = (String)
this backend exception. Any thoughts here?
Also, there is a forward that is called before the
include as you pointed out. Do you have any ideas on what
tweaking I can try?
Thanks again for your reply.
Sid
Larry Isaacs [EMAIL PROTECTED] wrote:
Sid,
The code
For reasons that are difficult to predict or calculate,
some other protection domain (i.e. codeBase) for somebody
in the stack may be missing this permission. I've given
up trying to figure these out after the obvious doesn't
fix it.
Try adding:
-Djava.security.debug=access,failure
to your
Classes downloaded to the client browser for execution is just
static content as far as Tomcat is concerned. Modifying the server's
or webapp's classpath isn't going to make any difference. It's
the client browser's classpath that needs adjusting to use the jar.
This means modifying the HTML
One other thing to be aware of is that if you installed Tomcat 4.1.x
using the exe, and you chose to install Tomcat as a service, then the
install would copy tools.jar from the JDK to Tomcat's common/lib
directory. This allowed the service to run off the JRE associated with
the JDK (much much
Alec,
I'm not aware of any specific causes for this behavior with Eclipse 3.3.x and
WTP 2.0.x. To begin searching for a cause, it would be helpful to know what
happens if you unzip a new Tomcat install, create a runtime and server from
that install in Eclipse, and try starting that server
There is not enough detail about your Eclipse configuration to make much of a
guess. Basically the exception says that the ServletRequestListener class is
not visible to one of the listener classes loaded in your web.xml. Either
because it's missing (which seems not to be the case), or
For some info about the Tomcat support in the Web Tools Platform of Eclipse,
see this FAQ:
http://wiki.eclipse.org/WTP_Tomcat_FAQ
If you happen to have put your mysql driver jar in shared/lib, then this
question might explain the behavior:
If I recall correctly, in JSP spec 1.1, the argument for
handlePageException() was Exception. In JSP spec 1.2 and later, the
argument is Throwable. It would appear you have a servlet.jar from
Servlet 2.2/JSP 1.1 somehow becoming the jar this JSP is running
against, causing the method signature
I've reinstalled the Tomcat server isn't much detail to go on.
See if the following link helps by explaining the Tomcat support in
Eclipse:
http://www.eclipse.org/webtools/faq/TomcatServerFAQ.php
It covers WTP 1.5.x, but the majority of the info applies to WTP 2.0.x
as well.
Cheers,
Larry
I think the Tomcat support in Eclipse WTP is pretty reasonable, but it isn't
perfect. For example, if you name your project ROOT, Eclipse won't tell you
that you are asking for trouble because some web servers, like Tomcat, may give
that particular name special treatment. This would explain
For details about the Tomcat support, see:
http://wiki.eclipse.org/WTP_Tomcat_FAQ
You might also check the Error Log view to see if any complaints are being
logged related to this.
Cheers,
Larry
-Original Message-
From: KANIKA GUPTA [mailto:[EMAIL PROTECTED]
Sent: Saturday, July
I has been quite a while since I have used Tomcat 3.3.x.
My recollection is that accessing the changed servlet would
trigger a reload of the webapp. This differs from the newer
Tomcats which have a background thread checking for changes.
Also, with a default configuration, I don't recall anything
Assuming you are using a version of Tomcat 5, you will have to
modify something on the Connector to fix this, easily.
If you want request.setCharacterEncoding(UTF-8) to affect the
encoding of GET query parameters (not just POST parameters),
then you must set useBodyEncodingForURI=true on the
This implies you are picking up older Servlet 2.2/JSP 1.1
API classes somehow, which is overriding the desired
Servlet 2.4/JSP 2.0 API classes. The API classes are
backward compatible, but not forward compatible as this
case illustrates. I don't know enough about Fedora to
say how this could
Just in case, does your web application display a directory
listing in 5.5.9? If so, be aware that directory listings
have been turned off in conf/web.xml for 5.5.20 (I forget in
which version this occurred) due to the potential of a DOS
attack if your web application contains lots of files.
The URL http://localhost:8080/samena/, in the absence of a
welcome file such as index.jsp, will request a directory
listing. However, in Tomcat 5.5, directory listings are
disabled by default, which will result in the error you see.
I would guess that you either need to enable directory
listings
It is likely that some other class in your webapp is on the
stack when the permission check occurs and it causing the
check to fail. You could try .../WEB-INF/- to expand
the grant to the entire webapp and see what happens.
To diagnose this kind of exception, you can add the following
system
for that in Tomcat's policies files.
Thanks again for your help!
Hugues
Larry Isaacs [EMAIL PROTECTED] wrote: It is likely that
some other class in your webapp is on the stack when the
permission check occurs and it causing the check to fail.
You could try .../WEB-INF/- to expand the grant
This is also explained in the WTP Tomcat FAQ:
http://wiki.eclipse.org/WTP_Tomcat_FAQ
or specifically:
http://wiki.eclipse.org/WTP_Tomcat_FAQ#If_I_start_my_Tomcat_server_and_try_to_display_Tomcat.27s_default_page.2C_why_do_I_see_a_directory_listing_or_404_error_page.3F
Cheers,
Larry
This information applies to the Tomcat support found in the Eclipse Web Tools
Platform, see http://www.eclipse.org/webtools. I believe Ados has stated he is
using the Sysdeo Tomcat plug-in, which is quite different. For those using or
considering the Web Tools Tomcat support, see
Feel free to ask Web Tools questions on the Web Tools newsgroup,
see http://www.eclipse.org/newsgroups/. Other comments below.
Cheers,
Larry
hallo,
thanks for the antworts.
after first Antwort. i have installed the WTP plugin and it
seems good to work with servlets. but i have some
Since you are using Tomcat 5, check out the shared.loader
property specified in the catalina.properties file of your
Tomcat instances. You could change it to use catalina.home
instead of catalina.base, or add an additional path.
Cheers,
Larry
-Original Message-
From: Fran Varin
The presence of /usr/share/tomcat5 in the servlet-api.jar
path suggests you are using a packaged install of Tomcat. While
doing some Eclipse Web Tools testing on SUSE 10.x (I think 10.1),
the servlet-api.jar it was installed as a dependency of the
Tomcat install and was symlinked as
A FAQ I've written has been submitted, but hasn't made it to
the Web Tools web site yet. For the time being, the answer to
your question can be viewed here as Troubleshooting question #5:
https://bugs.eclipse.org/bugs/attachment.cgi?id=67392#trouble_5
Cheers,
Larry
-Original Message-
30 matches
Mail list logo