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.
Using NetBeans 3.4.1 the Monitor module must be installed globally to work properly. If the Monitor module is installed at user level, the Tomcat server will not start properly because the Monitor valve classes are not found.
I just tried to reproduce this with Solaris 8 and JDK 1.4.0 and I don't see the problem. I downloaded 3.4.1 from today's build (12/3) and got the modules from the update center. I did it with a fresh install, that is, I hadn't started the bundled tomcat before I installed the monitor module. Could you explain exactly what you did, and on which platform? Also, please check the following: lillamy$ cd ~/.netbeans lillamy$ find 3.4.1dev -name *monitor* 3.4.1dev/system/Modules/org-netbeans-modules-web-monitor.xml 3.4.1dev/modules/locale/monitor_ja.jar 3.4.1dev/modules/ext/httpmonitor.jar 3.4.1dev/modules/ext/monitor-valve.jar 3.4.1dev/modules/docs/locale/monitor_ja.jar 3.4.1dev/modules/docs/monitor.jar 3.4.1dev/modules/monitor.jar 3.4.1dev/tomcat404/lib/httpmonitor.jar 3.4.1dev/tomcat404/server/lib/monitor-valve.jar Were all these files installed as a result of using the auto-update module? Then switch to the IDE installation directory, and cd into tomcat404 lillamy$ cd tomcat404 lillamy$ find . -name *monitor* ./lib/httpmonitor.jar ./server/lib/monitor-valve.jar If the files were downloaded correctly from autoupdate, but the listing failes for the tomcat404 directory, then the problem is with the Tomcat integration module. Thanks, a
Forgot to change the status.
I couldn't reproduce this on Win2K either.
Verified that it works for me also with the NetBeans 3.4.1 development build from 12/12. HTTP Monitor works fine when installed globally or locally.
Additional information from user: The interesting thing is, that I do see it with every 3.4.1 build here in my office. The same build works fine with the HTTP monitor on my computer at home. And so far it has only happened to me with the 3.4.1 not with 3.4 (as the original poster reported). The only additional modules I have installed are the other webmodules and the and the class navigator. I cannot reproduce it either on a clean (=empty) userdir. Nevertheless, I can reliably reproduce it with my existing 3.4.1 userdir. I shortly suspected the updated JSP module (1.8.2) which is available on the update center, but that wasn't the fact. The only thing I can give you at this point is the exception which is thrown, when the HTTP monitor does not work properly: c:\jdk1.4.1\bin\java -classpath "C:\Programme\NetBeans341 \tomcat404\bin\bootstrap.jar";"c:\jdk1.4.1 \lib\tools.jar";c:\Daten\NetBeans341 \modules\ext\httpmonitor.jar;c:\Daten\NetBeans341 \modules\ext\monitor-valve.jar - Dcatalina.home="C:\Programme\NetBeans341\tomcat404" - Dcatalina.base="c:\Daten\NetBeans341\tomcat404_base" org.apache.catalina.startup.Bootstrap "start" Exception during startup processing 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:324) at org.apache.catalina.startup.Bootstrap.main (Bootstrap.java:243) Caused by: java.lang.NoClassDefFoundError: org/apache/catalina/valves/ValveBase at java.lang.ClassLoader.defineClass0(Native Method) at java.lang.ClassLoader.defineClass (ClassLoader.java:502) at java.security.SecureClassLoader.defineClass (SecureClassLoader.java:123) at java.net.URLClassLoader.defineClass (URLClassLoader.java:250) at java.net.URLClassLoader.access$100 (URLClassLoader.java:54) at java.net.URLClassLoader$1.run (URLClassLoader.java:193) at java.security.AccessController.doPrivileged (Native Method) at java.net.URLClassLoader.findClass (URLClassLoader.java:186) at java.lang.ClassLoader.loadClass (ClassLoader.java:299) at sun.misc.Launcher$AppClassLoader.loadClass (Launcher.java:265) at java.lang.ClassLoader.loadClass (ClassLoader.java:255) at org.apache.catalina.loader.StandardClassLoader.loadClass (StandardClassLoader.java:1076) at org.apache.catalina.loader.StandardClassLoader.loadClass (StandardClassLoader.java:992) at org.apache.catalina.loader.StandardClassLoader.loadClass (StandardClassLoader.java:1076) at org.apache.catalina.loader.StandardClassLoader.loadClass (StandardClassLoader.java:992) at java.lang.ClassLoader.loadClassInternal (ClassLoader.java:315) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:140) at org.apache.catalina.util.xml.ObjectCreate.start (XmlMapper.java:616) at org.apache.catalina.util.xml.XmlMapper.matchStart (XmlMapper.java:412) at org.apache.catalina.util.xml.XmlMapper.startElement (XmlMapper.java:91) at org.xml.sax.helpers.XMLReaderAdapter.startElement (XMLReaderAdapter.java:333) at org.apache.xerces.parsers.SAXParser.startElement (SAXParser.java:1376) at org.apache.xerces.validators.common.XMLValidator.callStartE lement(XMLValidator.java:1284) at org.apache.xerces.framework.XMLDocumentScanner.scanElement (XMLDocumentScanner.java:1806) at org.apache.xerces.framework.XMLDocumentScanner$ContentDispa tcher.dispatch(XMLDocumentScanner.java:1182) at org.apache.xerces.framework.XMLDocumentScanner.parseSome (XMLDocumentScanner.java:381) at org.apache.xerces.framework.XMLParser.parse (XMLParser.java:1098) at org.xml.sax.helpers.XMLReaderAdapter.parse (XMLReaderAdapter.java:223) at javax.xml.parsers.SAXParser.parse (SAXParser.java:314) at javax.xml.parsers.SAXParser.parse (SAXParser.java:253) at org.apache.catalina.util.xml.XmlMapper.readXml (XmlMapper.java:228) at org.apache.catalina.startup.Catalina.start (Catalina.java:725) at org.apache.catalina.startup.Catalina.execute (Catalina.java:681) at org.apache.catalina.startup.Catalina.process (Catalina.java:179) ... 5 more
The problem appears to occur if the user has set a different userdir than .netbeans. At this point, it appears that although the required jar files are available under modules in the user's directory, they are not deployed properly to Tomcat (we know that all the jar files are present in the module that comes through autoupdate). I'm reassigning this bug since that part is the responsibility of the tomcat plugin.
The functionality managing the (Tomcat)plugin/monitor communication need to be improved for Netbeans3.5.
I have now discovered a way to reproduce this bug on Win2K. 1) Start with a fresh 3.4 installation, no auto-update modules installed. 2) Edit IDEROOT/bin/ide.cfg, adding -userdir something as the first argument. 3) Start the IDE. 4) Download the monitor.nbm and install it locally. 5) Mount and execute a web module. 6) Get a fresh 3.4.1 installation. 7) Edit IDEROOT/bin/ide.cfg, adding -userdir something-else as the first argument. 8) Start the IDE. 9) Execute the same web module 10) The IDE croaks because the filter will be declared in tomcat404_base/conf/web.xml but the libraries are not copied into IDEROOT/tomcat404/lib & server lib. I then tried to reproduce this with the IDE build from 02/07. There is a problem with importing settings so there is no Tomcat installation available if one does this. However, I noticed that as a result of this process, I have a Tomcat404 directory created in my user settings parallel with the tomcat404_base directory, and that this contains exactly the libraries required to deploy the monitor, so I suspect this is a bug. Also, the tomcat404_base/conf/web.xml file contains the old style declaration of the monitor (without the new init param with the host name and port of the internal server) which means it got installed in the wrong place - it should have been in the IDEROOT.
Investigated this a bit further. It seems that it's the fact that the monitor is installed in the local directory which causes the update to fail. If I run update from 3.4 -> 3.4.1 without the monitor installed locally it does not fail. I'll attach the execption.
Created attachment 8883 [details] Stacktrace
*** Issue 29554 has been marked as a duplicate of this issue. ***
*** Issue 30920 has been marked as a duplicate of this issue. ***
Ana hit the nail on the head when she found out that the wrong directories are created in userdir when the monitor module is installed (via autoupdate) subsequently in Netbeans3.4 (3.4.1). Unfortunately those directories (userdir/tomcat404/lib, userdir/tomcat404/server/lib) caused the problems when new netbeans version was installed with the old userdir specified (very common case). Specificaly, getHomeInternalDir() method from Tomcat40Installation class returned the userdir/tomcat404 directory as the home directory for the internal Tomcat404 - instead of netbeans_home/tomcat404 directory. That was the cause for exception attached to this issue (the same as in 30920). I consider this bug fixed for Netbeans3.5.
I cannot verify this is fixed with the latest NB 3.5 dev builds because of the problems in the server registry after upgrading from 3.4.1 to 3.5 (issue #30920).
Verified in NetBeans dev build 200302270100.