This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 48662 - Tomcat does not stop after a faulty debug start
Summary: Tomcat does not stop after a faulty debug start
Status: CLOSED INVALID
Alias: None
Product: serverplugins
Classification: Unclassified
Component: Tomcat (show other bugs)
Version: 4.x
Hardware: PC Windows ME/2000
: P2 blocker (vote)
Assignee: Sherold Dev
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-09-08 12:41 UTC by navneet
Modified: 2006-03-24 10:09 UTC (History)
0 users

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description navneet 2004-09-08 12:41:05 UTC
Build 200409061800

I have a web project where the servlet raises a
exception during the init of the servlet.

When I try to debug this project, and tomcat
raises an exception during the init of the
servlet, it fails to start with the final exception:

java.lang.reflect.InvocationTargetException 
at
sun.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at
org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:287)
at
org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:425)
Caused by: java.security.AccessControlException:
access denied (java.io.FilePermission C:\Documents
and
Settings\xxx\.netbeans\4.0beta1\jakarta-tomcat-5.0.28_base\webapps
read)
at
java.security.AccessControlContext.checkPermission(AccessControlContext.java:264)
at
java.security.AccessController.checkPermission(AccessController.java:427)
at
java.lang.SecurityManager.checkPermission(SecurityManager.java:532)
at
java.lang.SecurityManager.checkRead(SecurityManager.java:871)
at java.io.File.list(File.java:935)
at
org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:430)
at
org.apache.catalina.startup.HostConfig.start(HostConfig.java:983)
at
org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:349)
at
org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119)
at
org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1091)
at
org.apache.catalina.core.StandardHost.start(StandardHost.java:789)
at
org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1083)
at
org.apache.catalina.core.StandardEngine.start(StandardEngine.java:478)
at
org.apache.catalina.core.StandardService.start(StandardService.java:480)
at
org.apache.catalina.core.StandardServer.start(StandardServer.java:2313)
at
org.apache.catalina.startup.Catalina.start(Catalina.java:556)
... 6 more

After this the tomcat instance does not go
further. It just stops there. The deployment
dialog is waiting with the message: "Waiting for
Tomcat ..."

I tried doing a refresh on the Runtime tab, it
says that the server is in a "stopped" state.

I try "debug project" again and the "Deployment
Progress Monitor" just waits midway in the
progress bar. 

To debug the project, i have to stop netbeans and
start again.
Comment 1 zikmund 2004-09-08 14:52:50 UTC
I've tried your scenario: running WebApp in debugger with servlet
which throws RuntimeException in init method.

From the exception it seems that you have wrong file permissions (see:
access denied (java.io.FilePermission C:\Documents and
Settings\xxx\.netbeans\4.0beta1\jakarta-tomcat-5.0.28_base\webapps read)
Can you look at them, please?

Can you reproduce it with new WebApp project and clean user dir?
Thanks, Karel.
Comment 2 navneet 2004-09-08 19:18:34 UTC
I tried it with a clean .netbeans directory too and it gives me
consistent results as given in the description. 

Will try to duplicate this in a new project or try to identify the
problem with my project.

But my question here is: Should Tomcat lock up ? or should netbeans
lock tomcat due to this exception ?
Comment 3 navneet 2004-09-10 21:25:24 UTC
I tried two things:

1. Try and run the same application under Netbeans 3.6
2. Try and run the same application with Netbeans 3.6 and an External
Tomcat 5.0.28 server sharing the same base directory as the internal
one Netbeans 4.0 dev build.

In the first case, the results were identical. Tomcat locked up and to
debug the application the next time, i had to shut down netbeans.

In the second case, the server terminated fine and i did not need to
shutdown netbeans to debug again.

Am still trying to figure a demo for the case.
Comment 4 Sherold Dev 2004-09-13 12:39:31 UTC
Cannot reproduce this issue -> changing to P2 (when looking at the
stacktrace it is not obvious whether it is really a NB issue).

Can you please provide (attach) your web application or just a sample
with such behaviour? It would be very helpful.

To your question: Tomcat should not lock up due to this exception.

Does this happen only when debugging or also when just running the web
project?

Do you get this exception when you just start Tomcat from the
"Runtime" tab?

Didn't you modify some Tomcat or JDK security policy permissions?
Comment 5 navneet 2004-09-13 13:44:57 UTC
I did not change any setting anywhere when i got these error messages. 

I am trying to set up my web application to use log4j and to make it
log to a logs directory under my WEB-INF. I tried using the
log4jproperties to do this, but that did not automatically load the
logging settings. So I tried reading the settings in using the
DOMConfigurator and that is when it failed. And Its been failing since
then.

I then tried editing the catalina.properties file and added the
following statement at the bottom of the file:

grant {
    java.security.AllPermission;
};

And it still does not work.

The exception that I have listed is probably due to the fact that
log4j is trying to open a file ro read the configuration or trying to
write a log into the logs directory.
Comment 6 Sherold Dev 2004-09-13 14:32:04 UTC
I'm sorry but without exact steps how to reproduce it or a test case,
there is not very much we can do about this issue.
Comment 7 navneet 2004-09-14 07:14:33 UTC
Sorry about this. Will open another bug after I have a concrete example.
Comment 8 Jiri Skrivanek 2004-09-14 08:28:13 UTC
Verifying.