Search

6.6. Exposing POJOs as MBeans

download PDF

Example 6.8. Exposing an Existing POJO as an MBean

<deployment xmlns="urn:jboss:bean-deployer:2.0">

  <bean name="AnnotatedJMXPojo" class="org.jboss.demos.models.jmx.AtJmxPojo"/>

  <bean name="XmlJMXPojo" class="org.jboss.demos.models.mbeans.Pojo">
    <annotation>@org.jboss.aop.microcontainer.aspects.jmx.JMX(exposedInterface=org.jboss.demos.models.mbeans.PojoMBean.class, registerDirectly=true)</annotation>
  </bean>

  <bean name="ExposedPojo" class="org.jboss.demos.models.jmx.Pojo"/>

  <bean name="AnnotatedExposePojo" class="org.jboss.demos.models.jmx.ExposePojo">
    <constructor>
      <parameter><inject bean="ExposedPojo"/></parameter>
    </constructor>
  </bean>

</deployment>
			
			
			
			

This descriptor exposes an existing POJO as an MBean, and registers it into an MBean server.
To expose a POJO as an MBean, end it with an @JMX annotation, assuming that you have imported org.jboss.aop.microcontainer.aspects.jmx.JMX. The bean can either be exposed directly, or in its property.

Example 6.9. Exposing a POJO as an MBean Using Its Property

<deployment xmlns="urn:jboss:bean-deployer:2.0">

  <bean name="XMLLoginConfig" class="org.jboss.demos.models.old.XMLLoginConfig"/>

  <bean name="SecurityConfig" class="org.jboss.demos.models.old.SecurityConfig">
    <property name="defaultLoginConfig"><inject bean="XMLLoginConfig"/></property>
  </bean>

  <bean name="SecurityChecker" class="org.jboss.demos.models.old.Checker">
    <property name="loginConfig"><inject bean="jboss.security:service=XMLLoginConfig"/></property>
    <property name="securityConfig"><inject bean="jboss.security:service=SecurityConfig"/></property>
  </bean>

</deployment>
			
			
			
			

You can use any of the injection look-up types, by either looking up a plain POJO or getting a handle to an MBean from the MBean server. One of the injection options is to use type injection, sometimes called autowiring, and shown in Example 6.10, “Autowiring”.

Example 6.10. Autowiring

<deployment xmlns="urn:jboss:bean-deployer:2.0">

  <bean name="FromGuice" class="org.jboss.demos.models.plain.FromGuice">
    <constructor><parameter><inject bean="PlainPojo"/></parameter></constructor>
    <property name="guicePojo"><inject/></property>
  </bean>

  <bean name="AllPojos" class="org.jboss.demos.models.plain.AllPojos">
    <property name="directMBean"><inject bean="jboss.demos:service=pojo"/></property>
    <property name="exposedMBean"><inject bean="jboss.demos:service=ExposedPojo"/></property>
    <property name="exposedMBean"><inject bean="jboss.demos:service=ExposedPojo"/></property>
  </bean>

</deployment>
			
			
			
			

The FromGuice bean injects the Guice bean via type matching, where PlainPojo is injected with a common name injection. Now, you can test if Guice binding works as expected, as shown in Example 6.11, “Testing Guice Functionality”.

Example 6.11. Testing Guice Functionality

public class FromGuice {
    private IPojo plainPojo;
    private org.jboss.demos.models.guice.Pojo guicePojo;

    public FromGuice(IPojo plainPojo)
    {
	this.plainPojo = plainPojo;
    }

    public void setGuicePojo(org.jboss.demos.models.guice.Pojo guicePojo)
    {
	this.guicePojo = guicePojo;
    }

    public void start()
    {
	f (plainPojo != guicePojo.getMcPojo())
	    throw new IllegalArgumentException("Pojos are not the same: " + plainPojo + "!=" + guicePojo.getMcPojo());
    }
}
			
			
			
			

Example 6.11, “Testing Guice Functionality” only provides an alias component model. The alias is a trivial, but necessary feature. It must be introduced as a new component model inside the Microcontainer, in order to implement it as a true dependency. The implementation details are shown in Example 6.12, “AbstractController Source Code”.

Example 6.12. AbstractController Source Code

<deployment xmlns="urn:jboss:bean-deployer:2.0">
  <alias name="SpringPojo">springPojo</alias>
</deployment>
			
			
			
			

This descriptor maps the SpringPojo name to the springPojo alias. The benefit of aliases as true component models is that timing of bean deployment becomes less important. The alias waits in a non-installed state until the real bean triggers it.
Red Hat logoGithubRedditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

© 2024 Red Hat, Inc.