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
http://wiki.
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
-Origi
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 ru
> -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
> -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 t
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
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
Assuming you are using the Eclipse Web Tools Platform, or Java EE package
version of Eclipse for you Tomcat support, see this FAQ entry:
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_p
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 th
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:
http://wiki.eclipse.org/WTP_Tomcat_FAQ#Why_are_classes
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 because
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 from
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 easi
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
"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
> -
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 mi
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-
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 "[servleta
Take a look at the jasper-howto.html in the tomcat-docs webapp
(the "JSPs" link in the tomcat-docs home page). It describes how
to "turn off" the Eclipse JDT compiler, which is old enough in
Tomcat 5.5.9 that it doesn't include Java 5.0 support. You could
also try a newer version of Tomcat 5.5.x an
d
> succeed for "getClassLoader" but fail for SocketPermission? I
> did not find anything for that in Tomcat's policies files.
>
> Thanks again for your help!
>
> Hugues
>
>
> Larry Isaacs <[EMAIL PROTECTED]> wrote: It is likely that
> so
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 pr
Hi Dave,
I believe one of the primary reasons that the
conf/catalina.properties file exists is so things like this are
configurable. If:
shared.loader=${catalina.base}/shared/classes,${catalina.base}/shared/lib/*.jar
doesn't do what you want, change it to:
shared.loader=${catalina.home}/shared
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 (
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. Othe
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 Var
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 som
Remove bootstrap.jar, tools.jar, and commons-logging-api.jar from
the Bootstrap Entries and just add bootstrap.jar to the User Entries.
That should get it working.
I'm not sure about the impact of adding your project to the User
Entries as I think this is equivalent to adding your project to
the C
nal Message-
> From: Larry Isaacs [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, May 31, 2006 2:33 PM
> To: Tomcat Users List; [EMAIL PROTECTED]
> Subject: RE: JSP Compilation Errors - Tomcat 5.5.17
>
> This implies you are picking up older Servlet 2.2/JSP 1.1 API
> classes some
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 come
Assuming you are using a version of Tomcat 5, you will have to
modify something on the 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 .
The defa
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
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 Tom
the UIs are
> working very well. In fact I am able to change the password
> (that is when these exceptions are thrown) and is updated as
> well. Then why this backend exception. Any thoughts here?
>
> Also, there is a forward that is called before the
> "include"
Sid,
The code where the exception is occurring is:
private final String getAbsolutePathRelativeToContext(String
relativeUrlPath) {
String path = relativeUrlPath;
if (!path.startsWith("/")) {
String uri = (String)
request.getAttribute("javax.servlet.include.servl
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 th
: Graham Leggett [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, November 16, 2005 8:42 AM
> To: Tomcat Users List
> Subject: Re: Tomcat 5.5 and Logging - any plain english
> instructions anywhere?
>
> Larry Isaacs wrote:
>
> > You mention Eclipse. Are you using a version of W
Graham,
You mention Eclipse. Are you using a version of WebTools?
Assuming you are, be aware that the launch configuration
created for Tomcat v5.5.x is missing the JVM argument:
-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
that you would normally get from Tomcat 5.5's start
37 matches
Mail list logo