DO NOT REPLY [Bug 36976] New: - Tomcat VM does not shutdown with remote jmx enabled

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=36976>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=36976

   Summary: Tomcat VM does not shutdown with remote jmx enabled
   Product: Tomcat 5
   Version: 5.5.9
  Platform: PC
OS/Version: Windows XP
Status: NEW
  Severity: normal
  Priority: P2
 Component: Unknown
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


When using tomcat with remote jmx it does not shutdown. Using it with local jmx
works perfectly.

jmx parameters set in catalina.bat as JAVA_OPTS
-Dcom.sun.management.jmxremote
-Dcom.sun.management.jmxremote.ssl=false
-Dcom.sun.management.jmxremote.authenticate=false
-Dcom.sun.management.jmxremote.port=

Calling shutdown.bat I get the following error:

Error: Exception thrown by the agent : java.rmi.server.ExportException : Port
already in use: ;nested exception is:
java.net.BindException: Address already in use: JVM_Bind

Tomcat keeps running instead of performing a clean shutdown.

JVM is a 1.5.0_04
Tomcat installation is a default from 5.5.9.zip without configuration changes

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[PATCH] immediately observe JMX-driven host alias changes

[Luke Kirby]

Heya,

I was surprised to discover that the Host object exposed via JMX
allows for addAlias/removeAlias operations but that these changes were
never communicated to the Mapper. As such, they weren't immediately
effective and were only really of use with the Admin application,
which can be used to write the new aliases of the host back to
server.xml, effective on restart.

This patch communicates JMX-driven host alias changes to the mapper so
that the alias is immediately available for use without any need for a
restart, much like JMX-driven host removals/additions already work.

The approach I've taken is to have the StandardHostMBean fire JMX
AttributeChangeNotifications after an add/removeAlias operation. I
changed MapperListener to observe these notifications and then reflect
the change in the the Mapper instance it serves (this required a
little more smarts in Mapper). I had to change
catalina/core/mbeans-descriptor.xml to reinstate StandardHostMBean as
the MBean to be used for StandardHost - I couldn't see where
StandardHostMBean was actually being used before.. any reason? I took
this approach because MapperListener was already JMX-based; I guess
one could choose to do something based more on internal events, but I
hope this suffices.

The patch follows my signature. Let me know if I've missed something
or this solution is unsatisfactory. Hope it works!

Thanks,

  Luke

Index: 
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/connector/MapperListener.java
===
RCS file: 
/home/cvspublic/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/connector/MapperListener.java,v
retrieving revision 1.2
diff -u -r1.2 MapperListener.java
--- 
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/connector/MapperListener.java
29
Jan 2005 19:42:27 - 1.2
+++ 
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/connector/MapperListener.java
14
Sep 2005 18:03:31 -
@@ -24,6 +24,9 @@
 import javax.management.NotificationListener;
 import javax.management.ObjectInstance;
 import javax.management.ObjectName;
+import javax.management.AttributeChangeNotificationFilter;
+import javax.management.AttributeChangeNotification;
+import javax.management.ListenerNotFoundException;
 
 import org.apache.commons.logging.Log;
 import org.apache.commons.logging.LogFactory;
@@ -69,6 +72,13 @@
 private String domain="*";
 private String engine="*";
 
+/**
+ * The filter for host alias attribute change notifications
+ */
+private AttributeChangeNotificationFilter
hostAliasAttributeNotificationFilter =
+new AttributeChangeNotificationFilter();
+
+
 // --- Constructors
 
 
@@ -77,6 +87,8 @@
  */
 public MapperListener(Mapper mapper) {
 this.mapper = mapper;
+hostAliasAttributeNotificationFilter.disableAllAttributes();
+hostAliasAttributeNotificationFilter.enableAttribute("aliases");
 }
 
 
@@ -159,6 +171,21 @@
 ObjectName objectName = new ObjectName(
 "JMImplementation:type=MBeanServerDelegate");
 mBeanServer.removeNotificationListener(objectName, this);
+
+// remove listeners from all host objects
+Set hostMBeans = mBeanServer.queryMBeans(new
ObjectName(domain + ":type=Host,*"), null);
+Iterator hostMBeanIt = hostMBeans.iterator();
+while (hostMBeanIt.hasNext())
+{
+final ObjectInstance hostMBean =
(ObjectInstance)hostMBeanIt.next();
+try
+{
+   
mBeanServer.removeNotificationListener(hostMBean.getObjectName(),
this);
+} catch (Exception e) {
+log.warn("Error unregistering host listener", e);
+}
+}
+
 } catch (Exception e) {
 log.warn("Error unregistering MBeanServerDelegate", e);
 }
@@ -245,6 +272,25 @@
 }
 }
 }
