Re: Remaining tasklist for alpha?

  Hi group. Simone :)

> Actually I am pretty confident about the implementation, so
> I would go to a beta directly.
  I even thought of a release candidate directly. This version has undergone
quite a development, and should be very stable.
  However you mention, that the JSR 160 hasn't been finalized, so RC might
be a bad option if something might change seriously in the specs.

> Ward is working hard on JMX 1.2 (thanks man !), and JSR 160
> is still in EA2 compliance: we're waiting for JSR 160 final
> release and then we have to upgrade the implementation.

> Then we need examples and documentation.
  Ahmmm... Yes. However I think, that the docs might be left to the users.
I.e. if i need docs, I should get the Sun ones. Right?
  The examples however might be very handy for new users/developers.

>
> Another point that is not clear to me is the status of the
> HTTP adaptor: Carlos ?
> I was also thinking of moving the HTTP adaptor from
> mx4j.adaptor.http.* to mx4j.tools.adaptor.http.*. It is a
> breaking change, but I think the next release of MX4J will
> be named 2.0, so it is a major change and if we want to make
> this change better we do it now.
  Well... Changing the package might not be a big deal, many developers (I
in that number) use flexible configuration, where the change will be
stright-forward with no recompilation. And of course if the change is
imminent it is better done now than later. The sooner the better. Until the
release most people will have switched.

> I have in my sleeve 2 stuff:
> 1. A heartbeat implementation, a general one and for RMI (to
> notify the client when the server is down).
> 2. A configuration file implementation, which I'm using
> with great satisfaction (I posted about it some day ago).
>
> Anyone interested in these to be part of the release ?
  DEFINITELY! BOTH HANDS!
  At work I had to write such a Loader, that would configure the Server from
an XML file, that describes beans, attributes and operations called upon
initialization.
  I made it of course, but providing such a solution for the community will
boost third parties, that will develop MBean libraries and supply an
already-standard deployment/initialization descriptor.
  This might be a big step forward to modularized development, because
developers/users will have the option to write/use standard packages, that
contain services.

  BTW. I am sorry to not take part in this, but the company policy is not
very friendly on writing for third parties :(.

> Simon

  Lachezar.





-------------------------------------------------------
This SF.net email is sponsored by OSDN developer relations
Here's your chance to show off your extensive product knowledge
We want to know what you know. Tell us and you have a chance to win $100
http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54