MC4J und Tomcat 4.1

[andy flury]

in dem neuen Javamagazin gibt es eine Anleitung für das Remote Management des Tomcat via MC4J.

Hat dies jemand ausprobiert, ich bekomme von MC4J nur ClassCastExceptions! In den Mailinglists von Apache.org und mc4j.sourceforge.net war leider auch nichts zu finden.

[Marcus Spiegel]

Hi Andy

Ich habe mx4j-tools.jar UND mx4j-jmx.jar ins common/lib kopiert und habe mit MC4J eine Verbindung herstellen koennen.

Zuerst bin ich aber noch ueber einen Bug der neuen MC4J gestolpert, da dieser beim Erstellen der Connection (beim Dialog) das "Finish" zu frueh aktiviert, bevor man den eigentlichen Connector ausgewaehlt hat. Man muss also zuerst brav weiter klicken, den Connector selektieren und erst dann "Finish" druecken.

Vielleicht hilft dir der eine oder andere Tipp!

Gruss,
marcu

[Marcus Spiegel]

Oops...jetzt habe ich glaube ich Kaese erzaehlt
(schon ein wenig spaet .
Das Problem mit Selektieren des Connectors war wohl doch beim JBoss-Dialog und nicht bei MX4J
Aber auf alle Faelle hat die Verbindung MC4J 1.2 mit Tomcat 4.1.27 geklappt.

Gruss, marcu

[O. Weber]

Ich habe es auch ausprobiert und ebenso am Anfang Probleme gehabt. Zsätzlich zu den beiden Files mx4j-tools.jar und mx4j-jmx.jar, musste ich auch noch das log4j.???.jar (die genaue Bezeichnung habe ich gerade nicht dabei) von der CD mit kopieren. Danach lief es bei mir mit Tomcat 4.1.27 problemlos.
Schade nur, dass man die Verbindung bei jedem Start von MC4J erneut eintragen muss. Bei jBoss bleibt der Eintrag enthalten. Da ich mit MC4J unsere Produktiv-Server überwachen möchte, wäre ein Speichern der Verbindungen sehr nützlich. Das nur nebenbei

[Marcus Spiegel]

Hat jemand Erfahrungen mit Entwickeln von eigenen MBean, insbesondere fuer Tomcat? Verstehe ich das richtig, dass wenn man ein MBean fuer Tomcat entwickeln will, man sich an das jakarta-commons/modeler-Package halten muss (z.B. von der ModelMBean-Klasse ableiten)? Man muss ja die MBean in einem entsprechenden descriptor spezifizieren, der ja vom modeler-package kommt, nicht?

Hat jemand damit Erfahrung oder kann mir Tipps geben?

Gruss,
marcu

[Jörg Demmler]

Hi,

hab mc4j bei mir (Windows Server) installiert und versuche es zu testen, indem auf nen Tomcat 4.1.24 verbinde, der auf nem Linux Server läuft. Ich hab folgende Einträge in der jk2.properties des Tomcats vornehmen lassen, da ich selbst keine Schreibrecht auf dem Server hab:

#enable Connection for mc4j
mx.port=8999
mx.enabled=true
mx.jrmpPort=8999
mx.jrmpHost="Servername" (ist der Name des Linux Servers unter dem er sowohl mit putty als auch mit WinSCP erreichbar ist)

Desweiteren hab ich das jar mx4j-tools.jar unter server/lib eingespielt.

Die Verbindung in mc4j ist folgendermassen eingerichtet:

Connection type: MX4J 1.x
Name: so benannt, wie ich ihn nachher in der Liste haben will
JNDI Name: jrmp
Initial Context Factory: com.sun.jndi.rmi.registry.RegistryContextFactory (ist vorausgewählt)
Server URL: rmi://Servername:8999
Principles: leer
Credentials: leer

bei Customize Classpath trage ich ebenfalls nichts ein, da es im mc4j Wiki heisst, der default classpath wäre ok.

Will ich jetzt die Verbindung fertig stellen, kommt die Fehlermeldung : "The Server is not running on the specified port".

Wo liegt jetzt das Problem? Darf ich bei mx.jrmpHost nicht den Namen des Linux Server nehmen auf dem der Tomcat läuft und muss dort auf den Tomcat verweisen? Oder liegt das Problem wo anders?

Ich muss es leider hier fragen, anstatt es auszuprobieren, da ich, wie gesagt, keine Schreibrechte hab und der zuständigen Abteilung nicht andauernd ne Mail schicken kann, änder mal da was und da was, zumal der Server auch noch andere Aufgaben hat, als mir zu Testzwecken zur Verfügung zu stehen.

Wäre cool, wenn mir jemand sagen könnte, wo ich was falsch eingestellt hab, die Beispiele, die ich im Internet gefunden hab, helfen mir bei diesem Problem nicht weiter.

Gruß Jör

[Jörg Demmler]

Kann mir niemand helfen

[PRossbach]

Was für eine Fehlermeldung steht den im Log file?

Vermutlich findet der Tomcat die Klassen in server/lib nicht. Ich
meine, das im Tomcat 4.1 die Klassen im System Classpath liegen
muss. Dazu muss man den Path in der Datei bin/setclasspath.
[sh,bat] anpassen.

Schau Dir mal in meiner TomC@Kolumne 01/2004 nach.
http://tomcat.objektpark.org/kolumne/kolumneArchiv.html
Es gibt da auch eine Beispiel Konfiguration.

Im JavaMagazin 02/2006 findest Du die Integration von JMX mit
Java 5 und dem Tomcat 5.5.

Pete

[Jörg Demmler]

Ich kann weder im catalina.out noch im localhost.log nach Tomcat-Neustart eine entsprechende Fehlermeldung finden. Weiterhin konnte ich das Problem soweit eingrenzen, dass bei einer Portauflistung via netstat -a, der Port 8999 nicht dabei ist.
Nach der Lektüre Ihrer Kolumne ist mir auch aufgefallen, dass der ServerLifecycleListener in unserer server.xml auskommentiert ist. Könnte dies auch der Grund für meine bisherigen Probleme sein? Oder sind es doch eher, die nichtgefundenen Klassen (wobei das mx4j_jmx. jar aber auch in diesem Ordner liegt) ? Ich möchte, wie gesagt, nicht andauernd den Tomcat umkonfigurieren lassen, da er Produktivaufgaben hat.

Für Ihren Support herzlichen Dank

Viele Grüße

Jör

[PRossbach]

Der ServerLifecycleListener sollte bei der Verwendung von JMX
besser einkommentiert sein. Im Tomcat 4.1 hängt diese Klasse
einige wichtige JMX Objekte in den MBeanServer ein. Außerderm
kann man den ServerLifecycleListener als Alternative für die
Erzeugung eines JMX-RMi Adapter verwenden. Wenn im log nicht
explizit steht, das der JMX Adapter gestartet wurde, sind die
Klasse nicht korrekt im Classpath. Also einfach mal das mx4j-
tools.jar im System ClassPath (setclasspath.sh bzw. bat) eintragen

[Jörg Demmler]

Der LifecycleListener ist drin, und mx4j-tools.jar ist im Classpath, aber jetzt kommt diese Fehlermeldung im catalina.out:

[INFO] JkMX - -Stoping JMX
javax.management.InstanceNotFoundException: MBeanServer cannot find MBean with ObjectName Http:name=HttpAdaptor
at mx4j.server.MBeanServerImpl.findMBeanMetaData(MBea nServerImpl.java:528)
at mx4j.server.MBeanServerImpl.invoke(MBeanServerImpl .java:1351)
at org.apache.jk.common.JkMX.destroy(JkMX.java:210)
at org.apache.jk.server.JkMain.stop(JkMain.java:308)
at org.apache.jk.server.JkCoyoteHandler.destroy(JkCoy oteHandler.java:179)
at org.apache.coyote.tomcat4.CoyoteConnector.stop(Coy oteConnector.java:1166)
at org.apache.catalina.core.StandardService.stop(Stan dardService.java:546)
at org.apache.catalina.core.StandardServer.stop(Stand ardServer.java:2225)
at org.apache.catalina.startup.Catalina$CatalinaShutd ownHook.run(Catalina.java:624)

Warum wird der HttpAdaptor, der ja Bestandteil von mx4j-tools.jar ist, nicht am MBeanServer registriert

[Jörg Demmler]

Liegt es daran, dass ich im ServerLifecycleListener auf keinen Descriptor verweise? Allerdings finde ich auch keinen Descriptor im mx4j-tool.jar (außer der Klasse HttpAdaptorMBeanDescription, die ich aber aufgrund ihrer Formatierung nicht lesen kann) und wüsste nicht, worauf ich verweisen soll

[Jörg Demmler]

???
jetzt versteh ich gar nichts mehr, die Fehlermeldung im catalina.out sieht jetzt auf einmal folgendermaßen aus, obwohl ich nichts verändert habe:

[INFO] Registry - -Loading registry information
[INFO] Registry - -Creating new Registry instance
[INFO] Registry - -Creating MBeanServer
java.lang.NoClassDefFoundError: javax/management/RuntimeOperationsException
at javax.management.MBeanServerFactory.getLogger(MBea nServerFactory.java:32)
at javax.management.MBeanServerFactory.createMBeanSer verImpl(MBeanServerFactory.java:172)
at javax.management.MBeanServerFactory.createMBeanSer ver(MBeanServerFactory.java:42)
at javax.management.MBeanServerFactory.createMBeanSer ver(MBeanServerFactory.java:37)
at org.apache.commons.modeler.Registry.getServer(Regi stry.java:245)
at org.apache.catalina.mbeans.MBeanUtils.createServer (MBeanUtils.java:1748)
at org.apache.catalina.mbeans.MBeanUtils.<clinit>(MBe anUtils.java:169)
at org.apache.catalina.mbeans.GlobalResourcesLifecycl eListener.<clinit>(GlobalResourcesLifecycleListene r.java:117)
at java.lang.Class.newInstance0(Native Method)
at java.lang.Class.newInstance(Class.java:232)
at org.apache.commons.digester.ObjectCreateRule.begin (ObjectCreateRule.java:253)
at org.apache.commons.digester.Rule.begin(Rule.java:2 00)
at org.apache.commons.digester.Digester.startElement( Digester.java:1268)
at org.apache.xerces.parsers.AbstractSAXParser.startE lement(Unknown Source)
at org.apache.xerces.parsers.AbstractXMLDocumentParse r.emptyElement(Unknown Source)
at org.apache.xerces.impl.XMLDocumentFragmentScannerI mpl.scanStartElement(Unknown Source)
at org.apache.xerces.impl.XMLDocumentFragmentScannerI mpl$FragmentContentDispatcher.dispatch(Unknown Source)
at org.apache.xerces.impl.XMLDocumentFragmentScannerI mpl.scanDocument(Unknown Source)
at org.apache.xerces.parsers.DTDConfiguration.parse(U nknown Source)
at org.apache.xerces.parsers.DTDConfiguration.parse(U nknown Source)
at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
at org.apache.xerces.parsers.AbstractSAXParser.parse( Unknown Source)
at org.apache.commons.digester.Digester.parse(Digeste r.java:1543)
at org.apache.catalina.startup.Catalina.start(Catalin a.java:449)
at org.apache.catalina.startup.Catalina.execute(Catal ina.java:400)
at org.apache.catalina.startup.Catalina.process(Catal ina.java:180)
at java.lang.reflect.Method.invoke(Native Method)
at org.apache.catalina.startup.Bootstrap.main(Bootstr ap.java:203)

Die Klasse RuntimeOperationsException ist Bestandteil des mx4j-jmx.jar, das ja standardmäßig im Tomcat implementiert ist. Findet er die Klasse durch die Anpassung des Classpath nicht mehr? Hier der Classpath:

CLASSPATH="$JAVA_HOME"/lib/tools.jar:/opt/tomcat18039/server/lib/mx4j-tools.ja

[Jörg Demmler]

Nächstes Problem:

ServerLifecycleListener ist eingeschaltet, zusätzlich zum mx4j-tool.jar habe ich noch das mx4j-jmx.jar und das mx4j-impl.jar aus dem mx4j-3.0.1.zip von http://mx4j.sourceforge.net/ eingespielt und in den Classpath eingetragen. Dennoch erhalte ich weiterhin folgende Fehlermeldung im catalina.out:

[ERROR] JkMX - -Can't load the MX4J http adapter javax.management.ReflectionException: null nested exception is java.lang.ClassNotFoundException: mx4j.adaptor.http.HttpAdaptor

Das Problem ist klar, der Pfad im mx4j-tools.jar lautet inzwischen mx4j.tools.adaptor.http.HttpAdaptor. Aber wie kann das sein, das mx4j-jmx.jar ist doch auf dem gleichen Stand wie das mx4j-tools.jar? Oder gibt es außerhalb des mx4j-jmx.jar noch Klassen, die versuchen, die HttpAdaptor-Klasse zu laden und eine javax.management.ReflectionException werfen?

Viele Grüße

Jör

[Jörg Demmler]

Lösungen waren: mx4j-jmx.jar und mx4j-tools.jar in der Datei setclasspath.sh in den Classpath eintragen (werden nicht automatisch gezogen)

Ein weiteres Problem ergab sich bei mir, dass beim neuesten mx4j-tools.jar der HttpAdaptor unter mx4j.tools.adaptor.http liegt, gesucht wurde er aber unter mx4j.adaptor.http. (Komischerweise habe ich sämtliche jars, die mx4j betreffen, aus dem gleichen zip eingespielt). Ich hab dann jedenfalls das mx4j-tools.jar aus der mc4j-Anwendung genommen, damit hats funktioniert