+
+} else if (notification instanceof AttributeChangeNotification) {
+
+final AttributeChangeNotification attrChangeNotification
= (AttributeChangeNotification)notification;
+
+if ("aliases".equals(attrChangeNotification.getAttributeName()))
+{
+final ObjectName hostName = (ObjectName)
attrChangeNotification.getSource();
+try
+{
+reconfigureAliases(
+hostName,
+(String[])attrChangeNotification.getNewValue());
+}
+catch (Throwable t)
+{
+log.warn("Error updating aliases for " + hostName, t);
+}
+}
 

cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/ant/jmx JMXAccessorCreateTask.java JMXAccessorUnregisterTask.java JMXAccessorQueryTask.java JMXAccessorSetTask.java JMXAccessorTask.java antlib.xml jmxaccessor.tasks

[pero]

pero2005/09/14 06:28:29

  Modified:catalina/src/share/org/apache/catalina/ant/jmx
JMXAccessorQueryTask.java JMXAccessorSetTask.java
JMXAccessorTask.java antlib.xml jmxaccessor.tasks
  Added:   catalina/src/share/org/apache/catalina/ant/jmx
JMXAccessorCreateTask.java
JMXAccessorUnregisterTask.java
  Log:
  Add create remote Mbeans and unregister tasks
  fix some small typos!
  
  Revision  ChangesPath
  1.6   +2 -2  
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/ant/jmx/JMXAccessorQueryTask.java
  
  Index: JMXAccessorQueryTask.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/ant/jmx/JMXAccessorQueryTask.java,v
  retrieving revision 1.5
  retrieving revision 1.6
  diff -u -r1.5 -r1.6
  --- JMXAccessorQueryTask.java 27 Jul 2005 15:11:17 -  1.5
  +++ JMXAccessorQueryTask.java 14 Sep 2005 13:28:29 -  1.6
  @@ -106,7 +106,7 @@
* input stream will be closed upon completion of this task, whether it 
was
* executed successfully or not.
* 
  - * @exception BuildException
  + * @exception Exception
*if an error occurs
*/
   public String jmxExecute(MBeanServerConnection jmxServerConnection)
  
  
  
  1.5   +2 -2  
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/ant/jmx/JMXAccessorSetTask.java
  
  Index: JMXAccessorSetTask.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/ant/jmx/JMXAccessorSetTask.java,v
  retrieving revision 1.4
  retrieving revision 1.5
  diff -u -r1.4 -r1.5
  --- JMXAccessorSetTask.java   27 Jul 2005 15:11:17 -  1.4
  +++ JMXAccessorSetTask.java   14 Sep 2005 13:28:29 -  1.5
  @@ -152,7 +152,7 @@
* input stream will be closed upon completion of this task, whether it 
was
* executed successfully or not.
* 
  - * @exception BuildException
  + * @exception Exception
*if an error occurs
*/
   public String jmxExecute(MBeanServerConnection jmxServerConnection)
  
  
  
  1.13  +2 -2  
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/ant/jmx/JMXAccessorTask.java
  
  Index: JMXAccessorTask.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/ant/jmx/JMXAccessorTask.java,v
  retrieving revision 1.12
  retrieving revision 1.13
  diff -u -r1.12 -r1.13
  --- JMXAccessorTask.java  27 Jul 2005 15:11:18 -  1.12
  +++ JMXAccessorTask.java  14 Sep 2005 13:28:29 -  1.13
  @@ -491,7 +491,7 @@
* input stream will be closed upon completion of this task, whether it 
was
* executed successfully or not.
* 
  - * @exception BuildException
  + * @exception Exception
*if an error occurs
*/
   public String jmxExecute(MBeanServerConnection jmxServerConnection)
  
  
  
  1.3   +6 -0  
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/ant/jmx/antlib.xml
  
  Index: antlib.xml
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/ant/jmx/antlib.xml,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- antlib.xml30 Jun 2005 13:01:27 -  1.2
  +++ antlib.xml14 Sep 2005 13:28:29 -  1.3
  @@ -16,6 +16,12 @@
   name="query"
   classname="org.apache.catalina.ant.jmx.JMXAccessorQueryTask" />
 
  +  
  +  
 http://www.apache.org/licenses/LICENSE-2.0
   * 
   * Unless required by applicable law or agreed to in writing, software
   * distributed under the License is distributed on an "AS IS" BASIS,
   * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
   * See the License for the specific language governing permissions and
   * limitations under the License.
   */
  package org.apache.catalina.ant.jmx;
  
  import java.util.ArrayList;
  import java.util.List;
  
  import javax.management.MBeanServerConnection;
  import javax.management.ObjectName;
  
  import org.apache.tools.ant.BuildException;
  
  /**
   * Create new MBean at JMX JSR 160 MBeans Server. 
   * 
   * Create Mbeans
   * Create Mbeans with parameter
   * Create remote Mbeans with different classloader
   * 
   * 
   * Examples:
   * 
   * create a new Mbean at jmx.server connection 
   * 
   *   <jmx:create
   *   ref="jmx.server"
   *   name="Catalina:type=MBeanFactory"
   * 

cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/ant/jmx JMXAccessorGetTask.java JMXAccessorInvokeTask.java JMXAccessorQueryTask.java JMXAccessorSetTask.java JMXAccessorTask.java

[pero]

pero2005/07/22 04:39:08

  Modified:catalina/src/share/org/apache/catalina/ant/jmx
JMXAccessorGetTask.java JMXAccessorInvokeTask.java
JMXAccessorQueryTask.java JMXAccessorSetTask.java
JMXAccessorTask.java
  Log:
  Make Tasks also usefull outside ant script projects.
  handle empty project attribute
  properties can save also as local map.
  
  Revision  ChangesPath
  1.3   +2 -2  
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/ant/jmx/JMXAccessorGetTask.java
  
  Index: JMXAccessorGetTask.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/ant/jmx/JMXAccessorGetTask.java,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- JMXAccessorGetTask.java   30 Jun 2005 13:01:27 -  1.2
  +++ JMXAccessorGetTask.java   22 Jul 2005 11:39:08 -  1.3
  @@ -107,7 +107,7 @@
* @exception BuildException
*if an error occurs
*/
  -protected String jmxExecute(MBeanServerConnection jmxServerConnection)
  +public String jmxExecute(MBeanServerConnection jmxServerConnection)
   throws Exception {
   
   if (getName() == null) {
  
  
  
  1.3   +2 -2  
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/ant/jmx/JMXAccessorInvokeTask.java
  
  Index: JMXAccessorInvokeTask.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/ant/jmx/JMXAccessorInvokeTask.java,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- JMXAccessorInvokeTask.java30 Jun 2005 13:01:27 -  1.2
  +++ JMXAccessorInvokeTask.java22 Jul 2005 11:39:08 -  1.3
  @@ -158,7 +158,7 @@
* @exception BuildException
*if an error occurs
*/
  -protected String jmxExecute(MBeanServerConnection jmxServerConnection)
  +public String jmxExecute(MBeanServerConnection jmxServerConnection)
   throws Exception {
   
   if (getName() == null) {
  
  
  
  1.4   +2 -2  
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/ant/jmx/JMXAccessorQueryTask.java
  
  Index: JMXAccessorQueryTask.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/ant/jmx/JMXAccessorQueryTask.java,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- JMXAccessorQueryTask.java 8 Jul 2005 20:54:40 -   1.3
  +++ JMXAccessorQueryTask.java 22 Jul 2005 11:39:08 -  1.4
  @@ -109,7 +109,7 @@
* @exception BuildException
*if an error occurs
*/
  -protected String jmxExecute(MBeanServerConnection jmxServerConnection)
  +public String jmxExecute(MBeanServerConnection jmxServerConnection)
   throws Exception {
   
   if (getName() == null) {
  
  
  
  1.3   +2 -2  
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/ant/jmx/JMXAccessorSetTask.java
  
  Index: JMXAccessorSetTask.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/ant/jmx/JMXAccessorSetTask.java,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- JMXAccessorSetTask.java   30 Jun 2005 13:01:27 -  1.2
  +++ JMXAccessorSetTask.java   22 Jul 2005 11:39:08 -  1.3
  @@ -155,7 +155,7 @@
* @exception BuildException
*if an error occurs
*/
  -protected String jmxExecute(MBeanServerConnection jmxServerConnection)
  +public String jmxExecute(MBeanServerConnection jmxServerConnection)
   throws Exception {
   
   if (getName() == null) {
  
  
  
  1.10  +231 -160  
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/ant/jmx/JMXAccessorTask.java
  
  Index: JMXAccessorTask.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/ant/jmx/JMXAccessorTask.java,v
  retrieving revision 1.9
  retrieving revision 1.10
  diff -u -r1.9 -r1.10
  --- JMXAccessorTask.java  21 Jul 2005 10:45:45 -  1.9
  +++ JMXAccessorTask.java  22 Jul 2005 11:39:08 -  1.10
  @@ -14,10 +14,8 @@
* limitations under the License.
*/
   
  -
   package org.apache.catalina.ant.jmx;
   
  -
   import java.io.IOException;
   import java.lang.reflect.Array;
   import java.net.InetAddress;
  @@ -27,6 +25,7 @@
   import java.util.Iterator;
   import java.util.List;
   import java.util.Map;
  +import java.util.Properties;
   import

cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/ant/jmx JMXAccessorTask.java

[pero]

pero2005/07/21 03:45:46

  Modified:catalina/src/share/org/apache/catalina/ant/jmx
JMXAccessorTask.java
  Log:
  remove useless array cast
  
  Revision  ChangesPath
  1.9   +1 -3  
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/ant/jmx/JMXAccessorTask.java
  
  Index: JMXAccessorTask.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/ant/jmx/JMXAccessorTask.java,v
  retrieving revision 1.8
  retrieving revision 1.9
  diff -u -r1.8 -r1.9
  --- JMXAccessorTask.java  21 Jul 2005 07:19:12 -  1.8
  +++ JMXAccessorTask.java  21 Jul 2005 10:45:45 -  1.9
  @@ -553,7 +553,6 @@
   protected void echoResult(String name,Object result ) {
   if(isEcho()) {
   if (result.getClass().isArray()) {
  -Object array[] = (Object[]) result;
   for (int i = 0; i < Array.getLength(result); i++) {
   handleOutput(name + "." + i + "=" + Array.get(result, 
i));
   }
  @@ -617,7 +616,6 @@
   }
   } else if (result.getClass().isArray()) {
   if (isSeparatearrayresults()) {
  -Object array[] = (Object[]) result;
   int size = 0 ;
   for (int i = 0; i < Array.getLength(result); i++) {
   if(setProperty(propertyPrefix + "." + size , 
Array.get(result, i))) {
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/ant/jmx JMXAccessorTask.java

[pero]

pero2005/07/21 00:19:12

  Modified:catalina/src/share/org/apache/catalina/ant/jmx
JMXAccessorTask.java
  Log:
  Fix get Array Length
  
  Revision  ChangesPath
  1.8   +3 -3  
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/ant/jmx/JMXAccessorTask.java
  
  Index: JMXAccessorTask.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/ant/jmx/JMXAccessorTask.java,v
  retrieving revision 1.7
  retrieving revision 1.8
  diff -u -r1.7 -r1.8
  --- JMXAccessorTask.java  19 Jul 2005 08:38:27 -  1.7
  +++ JMXAccessorTask.java  21 Jul 2005 07:19:12 -  1.8
  @@ -554,7 +554,7 @@
   if(isEcho()) {
   if (result.getClass().isArray()) {
   Object array[] = (Object[]) result;
  -for (int i = 0; i < array.length; i++) {
  +for (int i = 0; i < Array.getLength(result); i++) {
   handleOutput(name + "." + i + "=" + Array.get(result, 
i));
   }
   } else
  @@ -619,7 +619,7 @@
   if (isSeparatearrayresults()) {
   Object array[] = (Object[]) result;
   int size = 0 ;
  -for (int i = 0; i < array.length; i++) {
  +for (int i = 0; i < Array.getLength(result); i++) {
   if(setProperty(propertyPrefix + "." + size , 
Array.get(result, i))) {
   size++;
   }
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/ant/jmx JMXAccessorTask.java

[pero]

pero2005/07/19 01:38:48

  Modified:catalina/src/share/org/apache/catalina/ant/jmx
JMXAccessorTask.java
  Log:
  Fix use primitiv datatypes as arrays - submitted by Wolfgang Miller-Reichling
  
  Revision  ChangesPath
  1.7   +4 -3  
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/ant/jmx/JMXAccessorTask.java
  
  Index: JMXAccessorTask.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/ant/jmx/JMXAccessorTask.java,v
  retrieving revision 1.6
  retrieving revision 1.7
  diff -u -r1.6 -r1.7
  --- JMXAccessorTask.java  16 Jul 2005 21:09:21 -  1.6
  +++ JMXAccessorTask.java  19 Jul 2005 08:38:27 -  1.7
  @@ -19,6 +19,7 @@
   
   
   import java.io.IOException;
  +import java.lang.reflect.Array;
   import java.net.InetAddress;
   import java.net.MalformedURLException;
   import java.net.UnknownHostException;
  @@ -554,7 +555,7 @@
   if (result.getClass().isArray()) {
   Object array[] = (Object[]) result;
   for (int i = 0; i < array.length; i++) {
  -handleOutput(name + "." + i + "=" + array[i]);
  +handleOutput(name + "." + i + "=" + Array.get(result, 
i));
   }
   } else
   handleOutput(name + "=" + result);
  @@ -619,7 +620,7 @@
   Object array[] = (Object[]) result;
   int size = 0 ;
   for (int i = 0; i < array.length; i++) {
  -if(setProperty(propertyPrefix + "." + size , array[i])) {
  +if(setProperty(propertyPrefix + "." + size , 
Array.get(result, i))) {
   size++;
   }
   }
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/ant/jmx JMXAccessorTask.java

[pero]

pero2005/07/16 14:09:21

  Modified:catalina/src/share/org/apache/catalina/ant/jmx
JMXAccessorTask.java
  Log:
  Support JMX OpenTypes as createProperties
  
  Revision  ChangesPath
  1.6   +33 -5 
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/ant/jmx/JMXAccessorTask.java
  
  Index: JMXAccessorTask.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/ant/jmx/JMXAccessorTask.java,v
  retrieving revision 1.5
  retrieving revision 1.6
  diff -u -r1.5 -r1.6
  --- JMXAccessorTask.java  8 Jul 2005 20:54:40 -   1.5
  +++ JMXAccessorTask.java  16 Jul 2005 21:09:21 -  1.6
  @@ -24,6 +24,7 @@
   import java.net.UnknownHostException;
   import java.util.HashMap;
   import java.util.Iterator;
  +import java.util.List;
   import java.util.Map;
   import java.util.Set;
   import java.util.StringTokenizer;
  @@ -31,7 +32,12 @@
   import javax.management.MBeanServerConnection;
   import javax.management.MalformedObjectNameException;
   import javax.management.ObjectName;
  +import javax.management.openmbean.CompositeData;
   import javax.management.openmbean.CompositeDataSupport;
  +import javax.management.openmbean.CompositeType;
  +import javax.management.openmbean.OpenType;
  +import javax.management.openmbean.SimpleType;
  +import javax.management.openmbean.TabularDataSupport;
   import javax.management.remote.JMXConnector;
   import javax.management.remote.JMXConnectorFactory;
   import javax.management.remote.JMXServiceURL;
  @@ -105,7 +111,7 @@
   /**
* Descriptive information describing this implementation.
*/
  -private static final String info = 
"org.apache.catalina.ant.JMXAccessorTask/1.0";
  +private static final String info = 
"org.apache.catalina.ant.JMXAccessorTask/1.1";
   
   /**
* Return descriptive information about this implementation and the
  @@ -580,12 +586,34 @@
   propertyPrefix = "";
   if (result instanceof CompositeDataSupport) {
   CompositeDataSupport data = (CompositeDataSupport) result ;
  -Set keys = data.getCompositeType().keySet() ;
  +CompositeType compositeType = data.getCompositeType();
  +Set keys = compositeType.keySet() ;
   for (Iterator iter = keys.iterator(); iter.hasNext();) {
   String key = (String) iter.next();  
   Object value = data.get(key);
  -setProperty(propertyPrefix + "." + key , value); 
   
  -}
  +OpenType type = compositeType.getType(key);
  +if(type instanceof SimpleType ) {
  +setProperty(propertyPrefix + "." + key , value); 
   
  +} else { 
  +createProperty(propertyPrefix + "." + key, value );
  +}
  +}
  +} else if (result instanceof TabularDataSupport) {
  +TabularDataSupport data = (TabularDataSupport) result ;
  +for (Iterator iter = data.keySet().iterator(); iter.hasNext();) {
  +Object key = iter.next();
  +for(Iterator iter1 = ((List)key).iterator(); 
iter1.hasNext();) {
  +Object key1= iter1.next();
  +CompositeData valuedata = data.get(new Object[] { key1 } 
);
  +Object value = valuedata.get("value");
  +OpenType type = 
valuedata.getCompositeType().getType("value");
  +if(type instanceof SimpleType ) {
  +setProperty(propertyPrefix + "." + key1 , value);

  +} else { 
  +createProperty(propertyPrefix + "." + key1, value );
  +}
  +}
  +}
   } else if (result.getClass().isArray()) {
   if (isSeparatearrayresults()) {
   Object array[] = (Object[]) result;
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/ant/jmx JMXAccessorQueryTask.java JMXAccessorTask.java

[pero]

pero2005/07/08 13:54:40

  Modified:catalina/src/share/org/apache/catalina/ant/jmx
JMXAccessorQueryTask.java JMXAccessorTask.java
  Log:
  more support for MXBean data
  better property binding support
  
  Revision  ChangesPath
  1.3   +54 -60
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/ant/jmx/JMXAccessorQueryTask.java
  
  Index: JMXAccessorQueryTask.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/ant/jmx/JMXAccessorQueryTask.java,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- JMXAccessorQueryTask.java 30 Jun 2005 13:01:27 -  1.2
  +++ JMXAccessorQueryTask.java 8 Jul 2005 20:54:40 -   1.3
  @@ -135,31 +135,29 @@
   String resultproperty = getResultproperty();
   try {
   names = jmxServerConnection.queryNames(new ObjectName(qry), 
null);
  -if (resultproperty != null)
  -getProject().setNewProperty(resultproperty + ".length",
  -Integer.toString(names.size()));
  +if (resultproperty != null) {
  +setProperty(resultproperty + 
".Length",Integer.toString(names.size()));
  +}
   } catch (Exception e) {
   if (isEcho())
   handleErrorOutput(e.getMessage());
   return "Can't query mbeans " + qry;
   }
   
  -Iterator it = names.iterator();
  -int oindex = 0;
  -String pname = null;
  -while (it.hasNext()) {
  -ObjectName oname = (ObjectName) it.next();
  -pname = resultproperty + "." + Integer.toString(oindex) + ".";
  -oindex++;
  -if (isEcho())
  -handleOutput(pname + "name=" + oname.toString());
  -if (resultproperty != null) {
  -getProject().setNewProperty(pname + "name",
  -oname.toString());
  -}
  -if (isAttributebinding()) {
  -bindAttributes(jmxServerConnection, resultproperty, pname, 
oname);
  -}
  +if (resultproperty != null) {
  +Iterator it = names.iterator();
  +int oindex = 0;
  +String pname = null;
  +while (it.hasNext()) {
  +ObjectName oname = (ObjectName) it.next();
  +pname = resultproperty + "." + Integer.toString(oindex) + 
".";
  +oindex++;
  +setProperty(pname + "Name", oname.toString());
  +if (isAttributebinding()) {
  +bindAttributes(jmxServerConnection, resultproperty, 
pname, oname);
  +
  +}
  +}
   }
   return isError;
   }
  @@ -171,50 +169,46 @@
* @param oname
*/
   protected void bindAttributes(MBeanServerConnection jmxServerConnection, 
String resultproperty, String pname, ObjectName oname) {
  -try {
  -MBeanInfo minfo = jmxServerConnection.getMBeanInfo(oname);
  -String code = minfo.getClassName();
  -if ("org.apache.commons.modeler.BaseModelMBean"
  -.equals(code)) {
  -code = (String) jmxServerConnection.getAttribute(oname,
  -"modelerType");
  -}
  -MBeanAttributeInfo attrs[] = minfo.getAttributes();
  -Object value = null;
  -
  -for (int i = 0; i < attrs.length; i++) {
  -if (!attrs[i].isReadable())
  -continue;
  -String attName = attrs[i].getName();
  -if (attName.indexOf("=") >= 0
  -|| attName.indexOf(":") >= 0
  -|| attName.indexOf(" ") >= 0) {
  -continue;
  +if (jmxServerConnection != null  && resultproperty != null 
  +&& pname != null && oname != null ) {
  +try {
  +MBeanInfo minfo = jmxServerConnection.getMBeanInfo(oname);
  +String code = minfo.getClassName();
  +if 
("org.apache.commons.modeler.BaseModelMBean".equals(code)) {
  +code = (String) jmxServerConnection.getAttribute(oname,
  +"modelerType");
   }
  +MBeanAttributeInfo attrs[] = minfo.getAttributes();
  +Object value = null;
   
  -try {
  -value = jmxServerConnection.getAttribute(oname,
  -attName);
  -

DO NOT REPLY [Bug 35635] New: - Cannot pass JMX arguments to Tomcat JRE

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=35635>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=35635

   Summary: Cannot pass JMX arguments to Tomcat JRE
   Product: Tomcat 5
   Version: 5.5.9
  Platform: PC
OS/Version: Windows XP
Status: NEW
  Severity: normal
  Priority: P2
 Component: Native:Integration
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


I think this issue is related to Bug #35128

Now instead of not being able to pass "-ea", I am not able to pass in the
following arguments:

-Dcom.sun.management.jmxremote.port=
-Dcom.sun.management.jmxremote.password.file=C:\Documents and
Settings\User\jmxremote.password

net start Tomcat5 returns error 1067

If I remove these arguments, it starts up just fine. I tried the attachment in
Bug #35128 but it didn't help.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/ant/jmx JMXAccessorCondition.java JMXAccessorTask.java

[Natasha Hasmani]

Thank-you for your e-mail.

Please note that i will be away from the office starting Wednesday June
29th, returning Thursday July 7th, with no access to email.  In my absence,
kindly contact Cheri Dueck at [EMAIL PROTECTED]

Kind Regards,

Natasha Hasmani
Senior Event Manager 



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/ant/jmx JMXAccessorCondition.java JMXAccessorTask.java

[Natasha Hasmani]

Thank-you for your e-mail.

Please note that i will be away from the office starting Wednesday June
29th, returning Thursday July 7th, with no access to email.  In my absence,
kindly contact Cheri Dueck at [EMAIL PROTECTED]

Kind Regards,

Natasha Hasmani
Senior Event Manager 



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/ant/jmx JMXAccessorCondition.java JMXAccessorTask.java

[Natasha Hasmani]

Thank-you for your e-mail.

Please note that i will be away from the office starting Wednesday June
29th, returning Thursday July 7th, with no access to email.  In my absence,
kindly contact Cheri Dueck at [EMAIL PROTECTED]

Kind Regards,

Natasha Hasmani
Senior Event Manager 



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/ant/jmx JMXAccessorCondition.java JMXAccessorTask.java

[pero]

pero2005/07/01 11:54:14

  Modified:catalina/src/share/org/apache/catalina/ant/jmx
JMXAccessorCondition.java JMXAccessorTask.java
  Log:
  Fix doc
  
  Revision  ChangesPath
  1.3   +3 -3  
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/ant/jmx/JMXAccessorCondition.java
  
  Index: JMXAccessorCondition.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/ant/jmx/JMXAccessorCondition.java,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- JMXAccessorCondition.java 1 Jul 2005 11:46:51 -   1.2
  +++ JMXAccessorCondition.java 1 Jul 2005 18:54:13 -   1.3
  @@ -249,7 +249,7 @@
   return ifCondition;
   }
   /**
  - * Only fail if a property of the given name exists in the current 
project.
  + * Only execute if a property of the given name exists in the current 
project.
* @param c property name
*/
   public void setIf(String c) {
  @@ -263,7 +263,7 @@
   }

   /**
  - * Only fail if a property of the given name does not
  + * Only execute if a property of the given name does not
* exist in the current project.
* @param c property name
*/
  
  
  
  1.4   +3 -3  
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/ant/jmx/JMXAccessorTask.java
  
  Index: JMXAccessorTask.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/ant/jmx/JMXAccessorTask.java,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- JMXAccessorTask.java  1 Jul 2005 11:46:51 -   1.3
  +++ JMXAccessorTask.java  1 Jul 2005 18:54:13 -   1.4
  @@ -273,7 +273,7 @@
   return ifCondition;
   }
   /**
  - * Only fail if a property of the given name exists in the current 
project.
  + * Only execute if a property of the given name exists in the current 
project.
* @param c property name
*/
   public void setIf(String c) {
  @@ -287,7 +287,7 @@
   }

   /**
  - * Only fail if a property of the given name does not
  + * Only execute if a property of the given name does not
* exist in the current project.
* @param c property name
*/
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/ant/jmx JMXAccessorCondition.java JMXAccessorTask.java

[pero]

pero2005/07/01 04:46:51

  Modified:catalina/src/share/org/apache/catalina/ant/jmx
JMXAccessorCondition.java JMXAccessorTask.java
  Log:
  Add if and unless
  Fix docs
  
  Revision  ChangesPath
  1.2   +103 -37   
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/ant/jmx/JMXAccessorCondition.java
  
  Index: JMXAccessorCondition.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/ant/jmx/JMXAccessorCondition.java,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- JMXAccessorCondition.java 30 Jun 2005 13:01:27 -  1.1
  +++ JMXAccessorCondition.java 1 Jul 2005 11:46:51 -   1.2
  @@ -88,7 +88,9 @@
   private String operation = "==" ;
   private String type = "long" ;
   private String ref = "jmx.server";
  -
  +private String unlessCondition;
  +private String ifCondition;
  + 
   // - Instance Info
   
   /**
  @@ -240,7 +242,41 @@
   public void setRef(String refId) {
   this.ref = refId;
   }
  -
  +/**
  + * @return Returns the ifCondition.
  + */
  +public String getIf() {
  +return ifCondition;
  +}
  +/**
  + * Only fail if a property of the given name exists in the current 
project.
  + * @param c property name
  + */
  +public void setIf(String c) {
  +ifCondition = c;
  +}
  +   /**
  + * @return Returns the unlessCondition.
  + */
  +public String getUnless() {
  +return unlessCondition;
  +}
  + 
  +/**
  + * Only fail if a property of the given name does not
  + * exist in the current project.
  + * @param c property name
  + */
  +public void setUnless(String c) {
  +unlessCondition = c;
  +}
  +
  +/**
  + * Get JMXConnection (default look at jmx.server project 
reference from jmxOpen Task)
  + * @return active JMXConnection
  + * @throws MalformedURLException
  + * @throws IOException
  + */
   protected MBeanServerConnection getJMXConnection()
   throws MalformedURLException, IOException {
   return JMXAccessorTask.accessJMXConnection(
  @@ -250,6 +286,7 @@
   }
   
   /**
  + * Get value from MBeans attribute 
* @return
*/
   protected String accessJMXValue() {
  @@ -264,7 +301,34 @@
   return null;
   }
   
  -// This method evaluates the condition
  +/**
  + * test the if condition
  + * @return true if there is no if condition, or the named property exists
  + */
  +protected boolean testIfCondition() {
  +if (ifCondition == null || "".equals(ifCondition)) {
  +return true;
  +}
  +return getProject().getProperty(ifCondition) != null;
  +}
  +
  +/**
  + * test the unless condition
  + * @return true if there is no unless condition,
  + *  or there is a named property but it doesn't exist
  + */
  +protected boolean testUnlessCondition() {
  +if (unlessCondition == null || "".equals(unlessCondition)) {
  +return true;
  +}
  +return getProject().getProperty(unlessCondition) == null;
  +}
  +
  +/**
  + * This method evaluates the condition
  + * It support for operation ">,>=,<,<=" the types long and 
double.
  + * @return expression jmxValue operation value
  + */
   public boolean eval() {
   if (operation == null) {
   throw new BuildException("operation attribute is not set");
  @@ -276,43 +340,45 @@
   throw new BuildException(
   "Must specify a 'attribute', name for equals condition");
   }
  -//FIXME check url or host/parameter
  -String jmxValue = accessJMXValue();
  -String op = getOperation() ;
  -if(jmxValue != null) {
  -if("==".equals(op)) {
  -return jmxValue.equals(value);
  -} else if("!=".equals(op)) {
  -return !jmxValue.equals(value);
  -} else { 
  -if("long".equals(type)) {
  -long jvalue = Long.parseLong(jmxValue);  
 
  -long lvalue = Long.parseLong(value);
  -if(">".equals(op)) {
  -return jvalue > lvalue ;
  -} else if(">=".equals(op)) {
  -return jvalue >= lvalue ;
  -} else if("<".equals(op))

cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/ant/jmx JMXAccessorEqualsCondition.java

[pero]

pero2005/06/30 06:15:14

  Modified:catalina/src/share/org/apache/catalina/ant/jmx
JMXAccessorEqualsCondition.java
  Log:
  Add correct super class to support connect by reference
  
  Revision  ChangesPath
  1.3   +3 -2  
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/ant/jmx/JMXAccessorEqualsCondition.java
  
  Index: JMXAccessorEqualsCondition.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/ant/jmx/JMXAccessorEqualsCondition.java,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- JMXAccessorEqualsCondition.java   30 Jun 2005 13:01:27 -  1.2
  +++ JMXAccessorEqualsCondition.java   30 Jun 2005 13:15:13 -  1.3
  @@ -7,6 +7,7 @@
   import javax.management.ObjectName;
   
   import org.apache.tools.ant.BuildException;
  +import org.apache.tools.ant.ProjectComponent;
   import org.apache.tools.ant.taskdefs.condition.Condition;
   
   /**
  @@ -51,7 +52,7 @@
* @since 5.5.10
*
*/
  -public class JMXAccessorEqualsCondition implements Condition {
  +public class JMXAccessorEqualsCondition  extends ProjectComponent  
implements Condition {
   
   // - Instance 
Variables
   
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/ant/jmx JMXAccessorCondition.java JMXAccessorEqualsCondition.java JMXAccessorGetTask.java JMXAccessorInvokeTask.java JMXAccessorQueryTask.java JMXAccessorSetTask.java JMXAccessorTask.java antlib.xml jmxaccessor.tasks

[pero]

pero2005/06/30 06:01:27

  Modified:catalina/src/share/org/apache/catalina/ant/jmx
JMXAccessorEqualsCondition.java
JMXAccessorGetTask.java JMXAccessorInvokeTask.java
JMXAccessorQueryTask.java JMXAccessorSetTask.java
JMXAccessorTask.java antlib.xml jmxaccessor.tasks
  Added:   catalina/src/share/org/apache/catalina/ant/jmx
JMXAccessorCondition.java
  Log:
  Add support for if and unless
  Add more usefull Ant Condition that support reference jmx connection
  Fix some docs
  
  Revision  ChangesPath
  1.2   +31 -16
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/ant/jmx/JMXAccessorEqualsCondition.java
  
  Index: JMXAccessorEqualsCondition.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/ant/jmx/JMXAccessorEqualsCondition.java,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- JMXAccessorEqualsCondition.java   24 Jun 2005 11:52:51 -  1.1
  +++ JMXAccessorEqualsCondition.java   30 Jun 2005 13:01:27 -  1.2
  @@ -12,22 +12,22 @@
   /**
*
* Definition
  - *  
  - *   
  - *   
  - *   
  - *   
  - *   
  - *   
  + *  
  + *   <path id="catalina_ant">
  + *   <fileset dir="${catalina.home}/server/lib">
  + *   <include name="catalina-ant.jar"/>
  + *   <include name="catalina-ant-jmx.jar"/>
  + *   </fileset>
  + *   </path>
*
  - *   
  - * 
  + * 
* 
* usage: Wait for start backup node
  - * 
  + * 
* <target name="wait">
*<waitfor maxwait="${maxwait}" maxwaitunit="second" 
timeoutproperty="server.timeout" >
*   <and>
  @@ -44,7 +44,7 @@
*   <echo message="Server ${url} alive" />
*   </target>
*
  - * 
  + * 
* 
* @author Peter Rossbach
* @version $Revision$ $Date$
  @@ -63,13 +63,13 @@
   private String name = null;
   private String attribute;
   private String value;
  -
  +private String ref = "jmx.server" ;
   // - Instance Info
   
   /**
* Descriptive information describing this implementation.
*/
  -private static final String info = 
"org.apache.catalina.ant.JMXAccessorEqualsCondition/1.0";
  +private static final String info = 
"org.apache.catalina.ant.JMXAccessorEqualsCondition/1.1";
   
   /**
* Return descriptive information about this implementation and the
  @@ -178,10 +178,25 @@
   this.value = value;
   }
   
  +/**
  + * @return Returns the ref.
  + */
  +public String getRef() {
  +return ref;
  +}
  +/**
  + * @param ref The ref to set.
  + */
  +public void setRef(String refId) {
  +this.ref = refId;
  +}
  +
   protected MBeanServerConnection getJMXConnection()
   throws MalformedURLException, IOException {
  -return JMXAccessorTask.createJMXConnection(getUrl(), getHost(),
  -getPort(), getUsername(), getPassword());
  +return JMXAccessorTask.accessJMXConnection(
  +getProject(),
  +getUrl(), getHost(),
  +    getPort(), getUsername(), getPassword(), ref);
   }
   
   /**
  
  
  
  1.2   +4 -4  
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/ant/jmx/JMXAccessorGetTask.java
  
  Index: JMXAccessorGetTask.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/ant/jmx/JMXAccessorGetTask.java,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- JMXAccessorGetTask.java   24 Jun 2005 11:52:51 -  1.1
  +++ JMXAccessorGetTask.java   30 Jun 2005 13:01:27 -  1.2
  @@ -33,9 +33,9 @@
* 
* 
* Examples:
  - * 
  + * 
* Get a Mbean IDataSender attribute nrOfRequests and create a new ant 
property IDataSender.9025.nrOfRequests 
  - * 
  + * 
*   <jmx:get
*   ref="jmx.server"
*   
name="Catalina:type=IDataSender,host=localhost,senderAddress=192.168.1.2,senderPort=9025"
 
  @@ -43,7 +43,7 @@
*   resultproperty="IDataSender.9025.nrOfRequests"
*   echo="false">
    *   />
  - * 
  + * 
* 
* 
* First call to a remote MBeanserver save the JMXConnection a referenz 
jmx.server
  
  
  
  1.2   +3 -3  
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/ant/jmx/JMXAccessorInvokeTask.j

cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/ant/jmx - New directory

[pero]

pero2005/06/24 04:51:37

  jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/ant/jmx - New 
directory

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 34139] - org.apache.catalina.realm.RealmBase.main() requires JMX and log4j

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=34139>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=34139


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED




--- Additional Comments From [EMAIL PROTECTED]  2005-03-24 15:43 ---
OK, docs corrected.  There are license issues with including just any JMX jar,
but we do include an implementation with the distro.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 34139] New: - org.apache.catalina.realm.RealmBase.main() requires JMX and log4j

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=34139>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=34139

   Summary: org.apache.catalina.realm.RealmBase.main() requires JMX
and log4j
   Product: Tomcat 5
   Version: 5.5.7
  Platform: PC
OS/Version: Windows XP
Status: NEW
  Severity: normal
  Priority: P4
 Component: Catalina
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


The Tomcat 5.5 documentation states that catalina.jar is the only jar required
on the classpath to run org.apache.catalina.realm.RealmBase.main. (See
http://jakarta.apache.org/tomcat/tomcat-5.5-doc/realm-howto.html#Digested%20Passwords)

UNDER 5.0.28:
If run with only catalina.jar, you get:

Exception in thread "main" java.lang.NoClassDefFoundError:
javax/management/MBeanRegistration

Adding the $TOMCAT_HOME/bin/jmx.jar to the classpath fixes this exception, but
then you get:

Exception in thread "main" java.lang.NoClassDefFoundError:
org/apache/commons/logging/LogFactory

Adding $TOMCAT_HOME/bin/commons-logging-api.jar permits the program to run 
properly.

UNDER 5.5.7:
No jar distributed with Tomcat 5.5.7 contains
javax/management/MBeanRegistration. If you add 5.0.28's jmx.jar and 5.5.7's
commons-logging-api.jar, it works.

Please correct the documentation (which is incorrect for Tomcat 5.5) and perhaps
include JMX.jar with the latest distribution.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 22130] - Tomcat VM not shutdown successfull as jk2 JMX handler is active

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=22130


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WONTFIX




--- Additional Comments From [EMAIL PROTECTED]  2004-12-22 21:22 ---
As of November 15, 2004, JK2 is no longer supported. All bugs related to JK2 
will be marked as WONTFIX. In its place, some of its features have been 
backported to jk1. Most of those features will be seen in 1.2.7, which is 
slated for release on November 30th, 2004.

Another alternative is the ajp addition to mod_proxy which will be part of 
apache 2.

For more information on the Tomat connectors docs at
http://jakarta.apache.org/tomcat/connectors-doc/


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: JMX Remote connection

[Jess Holle]

Costin Manolache wrote:
Jess Holle wrote:
In general the same-user, same-machine stuff works great (including 
with Tomcat 5) if you specify

   -Dcom.sun.management.jmxremote
as part of the command line.
Again - remember not everyone is using Sun JDK1.5 implementation.
My understanding is Macs don't have 1.5 yet, neither most other 
platforms.
Sorry.  Windows, Solaris, and Linux do, and HPUX will soon.
AIX and Mac OS X will lag as always, though if recent history is any 
guide AIX will lag further than Mac OS X.

--
Jess Holle
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: JMX Remote connection

[Costin Manolache]

Jess Holle wrote:
In general the same-user, same-machine stuff works great (including with 
Tomcat 5) if you specify

   -Dcom.sun.management.jmxremote
as part of the command line.
Again - remember not everyone is using Sun JDK1.5 implementation.
My understanding is Macs don't have 1.5 yet, neither most other platforms.

This is without any special web app or such.
What I really want to see is a nice bit of code that allows you to fire 
up a JMX RMI connector that:

   * Finds the first free port in a range (e.g. assuming you have a
 number of slave processes, this does not apply to Tomcat as it
 does not have such logic for it AJP port, etc).
   * Support user/password and SSL
   * Does not rely on implementation internals, i.e. requiring Java 5
 is fine, but having hooks into sun.* or MX4J or whatever classes
 is no good
That's not hard to add. You actually need the first free port in the 
range for rmiregistry - or you can use existing rmiregistry if one is 
found.

You need different rmi names - that's easier.
Adding user/pass/ssl is not hard - if someone has the itch it shouldn't 
be a problem. javax.man.remote has all that's needed AFAIK. IF you look 
at jmxremote webapp that I checked in - there is no mx4j or sun code, 
just plain javax.

Costin


--
Jess Holle
Remy Maucherat wrote:
Dominik Drzewiecki wrote:

I couldn't get the attach to process thing to work, though (= 
without a port). Is it supposed to be doable ?


Neither have I (I am talking of tomcat running as Windows service). 
It seems that both processes : tomcat JVM and jconsole JVM have to be 
owned by the same user. Maybe that is the case with you? Hovewer, 
starting tomcat from my system account solves the problem.
For more info see:
http://java.sun.com/j2se/1.5.0/docs/guide/management/jconsole.html


Both jconsole and the application must by executed by the same user 
name. The management and monitoring system uses the operating 
system's file permissions.


I'm running both with the same usename on Windows, and it doesn't 
work. Since it's Windows and I like to be able to do stuff, I of 
course run with root privileges. Seems to me it would work on Unix, 
but is currently broken on Windows (I use XP pro SP 2), or something. 
Over a TCP port, it works good.

I couldn't find a comprehensive guide on all these nice system 
properties, while there's tons of docs on the new command line commands.

If I use the service, which runs with the SYSTEM account, it of course 
doesn't work any better ;)

Rémy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: JMX Remote connection

[Jess Holle]

Remy Maucherat wrote:
For those interested in not wasting their time the way I just did, I 
just found this: 
http://java.sun.com/j2se/1.5.0/docs/guide/management/agent.html


*Limitation*: On Windows, for security reasons, local monitoring and 
management is only supported if your default Windows temporary 
directory is on a file system that supports persistent access control 
lists (for example, on an NTFS file system). It is not supported on a 
FAT file system that provide insufficient access controls.


I obviously use FAT32, and I have to add that this limitation is quite 
stupid. No multi user setup would run FAT and expect security, so you 
are fine allowing anything you want on FAT (at least, I can't see how 
it makes stuff more secure). 
Ah...
All my file systems are NTFS...
--
Jess Holle
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: JMX Remote connection

[Jess Holle]

In general the same-user, same-machine stuff works great (including with 
Tomcat 5) if you specify

   -Dcom.sun.management.jmxremote
as part of the command line.
This is without any special web app or such.
What I really want to see is a nice bit of code that allows you to fire 
up a JMX RMI connector that:

   * Finds the first free port in a range (e.g. assuming you have a
 number of slave processes, this does not apply to Tomcat as it
 does not have such logic for it AJP port, etc).
   * Support user/password and SSL
   * Does not rely on implementation internals, i.e. requiring Java 5
 is fine, but having hooks into sun.* or MX4J or whatever classes
 is no good
--
Jess Holle
Remy Maucherat wrote:
Dominik Drzewiecki wrote:

I couldn't get the attach to process thing to work, though (= 
without a port). Is it supposed to be doable ?

Neither have I (I am talking of tomcat running as Windows service). 
It seems that both processes : tomcat JVM and jconsole JVM have to be 
owned by the same user. Maybe that is the case with you? Hovewer, 
starting tomcat from my system account solves the problem.
For more info see:
http://java.sun.com/j2se/1.5.0/docs/guide/management/jconsole.html


Both jconsole and the application must by executed by the same user 
name. The management and monitoring system uses the operating 
system's file permissions.


I'm running both with the same usename on Windows, and it doesn't 
work. Since it's Windows and I like to be able to do stuff, I of 
course run with root privileges. Seems to me it would work on Unix, 
but is currently broken on Windows (I use XP pro SP 2), or something. 
Over a TCP port, it works good.

I couldn't find a comprehensive guide on all these nice system 
properties, while there's tons of docs on the new command line commands.

If I use the service, which runs with the SYSTEM account, it of course 
doesn't work any better ;)

Rémy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: JMX Remote connection

[Remy Maucherat]

Remy Maucherat wrote:
Dominik Drzewiecki wrote:

I couldn't get the attach to process thing to work, though (= 
without a port). Is it supposed to be doable ?

Neither have I (I am talking of tomcat running as Windows service). 
It seems that both processes : tomcat JVM and jconsole JVM have to be 
owned by the same user. Maybe that is the case with you? Hovewer, 
starting tomcat from my system account solves the problem.
For more info see:
http://java.sun.com/j2se/1.5.0/docs/guide/management/jconsole.html


Both jconsole and the application must by executed by the same user 
name. The management and monitoring system uses the operating 
system's file permissions.


I'm running both with the same usename on Windows, and it doesn't 
work. Since it's Windows and I like to be able to do stuff, I of 
course run with root privileges. Seems to me it would work on Unix, 
but is currently broken on Windows (I use XP pro SP 2), or something. 
Over a TCP port, it works good.

I couldn't find a comprehensive guide on all these nice system 
properties, while there's tons of docs on the new command line commands.

If I use the service, which runs with the SYSTEM account, it of course 
doesn't work any better ;)
For those interested in not wasting their time the way I just did, I 
just found this: 
http://java.sun.com/j2se/1.5.0/docs/guide/management/agent.html


*Limitation*: On Windows, for security reasons, local monitoring and 
management is only supported if your default Windows temporary directory 
is on a file system that supports persistent access control lists (for 
example, on an NTFS file system). It is not supported on a FAT file 
system that provide insufficient access controls.


I obviously use FAT32, and I have to add that this limitation is quite 
stupid. No multi user setup would run FAT and expect security, so you 
are fine allowing anything you want on FAT (at least, I can't see how it 
makes stuff more secure).

Rémy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: JMX Remote connection

[Remy Maucherat]

Dominik Drzewiecki wrote:

I couldn't get the attach to process thing to work, though (= without 
a port). Is it supposed to be doable ?

Neither have I (I am talking of tomcat running as Windows service). It 
seems that both processes : tomcat JVM and jconsole JVM have to be 
owned by the same user. Maybe that is the case with you? Hovewer, 
starting tomcat from my system account solves the problem.
For more info see:
http://java.sun.com/j2se/1.5.0/docs/guide/management/jconsole.html


Both jconsole and the application must by executed by the same user 
name. The management and monitoring system uses the operating system's 
file permissions.

I'm running both with the same usename on Windows, and it doesn't work. 
Since it's Windows and I like to be able to do stuff, I of course run 
with root privileges. Seems to me it would work on Unix, but is 
currently broken on Windows (I use XP pro SP 2), or something. Over a 
TCP port, it works good.

I couldn't find a comprehensive guide on all these nice system 
properties, while there's tons of docs on the new command line commands.

If I use the service, which runs with the SYSTEM account, it of course 
doesn't work any better ;)

Rémy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: JMX Remote connection

[Remy Maucherat]

Costin Manolache wrote:
No, removing jk2.properties - and removing JkMX - is a good thing.
I'll check in the webapp code, it's easier to talk about code - if 
people don't like it, feel free to -1 :-)
In the same spirit, I think we could imagine having a webapp for dynamic 
configuration of java logging.

Rémy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: JMX Remote connection

[Dominik Drzewiecki]

I couldn't get the attach to process thing to work, though (= without a 
port). Is it supposed to be doable ?
Neither have I (I am talking of tomcat running as Windows service). It 
seems that both processes : tomcat JVM and jconsole JVM have to be owned 
by the same user. Maybe that is the case with you? Hovewer, starting 
tomcat from my system account solves the problem.
For more info see:
http://java.sun.com/j2se/1.5.0/docs/guide/management/jconsole.html


Both jconsole and the application must by executed by the same user 
name. The management and monitoring system uses the operating system's 
file permissions.


This reminds me of the bug I noticed while I was trying to get it work.
It is impossible to select another account to run tomcat from within the 
tomcat service control. Will report it in bugzilla in a jiffie ;)

cheers,
/dd
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: JMX Remote connection

[Remy Maucherat]

Costin Manolache wrote:
Remy Maucherat wrote:
Dominik Drzewiecki wrote:

Why don't we dump the JkMX and just settle for the facilities 
provided by Java 5 configurable via standard system properties: 
-Dcom.sun.management.jmxremote alone for local JVM monioring

or
-Dcom.sun.management.jmxremote
-Dcom.sun.management.jmxremote.port=8004
-Dcom.sun.management.jmxremote.ssl=false
-Dcom.sun.management.jmxremote.authenticate=false
for remote machine monitoring.

Because they don't work with JDK1.4, and any people (including me) 
can't switch to Java5 since it breaks too much :-)
What are you talking about, it works great ;)
The option you mention are in fact the same thing with the webapp I'm 
suggesting - they have the effect of loading the standard 
javax.management.remote connector. The difference is that jx.m.r is 
using the standard API and will work with any JMX implementation, while
"com.sun" is specific to sun's implementation of jmx.
Right, the exact parameter will be proprietary. However, every VM will 
have to provide a JMX remote implementation, and I think it's rather 
obvious there will be some way to enable it with some option or config file.

I checked both myself with jconsole shipped with Java 5. It works 
like a charm (apart from increased CPU Load on the machine the 
jconsole runs).
MC4J 1.2 B5 has no problems with attaching to remote JVM either, 
hovewer it has some issues with mbeans provided by JVM, MC4J folks 
are aware of.

The bottomline is: consider dumping o.a.jk.c.JkMX (I know, I know 
there is number of users wishing to run tomcat on JVM <1.5)
 

Your post motivated me for trying jconsole, and I have to say it's 
really good.
Yes, jconsole is the reason I wrote the app too. Plus the fact that 
mx4j2.0 no longer works with jkmx ( they dumped the connector beans from
distribution since they now support the standard jx.m.r )
I couldn't get the attach to process thing to work, though (= without a 
port). Is it supposed to be doable ?


As others have said, the problem with JkJMX is that it's annoying to 
keep it up to date. And when we had it up to date, the JMX client was 
then rarely up to date. So I'll let you guys decide what do do, but 
it's sort of obvious the need for that kind of stuff is a lot smaller 
than what it used to be for Tomcat 5.5.

Note: the main reason why I removed jk2.properties is because is has 
a very confusing name (again referring to mod_jk2); if it's really 
needed, then it should be renamed, or an alternate name should be 
allowed.

No, removing jk2.properties - and removing JkMX - is a good thing.
I'll check in the webapp code, it's easier to talk about code - if 
people don't like it, feel free to -1 :-)
+1 for that webapp. Actually, we should include it in the "compat" 
package, since that package is for JDK 1.4.

Rémy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: JMX Remote connection

[Costin Manolache]

Remy Maucherat wrote:
Dominik Drzewiecki wrote:

Why don't we dump the JkMX and just settle for the facilities provided 
by Java 5 configurable via standard system properties: 
-Dcom.sun.management.jmxremote alone for local JVM monioring

or
-Dcom.sun.management.jmxremote
-Dcom.sun.management.jmxremote.port=8004
-Dcom.sun.management.jmxremote.ssl=false
-Dcom.sun.management.jmxremote.authenticate=false
for remote machine monitoring.
Because they don't work with JDK1.4, and any people (including me) can't 
switch to Java5 since it breaks too much :-)

The option you mention are in fact the same thing with the webapp I'm 
suggesting - they have the effect of loading the standard 
javax.management.remote connector. The difference is that jx.m.r is 
using the standard API and will work with any JMX implementation, while
"com.sun" is specific to sun's implementation of jmx.


I checked both myself with jconsole shipped with Java 5. It works like 
a charm (apart from increased CPU Load on the machine the jconsole runs).
MC4J 1.2 B5 has no problems with attaching to remote JVM either, 
hovewer it has some issues with mbeans provided by JVM, MC4J folks are 
aware of.

The bottomline is: consider dumping o.a.jk.c.JkMX (I know, I know 
there is number of users wishing to run tomcat on JVM <1.5)
 

Your post motivated me for trying jconsole, and I have to say it's 
really good.
Yes, jconsole is the reason I wrote the app too. Plus the fact that 
mx4j2.0 no longer works with jkmx ( they dumped the connector beans from
distribution since they now support the standard jx.m.r )

As others have said, the problem with JkJMX is that it's annoying to 
keep it up to date. And when we had it up to date, the JMX client was 
then rarely up to date. So I'll let you guys decide what do do, but it's 
sort of obvious the need for that kind of stuff is a lot smaller than 
what it used to be for Tomcat 5.5.

Note: the main reason why I removed jk2.properties is because is has a 
very confusing name (again referring to mod_jk2); if it's really needed, 
then it should be renamed, or an alternate name should be allowed.
No, removing jk2.properties - and removing JkMX - is a good thing.
I'll check in the webapp code, it's easier to talk about code - if 
people don't like it, feel free to -1 :-)

Costin
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: JMX Remote connection

[Remy Maucherat]

Dominik Drzewiecki wrote:
Hi,
Not sure what's the new policy for loading the Jmx RMI connector. 
jk2.properties was a hack - and now that it is removed, I was 
wandering if 
we have any "official" mechanism.

 

At the moment, jk2.properties is still used (we're just not shipping the 

default one).  It should be possible to configure JkMX via Connector 
attributes.

   

I had a small class that hooked in the connector, and I now refactored 
it 
to a webapp - nothing fancy ( it's not even "trusted" ), only loads 
rmiregistry and the jmx connector. I can check it in if there's no 
other
mechanism, it's very helpfull ( especially with JDK1.4/MX4j - in 5.0 
there 
are the cli options )
 

Why don't we dump the JkMX and just settle for the facilities provided by 
Java 5 configurable via standard system properties: 
-Dcom.sun.management.jmxremote alone for local JVM monioring

or
-Dcom.sun.management.jmxremote
-Dcom.sun.management.jmxremote.port=8004
-Dcom.sun.management.jmxremote.ssl=false
-Dcom.sun.management.jmxremote.authenticate=false
for remote machine monitoring.
I checked both myself with jconsole shipped with Java 5. It works like a 
charm (apart from increased CPU Load on the machine the jconsole runs).
MC4J 1.2 B5 has no problems with attaching to remote JVM either, hovewer it 
has some issues with mbeans provided by JVM, MC4J folks are aware of.

The bottomline is: consider dumping o.a.jk.c.JkMX (I know, I know there is 
number of users wishing to run tomcat on JVM <1.5)
 

Your post motivated me for trying jconsole, and I have to say it's 
really good.

As others have said, the problem with JkJMX is that it's annoying to 
keep it up to date. And when we had it up to date, the JMX client was 
then rarely up to date. So I'll let you guys decide what do do, but it's 
sort of obvious the need for that kind of stuff is a lot smaller than 
what it used to be for Tomcat 5.5.

Note: the main reason why I removed jk2.properties is because is has a 
very confusing name (again referring to mod_jk2); if it's really needed, 
then it should be renamed, or an alternate name should be allowed.

Rémy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: JMX Remote connection

[Dominik Drzewiecki]

>> Hi,
>> 
>> Not sure what's the new policy for loading the Jmx RMI connector. 
>> jk2.properties was a hack - and now that it is removed, I was 
>> wandering if 
>> we have any "official" mechanism.
>> 
> 
> At the moment, jk2.properties is still used (we're just not shipping the 
> 
> default one).  It should be possible to configure JkMX via Connector 
> attributes.
> 
>> I had a small class that hooked in the connector, and I now refactored 
>> it 
>> to a webapp - nothing fancy ( it's not even "trusted" ), only loads 
>> rmiregistry and the jmx connector. I can check it in if there's no 
>> other
>> mechanism, it's very helpfull ( especially with JDK1.4/MX4j - in 5.0 
>> there 
>> are the cli options )

Why don't we dump the JkMX and just settle for the facilities provided by 
Java 5 configurable via standard system properties: 
-Dcom.sun.management.jmxremote alone for local JVM monioring

or
-Dcom.sun.management.jmxremote
-Dcom.sun.management.jmxremote.port=8004
-Dcom.sun.management.jmxremote.ssl=false
-Dcom.sun.management.jmxremote.authenticate=false
for remote machine monitoring.

I checked both myself with jconsole shipped with Java 5. It works like a 
charm (apart from increased CPU Load on the machine the jconsole runs).
MC4J 1.2 B5 has no problems with attaching to remote JVM either, hovewer it 
has some issues with mbeans provided by JVM, MC4J folks are aware of.

The bottomline is: consider dumping o.a.jk.c.JkMX (I know, I know there is 
number of users wishing to run tomcat on JVM <1.5)

cheers,
/dd


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: JMX Remote connection

[Bill Barker]

- Original Message - 
From: "Costin Manolache" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, October 05, 2004 10:47 PM
Subject: Re: JMX Remote connection


Bill Barker wrote:
- Original Message - From: "Costin Manolache" 
<[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, October 05, 2004 10:06 PM
Subject: JMX Remote connection


Hi,
Not sure what's the new policy for loading the Jmx RMI connector. 
jk2.properties was a hack - and now that it is removed, I was wandering 
if we have any "official" mechanism.

At the moment, jk2.properties is still used (we're just not shipping the 
default one).  It should be possible to configure JkMX via Connector 
attributes.
I thought JkMX only supports the "old style" connector - not the new 
javax.management.remote, and since jk2.properties is being deprecated I
assumed JkMX will go as well, or at least move to a higher level.

Yup.  There isn't anything for javax.management.remote (other than the 
standard options in 1.5).

The code in JkMX seems very specific to mx4j - and I couldn't get it 
working with mx4j2.0, the package name changed ( mx4j.adapter.rmi -> 
mx4j.remote.rmi ) and the mechanism didn't seem to work.

The mx4j.remote.rmi isn't included in the bin distro anymore (the source 
file is there, but deprecated).

Can we at least add the JMXConnectionServerFactory as another special case 
? A separate webapp seemed cleaner.

It's a pain to do via reflection.  The webapp does seem cleaner.
Costin


I had a small class that hooked in the connector, and I now refactored 
it to a webapp - nothing fancy ( it's not even "trusted" ), only loads 
rmiregistry and the jmx connector. I can check it in if there's no other
mechanism, it's very helpfull ( especially with JDK1.4/MX4j - in 5.0 
there are the cli options )

Costin
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



This message is intended only for the use of the person(s) listed above 
as the intended recipient(s), and may contain information that is 
PRIVILEGED and CONFIDENTIAL.  If you are not an intended recipient, you 
may not read, copy, or distribute this message or any attachment. If you 
received this communication in error, please notify us immediately by 
e-mail and then delete all copies of this message and any attachments.

In addition you should be aware that ordinary (unencrypted) e-mail sent 
through the Internet is not secure. Do not send confidential or sensitive 
information, such as social security numbers, account numbers, personal 
identification numbers and passwords, to us via ordinary (unencrypted) 
e-mail.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



This message is intended only for the use of the person(s) listed above as the 
intended recipient(s), and may contain information that is PRIVILEGED and 
CONFIDENTIAL.  If you are not an intended recipient, you may not read, copy, or 
distribute this message or any attachment. If you received this communication in 
error, please notify us immediately by e-mail and then delete all copies of this 
message and any attachments.

In addition you should be aware that ordinary (unencrypted) e-mail sent through the 
Internet is not secure. Do not send confidential or sensitive information, such as 
social security numbers, account numbers, personal identification numbers and 
passwords, to us via ordinary (unencrypted) e-mail.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: JMX Remote connection

[Costin Manolache]

Bill Barker wrote:
- Original Message - From: "Costin Manolache" 
<[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, October 05, 2004 10:06 PM
Subject: JMX Remote connection


Hi,
Not sure what's the new policy for loading the Jmx RMI connector. 
jk2.properties was a hack - and now that it is removed, I was 
wandering if we have any "official" mechanism.

At the moment, jk2.properties is still used (we're just not shipping the 
default one).  It should be possible to configure JkMX via Connector 
attributes.
I thought JkMX only supports the "old style" connector - not the new 
javax.management.remote, and since jk2.properties is being deprecated I
assumed JkMX will go as well, or at least move to a higher level.

The code in JkMX seems very specific to mx4j - and I couldn't get it 
working with mx4j2.0, the package name changed ( mx4j.adapter.rmi -> 
mx4j.remote.rmi ) and the mechanism didn't seem to work.

Can we at least add the JMXConnectionServerFactory as another special 
case ? A separate webapp seemed cleaner.

Costin


I had a small class that hooked in the connector, and I now refactored 
it to a webapp - nothing fancy ( it's not even "trusted" ), only loads 
rmiregistry and the jmx connector. I can check it in if there's no other
mechanism, it's very helpfull ( especially with JDK1.4/MX4j - in 5.0 
there are the cli options )

Costin
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



This message is intended only for the use of the person(s) listed above as the 
intended recipient(s), and may contain information that is PRIVILEGED and 
CONFIDENTIAL.  If you are not an intended recipient, you may not read, copy, or 
distribute this message or any attachment. If you received this communication in 
error, please notify us immediately by e-mail and then delete all copies of this 
message and any attachments.
In addition you should be aware that ordinary (unencrypted) e-mail sent through the 
Internet is not secure. Do not send confidential or sensitive information, such as 
social security numbers, account numbers, personal identification numbers and 
passwords, to us via ordinary (unencrypted) e-mail.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: JMX Remote connection

[Bill Barker]

- Original Message - 
From: "Costin Manolache" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, October 05, 2004 10:06 PM
Subject: JMX Remote connection


Hi,
Not sure what's the new policy for loading the Jmx RMI connector. 
jk2.properties was a hack - and now that it is removed, I was wandering if 
we have any "official" mechanism.

At the moment, jk2.properties is still used (we're just not shipping the 
default one).  It should be possible to configure JkMX via Connector 
attributes.

I had a small class that hooked in the connector, and I now refactored it 
to a webapp - nothing fancy ( it's not even "trusted" ), only loads 
rmiregistry and the jmx connector. I can check it in if there's no other
mechanism, it's very helpfull ( especially with JDK1.4/MX4j - in 5.0 there 
are the cli options )

Costin
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



This message is intended only for the use of the person(s) listed above as the 
intended recipient(s), and may contain information that is PRIVILEGED and 
CONFIDENTIAL.  If you are not an intended recipient, you may not read, copy, or 
distribute this message or any attachment. If you received this communication in 
error, please notify us immediately by e-mail and then delete all copies of this 
message and any attachments.

In addition you should be aware that ordinary (unencrypted) e-mail sent through the 
Internet is not secure. Do not send confidential or sensitive information, such as 
social security numbers, account numbers, personal identification numbers and 
passwords, to us via ordinary (unencrypted) e-mail.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

JMX Remote connection

[Costin Manolache]

Hi,
Not sure what's the new policy for loading the Jmx RMI connector. 
jk2.properties was a hack - and now that it is removed, I was wandering 
if we have any "official" mechanism.

I had a small class that hooked in the connector, and I now refactored 
it to a webapp - nothing fancy ( it's not even "trusted" ), only loads 
rmiregistry and the jmx connector. I can check it in if there's no other
mechanism, it's very helpfull ( especially with JDK1.4/MX4j - in 5.0 
there are the cli options )

Costin
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Monitoring different Contexts with JMX MBean

[Stefan Fleiter]

This is a message I already posted to tomcat-user, but did not get any 
answer to.

I would be really thankful for any hint or direction where to get the 
needed information.

Hi,
I try to do my first steps with the java server platform and have chosen 
Tomcat for this.

I wrote a class which is able to Monitor the database pools of a Context
when beeing called out of it.
I only had to use JNDI to iterate over "comp/env/jdbc" and cast the 
DataSource instances to a BasicDataSource.

Now I want to implement an MBean which is able to monitor the pools of 
all Contexts of Tomcat.

I even don't know whether this is possible, but hope to get some help.
Now my concrete questions:
 - Can I somehow change the Context my code is executed in?
 - If not: How do I get instances of all JNDI DataSource for all
   Contexts ?
 - Where do I have to put my MBean .class-files?
   In the webapps dir or somewhere else?
 - How can I make Tomcat register my MBeans at startup?
Thanks a lot in advance,
Stefan
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

JMX

[Sebastien Brunot]

Hi,

 

How do you enable remote access to the JMX Server by RMI in Tomcat 4.1.30 ?

I'd like to access a custom MBean, which i register to the Tomcat JMX Server
in my webapp, via RMI.

 

I asked this question to the user mailing list, but without success. I hope
that somebody here will be able to help me. 

 

Thanks,

 

Sebastien

 

RFE: Basic auth jmx http adapter

[Rainer Jung]

Hi,

I append a small patch, including the necessary features to support basic
and digest authentication for the mx4j JMX http connector.

The way the http adaptor is initialized in JkMX.java today gives no
possibility to restrict access to it. Since the JMX console is very
powerful
I included code n JkMx.java to parse 3 additional configuration options
from jk2.properties to the connector:

mx.authMode
mx.authUser
mx.authPassword

The patch is very local and simple. It is based on the newest version of
JkMX.java. Thank for considering.

Rainer Jung

% diff -w -c JkMX.java.orig JkMX.java
*** JkMX.java.orig  Thu Jun 17 21:03:20 2004
--- JkMX.java   Sun Aug 29 14:16:35 2004
***
*** 39,44 
--- 39,47 
  private boolean enabled=false;
  private int httpport=-1;
  private String httphost="localhost";
+ private String authmode="none";
+ private String authuser=null;
+ private String authpassword=null;
  private int jrmpport=-1;
  private String jrmphost="localhost";
  private boolean useXSLTProcessor = true;
***
*** 86,91 
--- 89,118 
  return httphost;
  }
  
+ public void setAuthMode(String mode) {
+ authmode=mode;
+ }
+ 
+ public String getAuthMode() {
+ return authmode;
+ }
+ 
+ public void setAuthUser(String user) {
+ authuser=user;
+ }
+ 
+ public String getAuthUser() {
+ return authuser;
+ }
+ 
+ public void setAuthPassword(String password) {
+ authpassword=password;
+ }
+ 
+ public String getAuthPassword() {
+ return authpassword;
+ }
+ 
  /** Enable the MX4J JRMP internal adapter
   */
  public void setJrmpPort( int i ) {
***
*** 162,167 
--- 189,205 
  mserver.setAttribute(httpServerName, new Attribute("Host", 
httphost));
  mserver.setAttribute(httpServerName, new Attribute("Port", new 
Integer(httpport)));
  
+ if( authmode!=null  && ( "none".equals(authmode) || 
"basic".equals(authmode) || "digest".equals(authmode) ) )
+ mserver.setAttribute(httpServerName, new 
Attribute("AuthenticationMethod", authmode));
+ 
+ if( authuser!=null && authpassword!=null )
+ mserver.invoke(httpServerName, "addAuthorization",
+ new Object[] {
+ authuser,
+ authpassword},
+ new String[] { "java.lang.String", "java.lang.String" });
+ 
+ 
  if(useXSLTProcessor) {
  ObjectName processorName = 
registerObject("mx4j.tools.adaptor.http.XSLTProcessor",
"Http:name=XSLTProcessor");
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Documentation hint: getting rid of JMX HTTP adaptor errors

[Rainer Jung]

Hi,

using TC 5.0.27 together with the jmx http adaptor coming with mx4j 2.0.1
there are still error messages and missing data in the resulting html
pages. The errors disappear when using xalan 2.6.0. The release Notes for
J2SDK 1.4.2_05 say, that Sun still bundles 2.4.1+. Maybe that's worth a
hint either in the release notes, or in the doc, where the parameter
mx.enabled in jk2.properties is explained.

The error messages are:

SystemId Unknown; Line #12; Column #81; Cannot add attribute name after
child nodes or before an element is produced.  Attribute will be ignored.

produced when accessing the default page /serverbydomain (and the domain
name is missing in the result page) and

SystemId Unknown; Line #14; Column #80; Cannot add attribute objectname
after child nodes or before an element is produced.  Attribute will be
ignored.
SystemId Unknown; Line #14; Column #80; Cannot add attribute description
after child nodes or before an element is produced.  Attribute will be
ignored.
 when accessing /mbean.xml (and objectnme and description of the mbean is
mising).

All error messages disappear when using xanlan 2.6.0. I checked by putting
xalan.jar from the 2.6.0 distribution to the endorsed directory of tomcat.
Furthermore the previously missing data now is included in the result
pages.

Thanks for considerung

Rainer Jung



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 30537] - Tomcat 5.0.25 does not support JMX 1.2

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=30537>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=30537

Tomcat 5.0.25 does not support JMX 1.2

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2004-08-09 09:44 ---
Use another JMX implementation then.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 30537] New: - Tomcat 5.0.25 does not support JMX 1.2

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=30537>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=30537

Tomcat 5.0.25 does not support JMX 1.2

   Summary: Tomcat 5.0.25 does not support JMX 1.2
   Product: Tomcat 5
   Version: 5.0.25
  Platform: All
OS/Version: All
Status: NEW
  Severity: Major
  Priority: Other
 Component: Unknown
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


The jmx.jar located in %CATALINA_HOME%/bin does not implement the JMX 1.2 
specification. MBeanServer interface does not support 'getClassLoader()' 
or 'getClassLoaderRepository()'.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

JMX and tomcat

[Don Hill]

Hi,


How would I use JMX/tomcat to get a handle on the realm and be able to
call methods like authenticate(). I know I can get a realm but I
believe its not writeable. I was trying to use the ServerFactory but
it seems I get a classnotfound exception, are the container
classloader not a child of the server ?




Any thought or suggestions




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Tomcat and JMX (JRMP)!

[Remy Maucherat]

Slobodan Vujasinovic wrote:
I'm member of 'Enhydra Development Team' and we are currently developing
Application Server (Enhydra-Lite) based on Tomcat5.0.
I'm developing a side tool (EnTray - system tray administration tool (used
for starting/stopping server actions, accessing deployed applications, etc))
that communicates with Tomcat (its MBeanServer) using JMX and gathers
information from/about registered MBeans.

As I understood Tomcat 5.0.x offers possibility of "Complete server
monitoring using JMX and the manager web application" which is OK (I
downloaded "jmx.browser-1.2.0" application from Source Forge which enabled
me to se all registered MBeans).

But, I need to establish communication with Tomcat thru rmi/jrmp protocol
(from diferent virtual mashine).
I stumbled upon some configuration parameters on JK2 Home Page (
http://jakarta.apache.org/tomcat/tomcat-4.1-doc/jk2/jk2/configweb.html).
Parameters are:  mx.enable, mx.httpPort, mx.httpHost, mxjrmpPort (probably
typing error, I assume mx.jrmpHost is meant to be here) and mx.jrmpPort.
After integration of "mx4j" (2.0.1 release) into Tomcat I had no problems
with communication thro HTTP, but JRMP could not be initialized because
class "mx4j.adaptor.rmi.jrmp.JRMPAdaptor" was not found (probably some older
mx4j implementation - in new versions this class is placed in
"mx4j.tools.adaptor.rmi.jrmp" package). I even stumbled, on tomcat users
mailing list, on some additional configuration parameters (!!???) that
enable configuration of Adapter classes that are going to be initialized
(mx.mx4jHttpAdaptorClassName and mx.mx4jJRMPAdaptorClassName), but that
didn't work eider.
After, repackaging of "JRMPAdaptor" (from "mx4j.adaptor.rmi.jrmp" to
"mx4j.tools.adaptor.rmi.jrmp") I've succeeded to establish communication
between "EnTray" and Tomcat, and everything looked just fine - until I tried
to shutdown the server.
I've got "Stoping JMX" log on console and server could not finish shutdown
process.
To resolve this problem I had to take a look at Tomcats source code
(downloaded actual release 5.0.27) and found class of my interest
("org.apache.jk.common.JkMX" - placed in 'jakarta-tomcat-connectors'
module).
Problem was in "destroy()" method where You are trying to stop
"jrmpServerName" ("mx4j.tools.naming.NamingService") and not
actually initialized "adaptor" ("mx4j.adaptor.rmi.jrmp.JRMPAdaptor").
Fatherly, I' ve changed JRMAdaptor initialization (in the same class) by
adding "mx4j.tools.adaptor.rmi.jrmp.JRMPAdaptor" (latest implementation of
mx4j) implementation option ("mx4j.tools.adaptor.http.HttpAdaptor" and
"mx4j.adaptor.http.HttpAdaptor" options already existed there).

I'm sending adapted JkMX.java file ("org.apache.jk.common.JkMX"
implementation) and I hope that You will be so kind to consider those
changes and to include them in next Tomcat release (I understand that "This
is very experimental" - but is the matter of great importance to me).
 

We got more elegant code contributed already.
http://issues.apache.org/bugzilla/show_bug.cgi?id=29259
I expect that code will be included in 5.0.x eventually. OTOH, JMX 
server startup code shouldn't be in the connector code, so it'll be 
removed from JK.

Rémy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Tomcat and JMX (JRMP)!

[Slobodan Vujasinovic]

I'm member of 'Enhydra Development Team' and we are currently developing
Application Server (Enhydra-Lite) based on Tomcat5.0.

I'm developing a side tool (EnTray - system tray administration tool (used
for starting/stopping server actions, accessing deployed applications, etc))
that communicates with Tomcat (its MBeanServer) using JMX and gathers
information from/about registered MBeans.



As I understood Tomcat 5.0.x offers possibility of "Complete server
monitoring using JMX and the manager web application" which is OK (I
downloaded "jmx.browser-1.2.0" application from Source Forge which enabled
me to se all registered MBeans).



But, I need to establish communication with Tomcat thru rmi/jrmp protocol
(from diferent virtual mashine).

I stumbled upon some configuration parameters on JK2 Home Page (
http://jakarta.apache.org/tomcat/tomcat-4.1-doc/jk2/jk2/configweb.html).

Parameters are:  mx.enable, mx.httpPort, mx.httpHost, mxjrmpPort (probably
typing error, I assume mx.jrmpHost is meant to be here) and mx.jrmpPort.

After integration of "mx4j" (2.0.1 release) into Tomcat I had no problems
with communication thro HTTP, but JRMP could not be initialized because
class "mx4j.adaptor.rmi.jrmp.JRMPAdaptor" was not found (probably some older
mx4j implementation - in new versions this class is placed in
"mx4j.tools.adaptor.rmi.jrmp" package). I even stumbled, on tomcat users
mailing list, on some additional configuration parameters (!!???) that
enable configuration of Adapter classes that are going to be initialized
(mx.mx4jHttpAdaptorClassName and mx.mx4jJRMPAdaptorClassName), but that
didn't work eider.

After, repackaging of "JRMPAdaptor" (from "mx4j.adaptor.rmi.jrmp" to
"mx4j.tools.adaptor.rmi.jrmp") I've succeeded to establish communication
between "EnTray" and Tomcat, and everything looked just fine - until I tried
to shutdown the server.

I've got "Stoping JMX" log on console and server could not finish shutdown
process.

To resolve this problem I had to take a look at Tomcats source code
(downloaded actual release 5.0.27) and found class of my interest
("org.apache.jk.common.JkMX" - placed in 'jakarta-tomcat-connectors'
module).

Problem was in "destroy()" method where You are trying to stop
"jrmpServerName" ("mx4j.tools.naming.NamingService") and not

actually initialized "adaptor" ("mx4j.adaptor.rmi.jrmp.JRMPAdaptor").

Fatherly, I' ve changed JRMAdaptor initialization (in the same class) by
adding "mx4j.tools.adaptor.rmi.jrmp.JRMPAdaptor" (latest implementation of
mx4j) implementation option ("mx4j.tools.adaptor.http.HttpAdaptor" and
"mx4j.adaptor.http.HttpAdaptor" options already existed there).



I'm sending adapted JkMX.java file ("org.apache.jk.common.JkMX"
implementation) and I hope that You will be so kind to consider those
changes and to include them in next Tomcat release (I understand that "This
is very experimental" - but is the matter of great importance to me).



Regards,

Slobodan Vujasinovic

Enhydra Development Team


/*
 *  Copyright 1999-2004 The Apache Software Foundation
 *
 *  Licensed under the Apache License, Version 2.0 (the "License");
 *  you may not use this file except in compliance with the License.
 *  You may obtain a copy of the License at
 *
 *  http://www.apache.org/licenses/LICENSE-2.0
 *
 *  Unless required by applicable law or agreed to in writing, software
 *  distributed under the License is distributed on an "AS IS" BASIS,
 *  WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 *  See the License for the specific language governing permissions and
 *  limitations under the License.
 */

package org.apache.jk.common;


import org.apache.jk.core.JkHandler;

import javax.management.MBeanServer;
import javax.management.ObjectName;
import javax.management.Attribute;
import javax.management.MBeanServerFactory;
import java.io.IOException;

/**
 * Load the HTTP or RMI adapters for MX4J and JMXRI.
 *
 * Add "mx.enabled=true" in jk2.properties to enable it.
 * You could also select http and/or jrmp protocol, 
 * with mx.httpPort, mx.httpHost, mxjrmpPort and mx.jrmpPort
 *
 */
public class JkMX extends JkHandler
{
MBeanServer mserver;
private boolean enabled=false;
private int httpport=-1;
private String httphost="localhost";
private int jrmpport=-1;
private String jrmphost="localhost";
private boolean useXSLTProcessor = true;

public JkMX() {
}

/*  Public methods  */

/** Enable the MX4J adapters (new way)
 */
public void setEnabled(boolean b) {
enabled=b;
}

public boolean getEnabled() {
return enabled;

Re: jmx memory leak ?

[Bill Barker]

@see BZ #28321

- Original Message -
From: "Ludovic Drolez" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, April 23, 2004 9:18 AM
Subject: jmx memory leak ?


> Hi !
>
>
> We are currently using Tomcat 5.0.19. With simple servlets, we found that
> memory usage was continuously increasing, until a fatal OutOfMemory
exception.
>
> Using HPjmeter the only object which seems to keep growing seems to be an
> ArrayList created by a RequestGroupInfo object:
>
>Java stack -> [EMAIL PROTECTED] (120 bytes)
>  notifInfo -> [EMAIL PROTECTED]
(16
> bytes)
>   tpOName -> [EMAIL PROTECTED] (32 bytes)
> sSocket -> [EMAIL PROTECTED] (24 bytes)
>   tp -> [EMAIL PROTECTED]
> (56 bytes) (1280 held)
>   inet -> [EMAIL PROTECTED] (24 bytes)
> mserver -> [EMAIL PROTECTED] (40 bytes)
>   oname -> [EMAIL PROTECTED] (32 bytes)
> domain -> [EMAIL PROTECTED] (24 bytes)
>   name -> [EMAIL PROTECTED] (24 bytes)
> next ->
> [EMAIL PROTECTED] (80 bytes)
>  global -> [EMAIL PROTECTED] (16 bytes)
>  processors -> [EMAIL PROTECTED] (24 bytes)
> (1 611 200 held)
>elementData -> [EMAIL PROTECTED] (112 bytes) (1
611
> 176 held)
>
>
> JMX is not enabled and this bug seems to be jmx related...(But if i remove
> jmx.jar I cannot start tomcat5)
> Does someone knows why the arraylist is so big and keeps growing ?
>
>
> TIA,
> --
> Ludovic DROLEZ  Linbox / Free&ALter Soft
> 152 rue de Grigy - Technopole Metz 2000   57070 METZ
> tel : 03 87 50 87 90fax : 03 87 75 19 26
>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>


This message is intended only for the use of the person(s) listed above as the 
intended recipient(s), and may contain information that is PRIVILEGED and 
CONFIDENTIAL.  If you are not an intended recipient, you may not read, copy, or 
distribute this message or any attachment. If you received this communication in 
error, please notify us immediately by e-mail and then delete all copies of this 
message and any attachments.

In addition you should be aware that ordinary (unencrypted) e-mail sent through the 
Internet is not secure. Do not send confidential or sensitive information, such as 
social security numbers, account numbers, personal identification numbers and 
passwords, to us via ordinary (unencrypted) e-mail.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

jmx memory leak ?

[Ludovic Drolez]

Hi !


We are currently using Tomcat 5.0.19. With simple servlets, we found that
memory usage was continuously increasing, until a fatal OutOfMemory exception.

Using HPjmeter the only object which seems to keep growing seems to be an
ArrayList created by a RequestGroupInfo object:

   Java stack -> [EMAIL PROTECTED] (120 bytes)
 notifInfo -> [EMAIL PROTECTED] (16
bytes)
  tpOName -> [EMAIL PROTECTED] (32 bytes)
sSocket -> [EMAIL PROTECTED] (24 bytes)
  tp -> [EMAIL PROTECTED]
(56 bytes) (1280 held)
  inet -> [EMAIL PROTECTED] (24 bytes)
mserver -> [EMAIL PROTECTED] (40 bytes)
  oname -> [EMAIL PROTECTED] (32 bytes)
domain -> [EMAIL PROTECTED] (24 bytes)
  name -> [EMAIL PROTECTED] (24 bytes)
next ->
[EMAIL PROTECTED] (80 bytes)
 global -> [EMAIL PROTECTED] (16 bytes)
 processors -> [EMAIL PROTECTED] (24 bytes)
(1 611 200 held)
   elementData -> [EMAIL PROTECTED] (112 bytes) (1 611
176 held)


JMX is not enabled and this bug seems to be jmx related...(But if i remove
jmx.jar I cannot start tomcat5)
Does someone knows why the arraylist is so big and keeps growing ?


TIA, 
-- 
Ludovic DROLEZ  Linbox / Free&ALter Soft
152 rue de Grigy - Technopole Metz 2000   57070 METZ
tel : 03 87 50 87 90fax : 03 87 75 19 26



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [5.0] JMX 1.2

[Mark Thomas]

Remy,

Any further thoughts on this now the licencing issues appear to be resolved?
Just thinking about how to fix bug 28178.

Mark

> From: Remy Maucherat [mailto:[EMAIL PROTECTED] 
> 
> Amy Roh wrote:
> > Hi Remy,
> > 
> > JSR 160 will go final in October (assuming the final ballot 
> passes, as 
> > seems very likely).  At that stage the RI will be released under 
> > essentially the same licensing terms as the JMX RI.  So 
> yes, Tomcat will 
> > be able to use it.
> 
> Ok, so I won't bundle the binary until then.
> 
> I need to write code to replace the MX4J connector setup which is in 
> ServerLifecycleListener and MBeanUtils. I'll implement that as a 
> separate lifecycle listener.
> 
> Remy



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 27894] - jmx throws exception if TC installation path contains spaces

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=27894>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=27894

jmx throws exception if TC installation path contains spaces

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WONTFIX



--- Additional Comments From [EMAIL PROTECTED]  2004-03-24 09:25 ---
Honestly, this is not worth fixing, since the workaround is simple enough.
To get JMX remote support, use JDK 1.5.0 (I found out the support was
outstanding, and decided as a result that it was not worth spending time on this
- wise decision, since we would not have been able to actually ship the result
anyway).

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 27894] New: - jmx throws exception if TC installation path contains spaces

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=27894>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=27894

jmx throws exception if TC installation path contains spaces

   Summary: jmx throws exception if TC installation path contains
spaces
   Product: Tomcat 5
   Version: 5.0.19
  Platform: PC
OS/Version: Windows XP
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Unknown
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


I tried to run TC 5.0.19 with mx4j-1.1.1 and mc4j-1.2beta4.

As I read in http://mc4j.sourceforge.net/usageTomcat.html that the JMX RI (JSR
160) in tomcat is still not working I followed the instructions given there to
use mx4j 1.1.1.

Whenever I install tomcat to a path that contains spaces (e.g. the default
"C:\...\Apache Software Foundation\Tomcat 5.0") I get the following exception at
startup:

--snip
24.03.2004 08:57:00 org.apache.jk.common.JkMX loadAdapter
SCHWERWIEGEND: MX4j RMI adapter not loaded: javax.management.MBeanException:
nested exception is javax.naming.CommunicationException [Root exception is
java.rmi.ServerException: RemoteException occurred in server thread; nested
exception is:
java.rmi.UnmarshalException: error unmarshalling arguments; nested
exception is:
java.net.MalformedURLException: no protocol: Software]
24.03.2004 08:57:00 org.apache.jk.common.JkMX loadAdapter WARNUNG: No adaptors
were loaded but mx.enabled was defined.
--snap

When move the TC homedir to a path that does NOT contain spaces, anything works
fine!!

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [PROPOSAL] Re: Tomcat5 MBeans/JMX context creation

[Shapira, Yoav]

Hi,

>Proposed object names for the classloaders:
>
>Main CLs:
>[Server]:type=ServerClassLoader,name=(common|shared|server)
>Webapps CLs:
>[EngineName]:type=WebappClassLoader,path=[context_path],host=[host_name
]
>
>I am likely to move jmx.jar to "bin", since bootstrap will need to
>register the CLs it creates. The good thing is that this way all JDKs
>will have JMX in the classpath, like JDK 1.5 has.
>
>Once this "minor" issue is cleared out, this should all work.
>
>Any comments on this ?

Even though you've already done and committed this, I still wanted to +1
it.  Getting the JMX behavior under JDK 1.4 to be much closer to 1.5 is
a significant enhancement.  Thanks, as always ;)

Yoav Shapira



This e-mail, including any attachments, is a confidential business communication, and 
may contain information that is confidential, proprietary and/or privileged.  This 
e-mail is intended only for the individual(s) to whom it is addressed, and may not be 
saved, copied, printed, disclosed or used by anyone else.  If you are not the(an) 
intended recipient, please immediately delete this e-mail from your computer system 
and notify the sender.  Thank you.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [PROPOSAL] Re: Tomcat5 MBeans/JMX context creation

[Remy Maucherat]

Remy Maucherat wrote:
Any comments on this ?
All done. The changes are not too intrusive, since TC 5 already required 
JMX.
This should hopefully make Tomcat useable through JMX remote on JDK 1.5 
(which was my plan, if you remember my emails a few weeks ago).

The object name to use in most cases is 
Catalina:type=ServerClassLoader,name=server (the object name is mostly 
hardcoded)

The webapp CLs are also registered, which is not as useful. If some 
webapps are JMX aware, this could be used to instantiate their MBeans 
remotely.
Example object name: Catalina:type=WebappClassLoader,path=/,host=localhost

Rémy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[PROPOSAL] Re: Tomcat5 MBeans/JMX context creation

[Remy Maucherat]

Randy Watler wrote:

Remy Maucherat wrote:


Randy Watler wrote:


I am currently experimenting with the Java 1.5 remote JMX/MBeans for 
use in our build process.
...
Can anyone clarify how the "createStandardContext" should be invoked?


You can look at the JBoss integration code for examples.
...
There's additional code, but this is for creating a basic context, and 
configuring its classloader. The Tomcat code which allows doing this 
is a lot more recent than the harcoded admin webapp methods, and is 
more JavaBean like.


Remy,

Note that I am using the JMX remote "Out-of-the-box" Java 1.5 Monitoring 
and Management, so some of the JBoss setup may not apply, (like the 
ClassLoader configuration that passes object instances). Here is what I 
am trying:

// create context
mbeanServer.createMBean( "org.apache.commons.modeler.BaseModelMBean", 
context,
 new Object [] { 
"org.apache.catalina.core.StandardContext" },
 new String [] { "java.lang.String" } ) ;
mbeanServer.setAttribute( context, new Attribute( "docBase", 
"/tmp/testsite" ) ) ;
mbeanServer.setAttribute( context, new Attribute( "path", "/testsite" ) ) ;


> Unfortunately, the createMBean call above throws the following exception:
>
> javax.management.ReflectionException: The MBean class could not be
> loaded by the default loader repository
> at
> 
com.sun.jmx.mbeanserver.MBeanInstantiatorImpl.findClassWithDefaultLoaderRepo
> sitory(MBeanInstantiatorImpl.java:61)
> at
> 
com.sun.jmx.mbeanserver.MBeanInstantiatorImpl.instantiate(MBeanInstantiatorI
> mpl.java:378)
> at
> 
com.sun.jmx.mbeanserver.JmxMBeanServer.instantiate(JmxMBeanServer.java:1011)
> at
> 
com.sun.jmx.remote.security.MBeanServerAccessController.createMBean(MBeanSer
> verAccessController.java:167)
> at
> 
javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.
> java:1418)
> at
> 
javax.management.remote.rmi.RMIConnectionImpl.access+100(RMIConnectionImpl.j
> ava:81)
> at
> 
javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMICon
> nectionImpl.java:1301)
> at java.security.AccessController.doPrivileged(Native Method)
> at
> 
javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConne
> ctionImpl.java:1395)
> at
etc, etc

This makes sense to me perhaps because the JVM does not understand the 
Tomcat5 ClassLoader hierarchy and cannot load 
org.apache.commons.modeler.BaseModelMBean, no? Consequently, I am 
guessing that I am not going to be able to create new MBeans without 
doing so via existing registered MBeans? Am I missing something that 
should be obvious? Perhaps Tomcat can register its own "loader 
repository" somehow?
Well, ok, there's a problem.

You have to use that form of createBean, otherwise it's not going to 
work:  ObjectInstance createMBean(String className, ObjectName name, 
ObjectName loaderName, Object[] params, String[] signature)

The problem is that right now the CL aren't registered in JMX. Woops. 
Better luck next release, I guess ;) (I think I had written somewhere 
that the JMX stuff was "not done yet")

To address this issue, the classloaders used and created by Tomcat 
standalone should be registered with JMX.
The registration will take place:
- in ClassLoaderFactory for the standard classloaders (common, shared 
and server)
- in WebappLoader for the webapp classloaders (the loaders are already 
registered)
To avoid dependencies on the rest of the world (commons-*), the 
StandardClassLoader MBean will be a standard MBean (not too hard: no 
attributes or operations are needed).
The webapp classloader only needs an entry in mbeans-descriptors.

Proposed object names for the classloaders:

Main CLs:
[Server]:type=ServerClassLoader,name=(common|shared|server)
Webapps CLs:
[EngineName]:type=WebappClassLoader,path=[context_path],host=[host_name]
I am likely to move jmx.jar to "bin", since bootstrap will need to 
register the CLs it creates. The good thing is that this way all JDKs 
will have JMX in the classpath, like JDK 1.5 has.

Once this "minor" issue is cleared out, this should all work.

Any comments on this ?

Rémy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: TC 3.3.2 and JMX

[Henri Gomez]

Henri Gomez wrote:

Bill Barker wrote:

- Original Message -
From: "Henri Gomez" <[EMAIL PROTECTED]>
To: "Tomcat Developers List" <[EMAIL PROTECTED]>
Sent: Wednesday, February 25, 2004 4:50 AM
Subject: TC 3.3.2 and JMX


Any objection to set the default JMX port to -1 ?



None here.  Jk-Coyote is now the default, and it's connector support is
better.


Ok, I'll commit tomorrow
Bill was faster

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: TC 3.3.2 and JMX

[Henri Gomez]

Bill Barker wrote:

- Original Message -
From: "Henri Gomez" <[EMAIL PROTECTED]>
To: "Tomcat Developers List" <[EMAIL PROTECTED]>
Sent: Wednesday, February 25, 2004 4:50 AM
Subject: TC 3.3.2 and JMX


Any objection to set the default JMX port to -1 ?



None here.  Jk-Coyote is now the default, and it's connector support is
better.
Ok, I'll commit tomorrow

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: TC 3.3.2 and JMX

[Bill Barker]

- Original Message -
From: "Henri Gomez" <[EMAIL PROTECTED]>
To: "Tomcat Developers List" <[EMAIL PROTECTED]>
Sent: Wednesday, February 25, 2004 4:50 AM
Subject: TC 3.3.2 and JMX


> Any objection to set the default JMX port to -1 ?
>

None here.  Jk-Coyote is now the default, and it's connector support is
better.

> >>>> - As many, in my web application,  I allready load HTTP/JRMP
connector
> >>>>  (at special ports with custom login/pwd), but since JMXSupport is
> >>>>  loaded before my app, it didn't use my HTTP port settings.
> >>>>
> >>>>  What about set port to -1 by default in interceptors.xml to avoid
> >>>>  such problems ?
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>


This message is intended only for the use of the person(s) listed above as the 
intended recipient(s), and may contain information that is PRIVILEGED and 
CONFIDENTIAL.  If you are not an intended recipient, you may not read, copy, or 
distribute this message or any attachment. If you received this communication in 
error, please notify us immediately by e-mail and then delete all copies of this 
message and any attachments.

In addition you should be aware that ordinary (unencrypted) e-mail sent through the 
Internet is not secure. Do not send confidential or sensitive information, such as 
social security numbers, account numbers, personal identification numbers and 
passwords, to us via ordinary (unencrypted) e-mail.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

TC 3.3.2 and JMX

[Henri Gomez]

Any objection to set the default JMX port to -1 ?

- As many, in my web application,  I allready load HTTP/JRMP connector
 (at special ports with custom login/pwd), but since JMXSupport is
 loaded before my app, it didn't use my HTTP port settings.
 What about set port to -1 by default in interceptors.xml to avoid
 such problems ?


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: JMX remote and JDK 1.5

[Remy Maucherat]

[EMAIL PROTECTED] wrote:
Remy Maucherat wrote:

What does it mean ? 
I saw the 1.5 jmx stuff, but as usual this only works with 1.5 while most
people will keep using 1.3 or 1.4 for few years. I hope we're not falling
into the forced upgrade trap :-)
I agree in general. However, I've played with the beta, and it basically 
feels like 1.4.3, with the added language features. I didn't test the 
stability in production, of course, but it looks good so far. I do not 
think we'll end up in a situation like with Java 1.4 when:
- coders didn't want to use the new APIs since they weren't stable and 
tested (NIO)
- people didn't want to upgrade as the JVM itself wasn't stable

I agree that tomcat should't reinvent the wheel - but provide some mechanism
for 1.4, maybe similar ( or identical ) with what 1.5 provides. This would
also allow people with 1.3 or 1.4 to enjoy JMX now. 
I'm talking about JMX remote here. AFAIK, no clients support it right 
now. JDK 1.5 will make it a standard in a hurry, given that you don't 
have to configure or add anything in the application itself. Given that 
there's already support for the other JMX remoting connectors in Tomcat, 
I don't see the need to add something which will only become used once 
JDK 1.5 is out. Now, if someone feels like adding it, I won't complain, 
but I won't do it myself ;)

Rémy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: JMX remote and JDK 1.5

[cmanolache]

Remy Maucherat wrote:

> Hi,
> 
> It looks like the new JDK has an easy way to add a connector (and even
> SNMP) to a VM, without the need for explicit support in the application,
> using system properties (on the command line) like:
> - com.sun.management.config.file
> - com.sun.management.snmp.port
> - com.sun.management.jmxremote.port
> I expect other vendors will provide a similar feature :)
> 
> As a result, there's no need to reinvent the wheel inside Tomcat, and
> I'm shelving my plans to add a listener to instantiate JMX remote (no
> need to add complexity), and will unbundle JMX remote (only the JMX RI
> core will be bundled); instead, I'll add a little chapter about JMX in
> the docs :)

What does it mean ? 
I saw the 1.5 jmx stuff, but as usual this only works with 1.5 while most
people will keep using 1.3 or 1.4 for few years. I hope we're not falling
into the forced upgrade trap :-)

I agree that tomcat should't reinvent the wheel - but provide some mechanism
for 1.4, maybe similar ( or identical ) with what 1.5 provides. This would
also allow people with 1.3 or 1.4 to enjoy JMX now. 

Costin



> 
> With this JDK, JMX remote powered clients are going to become a standard
> almost instantly, since the only requirement is that the server is
> instrumented though JMX. So good job to the J2SE team, this doesn't seem
> beta (although they didn't test JBoss, it doesn't work right now, as a
> side effect of bundling JMX :-( ).
> 
> On the performance side, my (client) VM seems as fast as JDK 1.4.2, but
> does seem to use a little bit less memory. So unless it turns out to be
> really unstable (it does seem better than almost all the other Sun JDKs
> I've tried, so far), final 1.5.0 should be really successful when it's
> released.
> 
> Rémy



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

JMX remote and JDK 1.5

[Remy Maucherat]

Hi,

It looks like the new JDK has an easy way to add a connector (and even 
SNMP) to a VM, without the need for explicit support in the application, 
using system properties (on the command line) like:
- com.sun.management.config.file
- com.sun.management.snmp.port
- com.sun.management.jmxremote.port
I expect other vendors will provide a similar feature :)

As a result, there's no need to reinvent the wheel inside Tomcat, and 
I'm shelving my plans to add a listener to instantiate JMX remote (no 
need to add complexity), and will unbundle JMX remote (only the JMX RI 
core will be bundled); instead, I'll add a little chapter about JMX in 
the docs :)

With this JDK, JMX remote powered clients are going to become a standard 
almost instantly, since the only requirement is that the server is 
instrumented though JMX. So good job to the J2SE team, this doesn't seem 
beta (although they didn't test JBoss, it doesn't work right now, as a 
side effect of bundling JMX :-( ).

On the performance side, my (client) VM seems as fast as JDK 1.4.2, but 
does seem to use a little bit less memory. So unless it turns out to be 
really unstable (it does seem better than almost all the other Sun JDKs 
I've tried, so far), final 1.5.0 should be really successful when it's 
released.

Rémy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: embedded tomcat and JMX sample code

[Remy Maucherat]

Mark W. Webb wrote:
I am looking for some sample code that will demonstrate how to embed 
tomcat in a java application using JMX.  I would like to write some 
documentation on how to do this, as there is none that exists that I 
have found on tomcat's web site.  I would imagine that there must be 
some code somewhere that was used for testing the new infrastructure.

Everywhere I have turned so far, has told me to look at the JBoss source 
code, but I figure that the tomcat development team must have some code 
laying around that will demonstrate this.
The Ant script in the embed distribution can directly be translated into 
JMX commands. Other than that, we have no Java JMX code (so look in the 
JBoss/Tomcat integration for that).

Rémy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

embedded tomcat and JMX sample code

[Mark W. Webb]

I am looking for some sample code that will demonstrate how to embed 
tomcat in a java application using JMX.  I would like to write some 
documentation on how to do this, as there is none that exists that I 
have found on tomcat's web site.  I would imagine that there must be 
some code somewhere that was used for testing the new infrastructure.

Everywhere I have turned so far, has told me to look at the JBoss source 
code, but I figure that the tomcat development team must have some code 
laying around that will demonstrate this.

thank you for your time.
Mark
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 22130] - Tomcat VM not shutdown successfull as jk2 JMX handler is active

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22130>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22130

Tomcat VM not shutdown successfull as jk2 JMX handler is active





--- Additional Comments From [EMAIL PROTECTED]  2004-01-25 21:44 ---
The source of the problem is probably the RMI registry that is being created by 
the mx4j RMIAdapter. There is actually a non-daemon thread, the "RMI Reaper" 
thread:

"RMI Reaper" prio=5 tid=0x8e89bd0 nid=0x8b4 waiting on monitor 
[0x9b1f000..0x9b1fdb8]
at java.lang.Object.wait(Native Method)
at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:103)
at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:118)
at sun.rmi.transport.ObjectTable$Reaper.run(ObjectTable.java:279)
at java.lang.Thread.run(Thread.java:479)

The RMIAdapter should stop the NamingService, this should eliminate the 
deadlock.

Btw: I got mx4j running with the following properties in jk.properties:

mx.enabled=true
mx.jrmpPort=1099
mx.jrmpHost=localhost

Others mentioned mx.port=9000 which leads to total confusion. I used Tomcat 
4.1.29 and mx4j 1.1.1.

Anybody thinks to be in charge of this problem? Is there a release plan for 
4.1.30?

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: JMX 1.2 / JMX Remote 1.0

[Simon Clare]

Weird, I will try a tomcat build with the JMX 1.2.1 jar (jmxri.jar) i'm using outside 
a web container and see what happens (probably something horrific). If it works do you 
want to know about it?

In theory if you have JMX 1.2.1 then the remote stuff should just work 

ho hum.

-s

-- Original Message --
From: Remy Maucherat <[EMAIL PROTECTED]>
Reply-To: "Tomcat Developers List" <[EMAIL PROTECTED]>
Date: Wed, 21 Jan 2004 16:58:28 +0100

>Robert Krüger wrote:
>> Simon,
>>
>> I think you're right. I observerd the same. I downloaded and built
>> Tomcat 5 from CVS using the build.xml file provided on the website 3
>> days ago and the file jakarta-tomcat-5/build/common/lib/jmx.jar does not
>> contain the JMX 1.2 classes. In my case my code broke because
>> Monitor.addObserverdObject is not there (was added in 1.2). To make sure
>> I checked in the class file and it is not there.
>
>I am bundling the JAR from the JMX RI 1.2.1.
>As for JMX Remote, I plan to add support for it in the next release.
>
>Rémy
>
>
>-
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
>
>


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: JMX 1.2 / JMX Remote 1.0

[Remy Maucherat]

Robert Krüger wrote:
Simon,

I think you're right. I observerd the same. I downloaded and built 
Tomcat 5 from CVS using the build.xml file provided on the website 3 
days ago and the file jakarta-tomcat-5/build/common/lib/jmx.jar does not 
contain the JMX 1.2 classes. In my case my code broke because 
Monitor.addObserverdObject is not there (was added in 1.2). To make sure 
I checked in the class file and it is not there.
I am bundling the JAR from the JMX RI 1.2.1.
As for JMX Remote, I plan to add support for it in the next release.
Rémy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: JMX 1.2 / JMX Remote 1.0

[Robert Krüger]

Simon,

I think you're right. I observerd the same. I downloaded and built 
Tomcat 5 from CVS using the build.xml file provided on the website 3 
days ago and the file jakarta-tomcat-5/build/common/lib/jmx.jar does not 
contain the JMX 1.2 classes. In my case my code broke because 
Monitor.addObserverdObject is not there (was added in 1.2). To make sure 
I checked in the class file and it is not there.

Regards,

Robert

Simon Clare wrote:

Hi

This is probably:
a: stupid
b: annoying 

or possibly both but i'm having a bit of a problem with JMX specs in Tomcat. Am I right in thinking that JMX 1.2.1 RI is the current version within Tomcat 5 (http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24413)? 

However, the reference implementation (and spec) has the method:
javax.management.MBeanServer.getClassLoaderRepository()
But the JMX implementation bundled with Tomcat (5.016) does not (and throws a noSuchMethodException when I try and use it. 

My small mind has been throw into confusion, and I am contemplating Classpath order based hacks (shudder). 

simon clare

FULL (AND BORING) DETAILS

I'm connecting remotely to a JMX 1.2.1 RI JMX Server using the JMX 1.0 Remote RI and querying a few MBeans. This works a treat in a stand alone "vanilla" VM. However, inside a web container (weblogic and tomcat) where there is theortically all the JMX stuff allready there (minus the remote stuff) the same code does not work, it throws a NoSuchMethodException on javax.management.MBeanServer.getClassLoaderRepository(). Which is weird as this method should be there according to the JMX 1.2.1 spec. 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--

Robert Krüger
Signal7 GmbH
Brüder Knauss Str. 79
64285 Darmstadt
Germany
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

JMX 1.2 / JMX Remote 1.0

[Simon Clare]

Hi

This is probably:
a: stupid
b: annoying 

or possibly both but i'm having a bit of a problem with JMX specs in Tomcat. Am I 
right in thinking that JMX 1.2.1 RI is the current version within Tomcat 5 
(http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24413)? 

However, the reference implementation (and spec) has the method:
javax.management.MBeanServer.getClassLoaderRepository()
But the JMX implementation bundled with Tomcat (5.016) does not (and throws a 
noSuchMethodException when I try and use it. 

My small mind has been throw into confusion, and I am contemplating Classpath order 
based hacks (shudder). 

simon clare

FULL (AND BORING) DETAILS

I'm connecting remotely to a JMX 1.2.1 RI JMX Server using the JMX 1.0 Remote RI and 
querying a few MBeans. This works a treat in a stand alone "vanilla" VM. However, 
inside a web container (weblogic and tomcat) where there is theortically all the JMX 
stuff allready there (minus the remote stuff) the same code does not work, it throws a 
NoSuchMethodException on javax.management.MBeanServer.getClassLoaderRepository(). 
Which is weird as this method should be there according to the JMX 1.2.1 spec. 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: JMX JRMP rmi registry port configuration

[Kevin Pfarr]

The option mx.jrmpPort is used for registering the JRMPAdaptor to the 
NamingService, by setting the PROVIDER_URL.  When the NamingService is 
regeristered it creates the rmi registry whiCh defaults to 1099.

The code below will show what I mean about setting the port on the rmi 
registry.  The code below is from the class org.apache.jk.common.JkMX.


jrmpServerName = new ObjectName("Naming:name=rmiregistry");
mserver.createMBean("mx4j.tools.naming.NamingService", jrmpServerName, 
null);

// new line to set the rmi registry port to 1199
server.setAttribute(naming, new Attribute("Port", new Integer("1199")));
mserver.invoke(jrmpServerName, "start", null, null);
log.info( "Creating " + jrmpServerName );

-Kevin

Bill Barker wrote:
- Original Message - 
From: "Kevin Pfarr" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, January 08, 2004 2:55 PM
Subject: JMX JRMP rmi registry port configuration



When JMX is enabled, in the jk2.properties file, and configured to use 
the MX4J JRMP interal adapter, a rmi registry is created and bound to 
the default port of 1099.  If there is another application using that 
port and bind expection is thrown and the adaptor is never enabled.

A configuration option for the rmi registry port would sovle this 
problem.  A setter for port does exist on the 
mx4j.tools.naming.NamingService object.

The lastest source for org.apache.jk.common.JkMX does not have this 
feature, and would be the place to incorporate it.


Actually, it does have this feature already.  The option you want is:
  mx.jrmpPort=
This is my first post to the mailing list and have been a long time user 
of Tomcat.

-Kevin

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL.  If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments.

In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail.





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Kevin Pfarr  Software Engineer
PN:   314.678.2231
FX:   314.436.2559
CELL: 314.629.6255
[EMAIL PROTECTED]
Asynchrony Solutions, Inc.
1709 Washington Avenue // Suite 200
Saint Louis, Missouri 63103
www.asolutions.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: JMX JRMP rmi registry port configuration

[Bill Barker]

- Original Message - 
From: "Kevin Pfarr" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, January 08, 2004 2:55 PM
Subject: JMX JRMP rmi registry port configuration


> 
> When JMX is enabled, in the jk2.properties file, and configured to use 
> the MX4J JRMP interal adapter, a rmi registry is created and bound to 
> the default port of 1099.  If there is another application using that 
> port and bind expection is thrown and the adaptor is never enabled.
> 
> A configuration option for the rmi registry port would sovle this 
> problem.  A setter for port does exist on the 
> mx4j.tools.naming.NamingService object.
> 
> The lastest source for org.apache.jk.common.JkMX does not have this 
> feature, and would be the place to incorporate it.


Actually, it does have this feature already.  The option you want is:
  mx.jrmpPort=

> 
> This is my first post to the mailing list and have been a long time user 
> of Tomcat.
> 
> -Kevin
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 


This message is intended only for the use of the person(s) listed above as the 
intended recipient(s), and may contain information that is PRIVILEGED and 
CONFIDENTIAL.  If you are not an intended recipient, you may not read, copy, or 
distribute this message or any attachment. If you received this communication in 
error, please notify us immediately by e-mail and then delete all copies of this 
message and any attachments.

In addition you should be aware that ordinary (unencrypted) e-mail sent through the 
Internet is not secure. Do not send confidential or sensitive information, such as 
social security numbers, account numbers, personal identification numbers and 
passwords, to us via ordinary (unencrypted) e-mail.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

JMX JRMP rmi registry port configuration

[Kevin Pfarr]

When JMX is enabled, in the jk2.properties file, and configured to use 
the MX4J JRMP interal adapter, a rmi registry is created and bound to 
the default port of 1099.  If there is another application using that 
port and bind expection is thrown and the adaptor is never enabled.

A configuration option for the rmi registry port would sovle this 
problem.  A setter for port does exist on the 
mx4j.tools.naming.NamingService object.

The lastest source for org.apache.jk.common.JkMX does not have this 
feature, and would be the place to incorporate it.

This is my first post to the mailing list and have been a long time user 
of Tomcat.

-Kevin

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 24413] - bundled JMX implementation not compliant to specification

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24413>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24413

bundled JMX implementation not compliant to specification

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|VERIFIED



--- Additional Comments From [EMAIL PROTECTED]  2003-11-05 19:49 ---
I have downloaded the latest zip for Tomcat 5.0.14 and the problem no longer 
exists. The problem I was facing (with an earlier downloaded version of Tomcat 
5.0.12) was that role of getter and setter was not supported.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 24413] - bundled JMX implementation not compliant to specification

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24413>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24413

bundled JMX implementation not compliant to specification

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2003-11-05 08:18 ---
The implementation bundled is the JMX RI 1.2.1, and it has been working fine for me.
I don't understand the issue you are reporting. Please restate.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 24413] New: - bundled JMX implementation not compliant to specification

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24413>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24413

bundled JMX implementation not compliant to specification

   Summary: bundled JMX implementation not compliant to
specification
   Product: Tomcat 5
   Version: 5.0.12
  Platform: All
OS/Version: Other
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Webapps:Administration
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


The jmx.jar bundled with this verion, does not support values "getter" 
and "setter" for attribute "role" in ModelMBeanOperationInfo. The values that 
should be supported include "operation", "getter" and "setter". Please advise 
if any other version has a correct implementation.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 24250] - JMX ant task failed

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24250>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24250

JMX ant task failed

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2003-11-03 22:23 ---
I don't think I agree with this patch, so I've changed it:
- queryMBeans should never return a null Set (according to the JMX 1.2 Javadocs
- Tomcat 5 uses JMX 1.2)
- if there are no MBeans, this is not an error (the fact that there are zero
results should be displayed normally)

OTOH:
- Normalizing messages is *good* ("OK - " and "Error - "), and since the Ant
task is looking for that ...
- Removing e.printStackTrace is obviously good; I don't like the error handling
of this servlet, but maybe it is adapted to the task

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 24250] - JMX ant task failed

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24250>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24250

JMX ant task failed





--- Additional Comments From [EMAIL PROTECTED]  2003-10-30 14:26 ---
Created an attachment (id=8821)
JMXProxyServlet Patch for correct ant task handling

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 24250] New: - JMX ant task failed

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24250>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24250

JMX ant task failed

   Summary: JMX ant task failed
   Product: Tomcat 5
   Version: Nightly Build
  Platform: PC
OS/Version: Windows XP
Status: NEW
  Severity: Minor
  Priority: Other
 Component: Webapps:Manager
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Hups,

the JMX ant task failed when result is ok.
The JMXProxyServlet not send a correct status.

I fix it and add the Patch

Peter

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [5.0] JMX 1.2

[Remy Maucherat]

Amy Roh wrote:
Hi Remy,

JSR 160 will go final in October (assuming the final ballot passes, as 
seems very likely).  At that stage the RI will be released under 
essentially the same licensing terms as the JMX RI.  So yes, Tomcat will 
be able to use it.
Ok, so I won't bundle the binary until then.

I need to write code to replace the MX4J connector setup which is in 
ServerLifecycleListener and MBeanUtils. I'll implement that as a 
separate lifecycle listener.

Remy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [5.0] JMX 1.2

[Amy Roh]

Hi Remy,

JSR 160 will go final in October (assuming the final ballot passes, as 
seems very likely).  At that stage the RI will be released under 
essentially the same licensing terms as the JMX RI.  So yes, Tomcat will 
be able to use it.

Amy

Remy Maucherat wrote:
As discussed before, I'm going to package the JMX RI 1.2.1 with TC 5.0.x 
from now on (after testing, of course).
I'll leave MX4J part of the build process.

Q to the Sun folks: can I legally ship the JMX remote 1.0 RI binary with 
Tomcat ?

Remy


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[5.0] JMX 1.2

[Remy Maucherat]

As discussed before, I'm going to package the JMX RI 1.2.1 with TC 5.0.x 
from now on (after testing, of course).
I'll leave MX4J part of the build process.

Q to the Sun folks: can I legally ship the JMX remote 1.0 RI binary with 
Tomcat ?

Remy



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 22130] - Tomcat VM not shutdown successfull as jk2 JMX handler is active

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22130>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22130

Tomcat VM not shutdown successfull as jk2 JMX handler is active





--- Additional Comments From [EMAIL PROTECTED]  2003-08-05 12:04 ---
Maybe it is caused by mx4j's connectors using non-daemon threads. If you do a
thread dump (CTRL+BREAK on Windown, kill -3 on Unix), you can see which threads
are daemon, and which are not.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 22291] - Missing ant tasks for JMX proxy functionality

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22291>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22291

Missing ant tasks for JMX proxy functionality

[EMAIL PROTECTED] changed:

   What|Removed |Added

   Severity|Normal  |Enhancement
 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2003-08-11 09:07 ---
Thanks. The advantage of this is that it works without additional stuff. The
preffered way to interact with Tomcat through JMX is right now the various MX4J
connectors. Tomcat 5.0.x will be updated to JMX 1.2 and the remote JMX as soon
as they are available.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 22291] New: - Missing ant tasks for JMX proxy functionality

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22291>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22291

Missing ant tasks for JMX proxy functionality

   Summary: Missing ant tasks for JMX proxy functionality
   Product: Tomcat 5
   Version: 5.0.0
  Platform: Other
OS/Version: Other
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Unknown
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


The JMX proxy functionality in the Tomcat manager doesn't have ant tasks.

These are a bit awkward to use with the HTTP request format, so I wrote these 
and will be attaching the code to the bugzilla entry.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 22291] - Missing ant tasks for JMX proxy functionality

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22291>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22291

Missing ant tasks for JMX proxy functionality





--- Additional Comments From [EMAIL PROTECTED]  2003-08-11 07:03 ---
Created an attachment (id=7736)
The JMX Set task code

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 22291] - Missing ant tasks for JMX proxy functionality

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22291>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22291

Missing ant tasks for JMX proxy functionality





--- Additional Comments From [EMAIL PROTECTED]  2003-08-11 07:02 ---
Created an attachment (id=7735)
The JMX Query task code

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 22130] New: - Tomcat VM not shutdown successfull as jk2 JMX handler is active

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22130>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22130

Tomcat VM not shutdown successfull as jk2 JMX handler is active

   Summary: Tomcat VM not shutdown successfull as jk2 JMX handler is
active
   Product: Tomcat 4
   Version: 4.1.27
  Platform: PC
OS/Version: Windows XP
Status: NEW
  Severity: Critical
  Priority: Other
 Component: Connector:Coyote JK 2
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


I have configured at conf/jk2.properties (mx.port=9000). This starts
a mx4j Http and rmi JMX Apdator.

Tomcat Shutdown is not successful. All Tomcat Connector close but rmi and JMX 
Handler are not close. The Vm not exists.

I analysed that org.apache.jk.common.JkMX destroy() method not stop the MX4J 
Adaptors !

I see at start() this mserver.invoke(adaptor, "start", null,null) call.

Tested with 4.1.24, 4.1.27 and Tomcat 5 (5.0.3)



Peter

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Browse using MC4J (Re: [Novice] JMX / Tomcat 4.1.X)

[Davanum Srinivas]

For the record...Waz able to run MC4J (http://mc4j.sourceforge.net/) and JMX enabled 
stuff in
Tomcat 4.1.24.

Steps to setup MX4J (http://mx4j.sourceforge.net/) in Tomcat 4.1.24

#1: Edit jk2.properties and add a line "mx.port=9000"
#2: Edit server.xml, enable the Connector under "Coyote/JK2 AJP 1.3 Connector on port 
8009"
#3: Copy mx4j-tools.jar from your MX4J distribution and copy it to 
$CATALINA_HOME/server/lib
directory.
#4: Start using "catalina run" - makes it easy to look for any exceptions.
#5: go to your MC4J bin directory, start runide.exe
#6: Switch to the tab that says  "MC4J for MX4J"
#7: In the tree root node, right click and click on "Connect"
#8: Enter say tomcat4.1.24 in the wizard and click on finish.
#9: Expand the tree and browse the hierarchy.

Thanks,
dims

--- Davanum Srinivas <[EMAIL PROTECTED]> wrote:
> Hi folks,
> 
> 1. Is there some sample code that starts and stops a tomcat webapp via JMX?
> 2. Where is the actual implementation? (I get lost of the maze of tomcat modules).
> 
> Thanks,
> dims
> 
> =
> Davanum Srinivas - http://webservices.apache.org/~dims/
> 
> __
> Do you Yahoo!?
> SBC Yahoo! DSL - Now only $29.95 per month!
> http://sbc.yahoo.com
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 


=
Davanum Srinivas - http://webservices.apache.org/~dims/

__
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[Novice] JMX / Tomcat 4.1.X

[Davanum Srinivas]

Hi folks,

1. Is there some sample code that starts and stops a tomcat webapp via JMX?
2. Where is the actual implementation? (I get lost of the maze of tomcat modules).

Thanks,
dims

=
Davanum Srinivas - http://webservices.apache.org/~dims/

__
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: disable jmx option in tc5

[Costin Manolache]

Remy Maucherat wrote:

> Costin Manolache wrote:
>> Hmmm. We could use the "jsr77" option ( that is now in 4.1.x ) and
>> generate JSR77 names only if it is on.
>> 
>> Or we could just use the other kind of names allways - and have a
>> separate module that re-register the objects with JSR77 names ( if needed
>> ).
>> 
>> But the real issue is that a product shouldn't "handle JSR77 for
>> webmodules",  that's plain wrong. The mbeans for WebModule and Servlet
>> must be handled by tomcat - who is the one that knows when a servlet
>> or webmodule is instantiated  or removed or changes state, and can
>> provide usefull info ( statistics, etc ).
> 
> I completely agree, but the webmodule users don't agree, apparently. For
> example, the core JBoss folks insist that JBoss should be the one doing
> that JSR 77 stuff, for some reason, and that the web container should
> provide methods to access the stats (we do, so it's ok, I guess).


That's plain stupid IMO. 

Tomcat implements the servlet and webmodule - so most likely knows better
what's manageable inside and how to manage. Well - they'll probably loose
some features and dumb down the management of servlets and webmodules.

Not sure what you mean by "webmodule user" - I assume you're talking about
the JSR77 implementors. I can't see how a webmodule user would want the
webmodule managed by a third party entity instead of the servlet container. 


>> A product that creates some wrappers or dummy objects with JSR77 names
>> is useless - they'll have no real management value, since you would
>> manage the wrong components.
>> 
>> The EJB container should handle the JSR77 components that are related
>> with EJBs, and tomcat ( or whatever servlet implementation ) should
>> handle the JSR77 for its components.
>> 
>> ( jboss seems to be one case where jsr77 is implemented outside of the
>> servlet container ).
> 
> Indeed, and there's no change on the horizon.

That means we'll probably have to have a flag to disable jsr77.

It'll be ugly - since tomcat itself relies on the WebModule and Servlet to
be manageable and expose a number of attributes and control. 

Not sure how this will work - we basically need to be able to deal with dumb
WebModules wrappers and be able to located the real component somehow.

Costin


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: disable jmx option in tc5

[Remy Maucherat]

Costin Manolache wrote:
Hmmm. We could use the "jsr77" option ( that is now in 4.1.x ) and generate
JSR77 names only if it is on. 

Or we could just use the other kind of names allways - and have a separate
module that re-register the objects with JSR77 names ( if needed ).
But the real issue is that a product shouldn't "handle JSR77 for
webmodules",  that's plain wrong. The mbeans for WebModule and Servlet
must be handled by tomcat - who is the one that knows when a servlet 
or webmodule is instantiated  or removed or changes state, and can provide
usefull info ( statistics, etc ).
I completely agree, but the webmodule users don't agree, apparently. For 
example, the core JBoss folks insist that JBoss should be the one doing 
that JSR 77 stuff, for some reason, and that the web container should 
provide methods to access the stats (we do, so it's ok, I guess).

A product that creates some wrappers or dummy objects with JSR77 names 
is useless - they'll have no real management value, since you would manage
the wrong components. 

The EJB container should handle the JSR77 components that are related with 
EJBs, and tomcat ( or whatever servlet implementation ) should handle the 
JSR77 for its components.

( jboss seems to be one case where jsr77 is implemented outside of the 
servlet container ).
Indeed, and there's no change on the horizon.

Remy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: disable jmx option in tc5

[Amy Roh]

Costin Manolache wrote:
Amy Roh wrote:


Just out of curiosity, is there a simple way to disable jmx in tc5 other
than changing tomcat code to avoid registration/unregistration manually
which won't be trivial.


Just out of curiosity, why would you want to do this ?
I don't.  I was just thinking of different options to integrate tomcat
into a product that already handles jsr77 code for webmodules.  just
brain storming...


Hmmm. We could use the "jsr77" option ( that is now in 4.1.x ) and generate
JSR77 names only if it is on. 

Or we could just use the other kind of names allways - and have a separate
module that re-register the objects with JSR77 names ( if needed ).
But the real issue is that a product shouldn't "handle JSR77 for
webmodules",  that's plain wrong. The mbeans for WebModule and Servlet
must be handled by tomcat - who is the one that knows when a servlet 
or webmodule is instantiated  or removed or changes state, and can provide
usefull info ( statistics, etc ).
Yeah, I've already thought about the alternative.  It's not very pretty. 
 There can be lots of coordination problems. and it's missing the point.

BTW, how about that servlet unavilable error?  Were you able to figure 
out what's the problem?  Didn't see any commits on that.

A product that creates some wrappers or dummy objects with JSR77 names 
is useless - they'll have no real management value, since you would manage
the wrong components. 

The EJB container should handle the JSR77 components that are related with 
EJBs, and tomcat ( or whatever servlet implementation ) should handle the 
JSR77 for its components.

( jboss seems to be one case where jsr77 is implemented outside of the 
servlet container ).

Costin

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: disable jmx option in tc5

[Costin Manolache]

Amy Roh wrote:

>>>Just out of curiosity, is there a simple way to disable jmx in tc5 other
>>>than changing tomcat code to avoid registration/unregistration manually
>>>which won't be trivial.
>> 
>> 
>> Just out of curiosity, why would you want to do this ?
> 
> I don't.  I was just thinking of different options to integrate tomcat
> into a product that already handles jsr77 code for webmodules.  just
> brain storming...

Hmmm. We could use the "jsr77" option ( that is now in 4.1.x ) and generate
JSR77 names only if it is on. 

Or we could just use the other kind of names allways - and have a separate
module that re-register the objects with JSR77 names ( if needed ).

But the real issue is that a product shouldn't "handle JSR77 for
webmodules",  that's plain wrong. The mbeans for WebModule and Servlet
must be handled by tomcat - who is the one that knows when a servlet 
or webmodule is instantiated  or removed or changes state, and can provide
usefull info ( statistics, etc ).

A product that creates some wrappers or dummy objects with JSR77 names 
is useless - they'll have no real management value, since you would manage
the wrong components. 

The EJB container should handle the JSR77 components that are related with 
EJBs, and tomcat ( or whatever servlet implementation ) should handle the 
JSR77 for its components.

( jboss seems to be one case where jsr77 is implemented outside of the 
servlet container ).

Costin


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: disable jmx option in tc5

[Amy Roh]

Costin Manolache wrote:
Amy Roh wrote:


Just out of curiosity, is there a simple way to disable jmx in tc5 other
than changing tomcat code to avoid registration/unregistration manually
which won't be trivial.


Just out of curiosity, why would you want to do this ?
I don't.  I was just thinking of different options to integrate tomcat 
into a product that already handles jsr77 code for webmodules.  just 
brain storming...

The whole point of using ( and requiring ) JMX is to simplify the
model. I know that right now it doesn't look simpler, especially since
some pieces are broken - but things are getting consistent and at least
in my opinion they'll be much simpler in the end.
I couldn't agree more.

Thanks,
Amy
A lot of the complexity in the current JMX stuff is related with the
2 config models - we need to support server.xml and direct API calls for
backward compat.
Costin



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: disable jmx option in tc5

[Costin Manolache]

Amy Roh wrote:

> Just out of curiosity, is there a simple way to disable jmx in tc5 other
> than changing tomcat code to avoid registration/unregistration manually
> which won't be trivial.

Just out of curiosity, why would you want to do this ?

The whole point of using ( and requiring ) JMX is to simplify the
model. I know that right now it doesn't look simpler, especially since
some pieces are broken - but things are getting consistent and at least
in my opinion they'll be much simpler in the end.

A lot of the complexity in the current JMX stuff is related with the
2 config models - we need to support server.xml and direct API calls for
backward compat.

Costin



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: disable jmx option in tc5

[Remy Maucherat]

Amy Roh wrote:
Just out of curiosity, is there a simple way to disable jmx in tc5 other 
than changing tomcat code to avoid registration/unregistration manually 
which won't be trivial.
It had been decided that Tomcat 5 would require JMX, so it is not 
possible to disable it.

Remy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

disable jmx option in tc5

[Amy Roh]

Just out of curiosity, is there a simple way to disable jmx in tc5 other 
than changing tomcat code to avoid registration/unregistration manually 
which won't be trivial.

Thanks,
Amy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: TC5 JMX

[Amy Roh]

> Amy Roh wrote:
>
> >> I moved the valve registration in addValve().
> >
> > Cool.  I think logger and realm registration should be in setLogger and
> > setRealm as well so mbeans can get registered correctly.  Also,
> > deregistration for old mbean should happen when new logger or realm is
> > null.
>
> +1 :-)
>
> For the second part - deregistration should happen on stop().
>
> If you are going to implement this ( please ! ), don't worry about the
> embed use case, I'll fix it if there are problems.

So you haven't done logger/realm registration/deregistration?  I would hate
to duplicate what you already have in your workspace.  So let me know.  I
can add registration in start() and deregistration in stop().  Is there a
reason why LoggerBase doesn't implement Lifecycle?  Logger registration
won't be consistent since only FileLogger implements Lifecycle and not the
other two (SystemOut, SystemErr).

>
>
> >> I got reload() to work - but right now I'm stuck with some problems in
> >> stop()/start().
> >>
> >> Reload doesn't deal with modified web.xml - and for some reason
> >> stop()/start() finds some older mappers, something is not cleaning up.
> >>
> >> stop() does now remove all mbeans that it created.
> >
> > Awesome.  :-)
>
> Well, I finally got it working ( in standalone ). I had to create a new
> ServletContext, copy all the settings, then unregister and register again.
>
> It's a bit tricky - we have to unregister/register, otherwise the mapper
> will not work, and what's worse - it's almost impossible to undo all the
> actions that happen in init/start ( since many are driven by web.xml ).

This reminds me that the current mapper doesn't work if there isn't an
Engine with "Catalina" name since it's hard coded, right?

Amy

>
> I don't know how start/stop worked before ( or if it worked ), but
creating
> a new context seemes like a reasonable solution and may avoid some leaks
> or other problems.
>
> The negative is that extending StandardContext will become more tricky.
>
> I'll probably commit tommorow - I still need to remove a lot of debug
> statements and test in embeded case. ( I also checked Host.stop - it
> seems to clean up the JMX, I don't know yet if start() will recreate
> the same environemnt ).
>
>
> Costin
>
> >
> > Amy
> >
> >>
> >> ( by "now" I mean my work version, I have a number of debug statements
> >> to remove and I'll check in ).
> >>
> >>
> >>
> >> Costin
> >>
> >>
> >> -
> >> To unsubscribe, e-mail: [EMAIL PROTECTED]
> >> For additional commands, e-mail: [EMAIL PROTECTED]
> >>
> >>
>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: TC5 JMX

[Costin Manolache]

Amy Roh wrote:

>> I moved the valve registration in addValve().
> 
> Cool.  I think logger and realm registration should be in setLogger and
> setRealm as well so mbeans can get registered correctly.  Also,
> deregistration for old mbean should happen when new logger or realm is
> null.

+1 :-)

For the second part - deregistration should happen on stop().

If you are going to implement this ( please ! ), don't worry about the
embed use case, I'll fix it if there are problems.


>> I got reload() to work - but right now I'm stuck with some problems in
>> stop()/start().
>>
>> Reload doesn't deal with modified web.xml - and for some reason
>> stop()/start() finds some older mappers, something is not cleaning up.
>>
>> stop() does now remove all mbeans that it created.
> 
> Awesome.  :-)

Well, I finally got it working ( in standalone ). I had to create a new
ServletContext, copy all the settings, then unregister and register again.

It's a bit tricky - we have to unregister/register, otherwise the mapper
will not work, and what's worse - it's almost impossible to undo all the
actions that happen in init/start ( since many are driven by web.xml ).

I don't know how start/stop worked before ( or if it worked ), but creating 
a new context seemes like a reasonable solution and may avoid some leaks
or other problems.

The negative is that extending StandardContext will become more tricky.

I'll probably commit tommorow - I still need to remove a lot of debug 
statements and test in embeded case. ( I also checked Host.stop - it 
seems to clean up the JMX, I don't know yet if start() will recreate 
the same environemnt ).


Costin

> 
> Amy
> 
>>
>> ( by "now" I mean my work version, I have a number of debug statements
>> to remove and I'll check in ).
>>
>>
>>
>> Costin
>>
>>
>> -
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: TC5 JMX

[Amy Roh]

> Amy Roh wrote:
>
> > Costin,
> >
> > It doesn't seem like mbeans are created appropriately when logger,
realm,
> > and valve are dynamically added after start.  Is the mbean registration
> > code listening to those events?
>
> It should.
>
> For valve - I think it works now ( I'll make a commit soon with few more
> fixes ). The registration happens in ContainerBase, when the valve is
added
> - and unregistration is also in ContainerBase when the vavle is removed.
>
> >  I see that logger/valve registration is done in
> > ContainerBase.start().  Also, the mbeans are not getting deregistered
and
> > failed to be removed from admin.  Let me know what your plans are.  :-)
>
> I moved the valve registration in addValve().

Cool.  I think logger and realm registration should be in setLogger and
setRealm as well so mbeans can get registered correctly.  Also,
deregistration for old mbean should happen when new logger or realm is null.

>
> I got reload() to work - but right now I'm stuck with some problems in
> stop()/start().
>
> Reload doesn't deal with modified web.xml - and for some reason
> stop()/start() finds some older mappers, something is not cleaning up.
>
> stop() does now remove all mbeans that it created.

Awesome.  :-)

Amy

>
> ( by "now" I mean my work version, I have a number of debug statements
> to remove and I'll check in ).
>
>
>
> Costin
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: TC5 JMX

[Costin Manolache]

Amy Roh wrote:

> Costin,
> 
> It doesn't seem like mbeans are created appropriately when logger, realm,
> and valve are dynamically added after start.  Is the mbean registration
> code listening to those events?

It should. 

For valve - I think it works now ( I'll make a commit soon with few more
fixes ). The registration happens in ContainerBase, when the valve is added
- and unregistration is also in ContainerBase when the vavle is removed.

>  I see that logger/valve registration is done in
> ContainerBase.start().  Also, the mbeans are not getting deregistered and
> failed to be removed from admin.  Let me know what your plans are.  :-)

I moved the valve registration in addValve(). 

I got reload() to work - but right now I'm stuck with some problems in
stop()/start(). 

Reload doesn't deal with modified web.xml - and for some reason
stop()/start() finds some older mappers, something is not cleaning up.

stop() does now remove all mbeans that it created.

( by "now" I mean my work version, I have a number of debug statements
to remove and I'll check in ).



Costin


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]