JBossDeveloper

When I start hearing about different servers in different processes alarm bells start to ring.

We need a simple management API that can run in the same microcontainer instance without dragging in lots of dependencies.

One of the key differentiators of the standalone deployment is it is has a small footprint.

What dependencies does it have?

Seam
JBossWeb
JBoss remoting

any others?

I don't want to end up in a situation where we have to start an MBean server just so we can expose our POJOs

"ataylor" wrote:

Why don't we just write a simple proxy and use JMS as the transport. The only issue then is the UI.

From jbm's point of view, you just expose your management "stuff" via JMX MBeans. If you want jbm to be managed "by something" (RHQ or something else) you need to do this no matter what. Since jbm is written in Java, JMX seems to be the logical choice. jbm is as lightweight as you make it - the jbm MBeans are hosted by jbm somewhere (maybe it has its own MBeanServer, maybe it uses the JRE5 platform MBean Server, maybe its running in JBossAS and it uses JBoss's MBeanServer... its up to you).

Then, you can either:

a) write your own client that connects to the MBeanServer that exposes your MBeans, and write your own management application/UI that makes JMX API calls to interact with the jbm management facilities.

or

b) write an RHQ plugin that connects to the MBeanServer that exposes your MBeans (no Java code needed on your part if the JMX plugin can do everything you need) and utilize the RHQ feature set that the RHQ Server core UI provides.

and I do not have an uncle named Bob ;)

Let me be clear, too - RHQ does NOT introduce ANY dependencies in YOUR managed product. You have no RHQ code in jbm at all. I only bring up JMX because that's the "standard" way to manage Java apps/services. You can do it however you want.

Its the RHQ plugin that needs to talk to your management interface. Its the RHQ plugin that has dependencies on YOUR product. For example, the JBossAS4 plugin has dependencies on JBossAS client libraries - it is NOT the other way around (that is, JBossAS4 has NO RHQ dependencies - nothing RHQ-related runs inside of JBossAS4).

Hmmm.

JBM 2.0 has specifically moved *away* from MBeans. We have no MBeans in JBM any more. We are just POJOs - this is the way most services are going, especially for AS 5.0.

I don't think there's any chance we'll re-introduce MBeans just so we can have a management UI.

Robert is also not my mother's brother. ;)

"mazz@jboss.com" wrote:
Let me be clear, too - RHQ does NOT introduce ANY dependencies in YOUR managed product. You have no RHQ code in jbm at all. I only bring up JMX because that's the "standard" way to manage Java apps/services. You can do it however you want.

"timfox" wrote:
I don't want to end up in a situation where we have to start an MBean server just so we can expose our POJOs

This is fine. You do not need JMX - I only brought it up because remoting 2 had MBeans and I thought jbm would still. It doesn't matter - you expose your management however you want. SNMP, your own custom management interface, whatever. Its the plugin developer that needs to connect to your jbm management interface, if you do it your own way, just have the plugin connect to it in "your way". For example, put your jbm management client libraries in the plugin jar and it can connect to it however it wants.

It does not have to be JMX, forget I even mentioned it :)

"@JMX" is not a standard annotation from the JDK libraries, so we can't have it in our core classes since it will introduce a build time dependency on whatever library that comes from (AOP?), and we don't want to force our embedded users to drag in jars they don't need.

"jmesnil" wrote:

For the standalone case, the simple way is to register our POJOs as MBeans on the JVM platform MBeanServer, enable a remote access to it and use a generic JMX console (e.g. jconsole).

0 dependencies other than Java 5, everything is already included.
Generic JMX consoles are not as good as specialized ones but they can be sufficient if our MBeans are meaningful enough.