Creating a JMX Managed Bean in a portlet

[Robert Leo Smith, modificado 12 Anos atrás.]

Hi all,

I'm wondering if anyone has attempted to create a managed bean within a portlet? Our application needs the ability to do some monitoring and property setting on the fly and we thought using JMX would be a good solution.

I've been investigating JMX and haven't had much luck.

We are running on JBoss 5.1.0 and using ICEfaces and Spring. I've attempted to use Spring to create a managed bean and also attempted to do it by creating a sar.

When I used Spring, it seems to work as it compiles and deploys, but the MBean is not visible in the JBoss jmx-console or in JConsole.

When I used the sar approach, I tried 2 methods. First, I created a separate project that generated a .sar file with a META-INF directory containing the jboss-service.xml. On deployment, it failed with classpath errors. I'm assuming that is because the sar is not in an ear with the portlet webapp, hence the classpath is just JBoss which doesnt contain the portlet classpath.

Next, I tried adding the jboss-service.xml in the META-INF directory of the portlet war. That too appeared to work fine, except as with Spring the MBean is not visible in the JBoss jmx-console or JConsole.

I'm starting to run out of ideas, and I'm not finding much information about creating JMX MBeans within portlets.

[Andew Jardine, modificado 9 Anos atrás.]

Hi Robert,

Did you ever manage to figure this one out? I am looking to do the same thing and would appreciate any information you can share --

[David H Nebinger, modificado 9 Anos atrás.]

It's actually no different than creating a bean in any other scenario, i.e. a servlet.

The difficulty here is the perception of what should be in JMX. When you're coding a portlet, you are only creating a single plugin. However, at runtime you'll have X instances of a portlet, where X depends upon how many pages it's on, how many instances per page, how many users have hit the page, ...

This is where the idea of using JMX to set a property on 'the portlet' fails, because there can be so many instances you'll spend more time trying to update each one than it's worth.

Instead I would recommend using portal-ext.properties (if using a single instance) or a database table (for a cluster). That way a single change can affect all runtime instances (as long as you're not caching the value in your code). portal-ext.properties changes are actually updated on a timed basis, so there is a short window where you'll get a stale value, but you can control this by adjusting the timeframe for refresh.

[Andew Jardine, modificado 9 Anos atrás.]

Hey David,

Interesting and excellent point about the portlets. I think I was confusing myself -- in the end what I actually want to be monitoring is a set of classes packaged into a jar that are leveraged by the portlet. More interestingly, I was not aware that the portal-ext file was reloaded on a timed interval! I was always under the impression that you had to restart the server every time you modified it.

When was that feature introduced? ... or has it always been there and I was just misinformed?

[David H Nebinger, modificado 9 Anos atrás.]

Andew Jardine:

When was that feature introduced? ... or has it always been there and I was just misinformed?

Well, Liferay uses EasyConf (an extension of commons-configuration) and has done so since 6.0 for sure, but possibly this was in the 5.x line. EasyConf has support for it built in.

That said, it is not enabled in the portal.properties, you'd have to add it to portal-ext.properties as such:

#
# Easyconf configuration options.
#
# easyconf:reload-delay - Defines a 'watch' time on the config files; if they get updated, easyconf will
# reload the configuration, but only if this value is defined.  We'll use 30 seconds, or 30,000 milliseconds.
easyconf:reload-delay=30000

[Andew Jardine, modificado 9 Anos atrás.]

Hah! awesome. Learn something new everyday. Thanks for sharing David!

[Robert Leo Smith, modificado 9 Anos atrás.]

Partially. Got it visible within the JBoss Console. Its been a couple years but if I remember correctly it was settings within the application context hooking into Jboss that were wrong.

I never got it to be visible in JConsole - but that was not a specific problem with the JMX bean, it was related to JBoss not exposing them in 5. If you are using a later release of jboss, I dont think they support a web console anymore but expose via their cli interface - I've not attempted that yet.

-Robert

[Andew Jardine, modificado 9 Anos atrás.]

Ok thanks Robert. One of the rubs for me is that I am not using JBOSS actually... my setup is on a tomcat bundle. Good to know that you did get something working in the end though so there is hope