| Newsgroups |
gmane.comp.java.mx4j.devel |
| Message-ID |
<[email protected]> |
Hi again Simon,
I've responded to your questions inline, below.
I will zip up the code and send to you shortly.
Bordet, Simone wrote:
>Hi,
>
>>I have written an adaptor which essentially duplicates the
>>jmxmp adaptor
>>in JMX remote, and communicates over a regular Socket.
>>The one problem I had with mx4j was that using any of the supplied
>>connectors was incredibly complex (rmi namespaces etc) or
>>very resource heavy (soap using jetty, burlap etc).
>
>
>Just to clarify this, RMI does not use namespaces (what's that in java
>?), and it's not incredibly complex to setup.
>In fact it's waaay easier than the RMI tutorial, since there is no need
>to compile stubs (they come precompiled in MX4J). The only thing to pay
>attention for is the rmiregistry, but this is RMI basics, so it is
>normally well understood.
>
This was not the case the last time I tried to use mx4j (years ago, admittedly),
there was a major hack using JNDI stuff, which is why I went and wrote my own
adaptors.
Perhaps the code has gotten better since then, since I haven't used it for a few
releases.
>About resource heavyness of jetty, it is true that may be heavier than a
>custom socket protocol, but it runs the connector over HTTP (often it is
>not enough to run something on port 80 or 8080, it must be HTTP) and
>it's easily embeddable.
>
>>Obviously my adaptors aren't compatible with the JMX jmxmp connector,
>>but they could form the basis of a good replacement since I
>>think they are not yet implemented in mx4j.
>
>
>The jmxmp provider is not implemented in MX4J.
>The main reason for that is the difficulty of finding a good SASL
>provider; furthermore this provider is defined by the spec, meaning that
>it must be interoperable with RI's (which involves more work).
>
I was under the impression that jmxmp providers didn't need to be able to
communicate across different implementations, if this is not the case I guess
it won't be a jmxmp protocol then.
>>I'm not yet a confirmed cvs submitter either, so what is the best way
>>for you guys to decide if you want to integrate my adaptors
>>or not? I've checked out an anonymous cvs copy, and I'm busy
>
>overlaying
>
>>my code into this to see if all the tests run ok.
>
>
>I'd like to see the code, if you can zip it and send it to me.
>I also have few questions, below:
>
>1. Does it implements all JSR 160 API ? That is: can it emit connection
>notifications, handle remote notifications and support all the
>MBeanServerConnection API ?
>
Yes, but I haven't run the full suite of tests in the current workspace, since
it seems to not find my provider server and client classes.
>2. What is the proposed protocol name ?
>
I was calling it "socket", since that's all it uses.
>3. How does it handle authentication and confidentiality ?
>
It doesn't. It could be extended to communicate using SSL socket instead of
java.net.Socket, similar to what you do for your existing adaptors.
>4. How does it handle threads ? It is thread safe ? Has it been tested
>with multiple clients ?
>
It seems to work fine for my usage, but you never know, scaling this kind of
thing up always flushed new bugs out.
>5. Which JDK targets to ? 1.3, 1.4, 1.5 ?
>
Currently uses standard 1.3 code
>6. How does it handle classes that are unknown to the client, but
>present in the server ? And viceversa ?
>
No special handling, you are expected to have correct classloader for all
classes being exchanged.
>7. What is the serialization mechanism ? Is it pluggable ?
>
Just defaults to Serializable, and writes the object across the socket.
>8. Which mechanism is it used for protocol framing ?
>
No idea what yo are talking about here.
>9. Does it reuse the MX4J abstract classes in mx4j.tools.remote.* as the
>basis for the implementation ?
>
The 2 main classes extends javax.management.remote.JMXConnector and
javax.management.remote.JMXConnectorServer.
No dependancies exist on mx4j code.
>10. Have you comments about how this protocol fits with the following
>document: http://www.ietf.org/rfc/rfc3117.txt
>
I'd say the referenced RFC is much better researched, probably is better longer
term, but will require major effort, and still won't give you a jmxmp adaptor.
It might also be a little complicated.
My adaptor is very lightweight, requires nothing more than java.net.Socket, and
is easy to configure using standard open proxy/firewall ports.
Mine has the additional advantage of existing today...
>Thanks,
>
>Simon
>
>
>-------------------------------------------------------
>SF email is sponsored by - The IT Product Guide
>Read honest & candid reviews on hundreds of IT Products from real users.
>Discover which products truly live up to the hype. Start reading now.
>http://ads.osdn.com/?ad_ide95&alloc_id396&op=click
>_______________________________________________
>Mx4j-devel mailing list
>[email protected]
>https://lists.sourceforge.net/lists/listinfo/mx4j-devel
>
>
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id396&op=click