3 Replies Latest reply on Dec 16, 2006 6:26 PM by Ales Justin

    JMX Decorator for POJOs - suggestion

    David Ward Master

      In regard to this JIRA issue:
      http://jira.jboss.com/jira/browse/JBMICROCONT-71
      ... I have a suggestion:

      I think that exposing a microcontainer POJO as an MBean, and optionally also making it available in JNDI, would be a farily common thing to do. Thus, I think an ultra-easy way of configuring a POJO to expose itself as so should be available. May I suggest adding 2 new optional attributes to the <bean ...> element? jmx-name and jndi-name? Simply adding them to the bean tag will go ahead and dynamically expose it as an mbean or add it to JNDI, respectively? Example:

      <bean
      name="Bar"
      jmx-name="jboss.foo:service=Bar"
      jndi-name="java:/foo/Bar"
      class="com.foo.Bar"/>

      I think this would be easier for people than a sub <annotation ...> element (I remember seeing something like this somewhere for jndi binding in the microcontainer). For JMX, I like it better than a @JMX annotation on the bean also (I saw that someplace too). However, I understand that is more of a matter of opinion/taste...

      If this has already been suggested then shame on me. :)

      Thoughts?

        • 1. Re: JMX Decorator for POJOs - suggestion
          Adrian Brock Master

          No because this breaks the whole idea of "do one thing well".
          The microcontainer is a dependency state machine.

          Besides, despite your assertion only a small percentage of POJOs end up in JNDI
          and then not always trivially, e.g. they need to wrapped in object factories.

          There already is a mechansim to add adhoc metadata to beans that can
          be processed by pluggable interceptors so you can do

          <bean ...>
           <annotation>org.jboss.jndi.JNDIBinding("blah")</annotation>
          
          or
          
          <bean ..>
           <annotation org.jboss.jndi.JNDIBinding(value="blah" objectFactory=com.acme.SomeObjectFactory)</annotation>
          


          Which makes this much more extenisbe in terms of matching the
          metadata (the annotation) to the implementation (the aspect).

          Additionally, you can meta-annotate the metadata to say it requires another service,
          e.g.
          @Depends("jboss:service=Naming")
          public @interface JNDIBinding
          ...
          


          So you know beans annotated with JNDIBinding must wait for the Naming Service
          to start.

          This is a much more generic mechanism than the "hacky" approach you describe.
          1) It requires not extra handling in the microcontainer
          2) You can use AOP to map the metadata to any aspect implementation you like
          3) The metadata is extensible as new requirements are understood.

          • 2. Re: JMX Decorator for POJOs - suggestion
            David Ward Master

            Adrian,

            I appreciate your response, though I think "hacky" was a bit strong... :) I merely thought that a jndi-name attribute could serve as a shorthand for the JNDIBinding annotation that you mentioned. It is very similar to the <attribute name="JNDIName"...> element that one can nest under MBean tags. Is that considered "hacky" as well?

            Having a shorthand or "easier" way of doing configuration is not unprecedented in JBoss. For example, people used to have to write mbean *-service.xml files to set up datasources in AS. Now they just have to write a *-ds.xml file, which is a simpler syntax, although under the hood it just gets trasnformed. (Or at least that's how it used to be implemented...)

            Last, your repsponse addressed putting the POJO in JNDI. I didn't see what the recommended approach is to expose the POJO as a JMX MBean. Is there an <annotation ..> for that is well?

            Thank you.