RE: Some code to donate

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.

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'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 ?
2. What is the proposed protocol name ?
3. How does it handle authentication and confidentiality ?
4. How does it handle threads ? It is thread safe ? Has it been tested
with multiple clients ?
5. Which JDK targets to ? 1.3, 1.4, 1.5 ?
6. How does it handle classes that are unknown to the client, but
present in the server ? And viceversa ?
7. What is the serialization mechanism ? Is it pluggable ?
8. Which mechanism is it used for protocol framing ?
9. Does it reuse the MX4J abstract classes in mx4j.tools.remote.* as the
basis for the implementation ?
10. Have you comments about how this protocol fits with the following
document: http://www.ietf.org/rfc/rfc3117.txt

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