4 Replies Latest reply on Jan 16, 2003 4:09 PM by starksm64

    Let's Begin

    bill.burke

      We need better management information. A lot of the JSR-77 stuff is useful
      information, the only problem was with how it was integrated, not really
      tested, and not understood by the people working on the core stuff into
      which this foreign code was interjected.


      Where applicable this should be integrated via interceptors and/or aspects that
      emit JMX notifications on which JSR-77 bean may be created. So the first
      step is to replace the existing JSR-77 stuff with what we actually need to do
      management and support of JBoss. For caches, pools, invocations, etc. there
      needs to be low impact asynchronous events that allow for collection of this
      information and rehashing statistically and historically.

      I want this working in 3.2 as well so where the aspect stuff cannot be used
      alternative approaches are needed.

      xxxxxxxxxxxxxxxxxxxxxxxx
      Scott Stark
      Chief Technology Officer
      JBoss Group, LLC
      xxxxxxxxxxxxxxxxxxxxxxxx

      From: "David Jencks" <davidjencks@directvinternet.com>
      To: scott.stark@jboss.org
      Sent: Monday, December 23, 2002 11:22 AM
      Subject: Management layer


      > Before you do anything to the jsr-77 stuff, I'd like to know if we plan to
      > continue to implement it. Although I personally never got why it is useful
      > under any circumstances, I'm willing to believe e.g. marc if he says we
      > should keep it. anyway,
      >
      > -- if we plan to implement it, I suggest moving directly to an mbean
      > interceptor/aspect based implementation where we keep the "management"
      > module more or less the same but replace the stuff spread all over the rest
      > of the code with interceptors.
      >
      > -- if we plan to not implement it, ... remove it all.
      >
      > I think even a somewhat lame implementation will provide an easier base for
      > improvement than starting over from scratch. Do we have anyone interested
      > in working on it? There was a guy helping andy for a while.
      >
      >
      > thanks
      > david

        • 1. Re: Let's Begin

          TODO: org.jboss.mx.notification.AsynchNotificationBroadcasterSupport

          • 2. Re: Let's Begin

            Done

            Regards,
            Adrian

            • 3. Re: Let's Begin

              cool!

              • 4. Re: Let's Begin
                starksm64

                I browsed back through the latest spec and I am still not sure what some of these objects
                represent, but that is not important for my initial focus. What I want is to remove the
                dependency on JSR-77 components from the core layer in both 3.2 and 4.0. Right now even the minimal
                configuration has to include the management jar.

                Beyond that, which management objects should or should not have MBean representations
                is up for debate and I'm not sure I care one way or the other in the absence of a prototype
                that indicates obvious advantages. Having a lot of objects is not in itself a very good
                reason to not use MBeans if there are overriding advantages.