You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Costin Manolache <cm...@yahoo.com> on 2004/10/06 07:06:52 UTC
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.
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: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: JMX Remote connection
Posted by Remy Maucherat <re...@apache.org>.
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: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: JMX Remote connection
Posted by Jess Holle <je...@ptc.com>.
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
>
> <quote>
> *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.
> </quote>
>
> 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: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: JMX Remote connection
Posted by Remy Maucherat <re...@apache.org>.
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
>>
>> <cut>
>> 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.
>> </cut>
>
>
> 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
<quote>
*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.
</quote>
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: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: JMX Remote connection
Posted by Jess Holle <je...@ptc.com>.
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: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: JMX Remote connection
Posted by Costin Manolache <cm...@yahoo.com>.
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
>>>
>>> <cut>
>>> 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.
>>> </cut>
>>
>>
>>
>> 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: tomcat-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: JMX Remote connection
Posted by Jess Holle <je...@ptc.com>.
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
>>
>> <cut>
>> 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.
>> </cut>
>
>
> 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: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: JMX Remote connection
Posted by Remy Maucherat <re...@apache.org>.
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
>
> <cut>
> 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.
> </cut>
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: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: JMX Remote connection
Posted by Dominik Drzewiecki <dr...@post.pl>.
> 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
<cut>
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.
</cut>
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: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: JMX Remote connection
Posted by Remy Maucherat <re...@apache.org>.
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: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: JMX Remote connection
Posted by Costin Manolache <cm...@yahoo.com>.
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: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: JMX Remote connection
Posted by Remy Maucherat <re...@apache.org>.
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: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: JMX Remote connection
Posted by Dominik Drzewiecki <dr...@post.pl>.
>> 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: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: JMX Remote connection
Posted by Bill Barker <wb...@wilshire.com>.
----- Original Message -----
From: "Costin Manolache" <cm...@yahoo.com>
To: <to...@jakarta.apache.org>
Sent: Tuesday, October 05, 2004 10:47 PM
Subject: Re: JMX Remote connection
> Bill Barker wrote:
>>
>> ----- Original Message ----- From: "Costin Manolache"
>> <cm...@yahoo.com>
>> To: <to...@jakarta.apache.org>
>> 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: tomcat-dev-unsubscribe@jakarta.apache.org
>>> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>>>
>>>
>>
>>
>>
>> ------------------------------------------------------------------------
>>
>>
>> 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: tomcat-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
>
Re: JMX Remote connection
Posted by Costin Manolache <cm...@yahoo.com>.
Bill Barker wrote:
>
> ----- Original Message ----- From: "Costin Manolache"
> <cm...@yahoo.com>
> To: <to...@jakarta.apache.org>
> 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: tomcat-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>>
>>
>
>
>
> ------------------------------------------------------------------------
>
>
> 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: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: JMX Remote connection
Posted by Bill Barker <wb...@wilshire.com>.
----- Original Message -----
From: "Costin Manolache" <cm...@yahoo.com>
To: <to...@jakarta.apache.org>
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: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
>