Re: JMX Remote connection

2004-10-07 Thread 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.

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


Re: JMX Remote connection

2004-10-07 Thread 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

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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: JMX Remote connection

2004-10-07 Thread 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

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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: JMX Remote connection

2004-10-07 Thread 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

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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: JMX Remote connection

2004-10-07 Thread 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

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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: JMX Remote connection

2004-10-07 Thread 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

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: [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

2004-10-07 Thread 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

2004-10-06 Thread 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

2004-10-06 Thread 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

2004-10-06 Thread 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.

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


Re: JMX Remote connection

2004-10-06 Thread 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

2004-10-06 Thread 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.

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


Re: JMX Remote connection

2004-10-06 Thread 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

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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


JMX Remote connection

2004-10-05 Thread 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]


Re: JMX Remote connection

2004-10-05 Thread 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]

Re: JMX Remote connection

2004-10-05 Thread 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]