[Design of Messaging on JBoss (Messaging/JBoss)] - Re: JBM 2 Management Interfaces
by jmesnil
"jmesnil" wrote : "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
|
| 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).
As an example, it is only a 3-line 0-dependency change to be able to manage a MessagingServer from a GUI.
Step 1/ Expose our POJO as MBeans on the platform mbeanserver. E.g using JBM's trunk EmbeddedExample:
| MessagingServer messagingServer = ...;
|
| // add the next 3 lines:
| StandardMBean serverMBean = new StandardMBean(messagingServer, MessagingServer.class);
| ObjectName serverON = ObjectName.getInstance("org.jboss.messaging:name=MessagingServer");
| ManagementFactory.getPlatformMBeanServer().registerMBean(serverMBean, serverON);
|
| messagingServer.start();
|
Step 2/ Run JBM in standalone and add jmx management. On Sun JVM, set -Dcom.sun.management.jmxremote
That's all we need to do to be able to use a generic JMX console.
Step 3/ Open jconsole and connect using the "local" connection.
In the "MBeans" tab, go to "org.jboss.remoting:name=MessagingServer".
In the "Operations", start and stop the messaging server as much as you want.
To sum up, to get this minimal support for a GUI management console, the only thing we need to do is register our POJO on the platform mbean server.
This can be done very simply in any POJO implementation which conforms to an interface:
| class ServiceImpl implements ServiceIntf
| {
| public ServiceImpl(...)
| {
| ...
| ObjectName on = new ObjectName(...) // based on POJO fields
| // this instance is exposed as a MBean of the ServiceIntf interface...
| StandardMBean mbean = new StandardMBean(this, ServiceIntf.class);
| // ... and registered on the JVM platform mbean server
| ManagementFactory.getPlatformMBeanServer().registerMBean(mbean, on);
| }
|
| // somewhere in the POJO lifecycle, we should also unregister its MBean
| }
|
As long as we stick to standard JMX conventions (get/set for properties, etc.), we could have a usable GUI console for (almost) free.
The memory footprint to register the mbeans on the platform mbean server is negligible and this could be done regardless of the way JBM is run (as long as we unregister mbeans properly when the managed resources are disposed)
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4130876#4130876
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4130876
18 years, 1 month
[Design the new POJO MicroContainer] - Re: Handling contexts in error
by adrian＠jboss.org
The MC can do all this, except the failure part.
The reason it can't do the failure part is because it follows what is an accepted
generally good programming practice (e.g. ejbs do the same)
that if the container invokes a bean and it throws an error then you discard
that bean. You can't know that the bean is still in a good state because
you don't know why it threw the error.
PROPOSAL
I've had a seperate thought which is probably more acceptable to both
you and to me, ;-)
What you really want to do is manage the state of the failed beans.
i.e. you want to takeover the management of the context in error from the MC
and fix it manually.
So my solution would be to allow something like:
xml pseudo code as always ;-)
| <bean ... error-handling="manual"/>
|
If for example the bean threw an error in start() then we no longer just discard
this bean. Instead we would effectively change its controller mode to "manual"
(if it isn't already) and just then revert it to the previous state. i.e. Created in this case
or back to Instantiated if the property configuration failed.
You can then pick up the management of the bean from there.
When you decide to move the bean, we would just clear the error in the
controller context and try again (reverting back to automatic if the bean
was previously in that mode).
We would never try to move a context in such a state without an
explicit request on the controller to do so.
I don't think this would require a major change in the Controller,
most of the work would be in the IncompleteDeploymentException
where we would now have to check all contexts at all states
to see whether it has an error set (previously we just retrieved those
in the **ERROR** state).
We may want to only allow this for checked exceptions. i.e. if start throws
a RuntimeException or Error, we would still discard the bean
or perhaps make it configurable?
This semantic would deal with my objections above and give you the
ability to manage the failing beans/contexts without having to re-install them.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4130872#4130872
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4130872
18 years, 1 month
[Design the new POJO MicroContainer] - Re: Handling contexts in error
by julien＠jboss.com
Here is my use case:
I defined an SPI for that allow to integrate portlet applications / portlet container and portlet filter objects (which have a stop/start/failed life cycle and start() throws Exception / stop() callbacks) with kernel system (whether it is MC or something else).
I have two facade of objects:
1/ managed object which are exposed to admin and allow to know what exists, the state and life cycle trigger (managedStart() / managedStop())
base class is
| public interface ManagedObjet
| {
| ManagedObjectStatus getStatus();
| void managedStart() throws Exception;
| void managedStop();
| }
|
then for instance I have
| public interface ManagedPortletApplication extends ManagedObject
| {
| Collection<ManagedPortletContainer> getPortletContainers();
| }
|
| public interface ManagedPortletContainer extends ManagedObject
| {
| ManagedPortletApplication getPortletApplication();
| }
|
-----------------------------------
Then I have the internal API that is aimed at providing wiring capabilities and real start/stop activities
| public interface PortletContainerService
| {
| void setPortletApplication(PortletApplicationService pa);
| void start() throws Exception;
| void stop();
| }
|
| public interface PortletApplicationService
| {
| void addPortletContainer(PortletContainerService pc);
| void removePortletContainer(PortletContainerService pc);
| void start() throws Exception;
| void stop();
| }
|
-----------------------------------
Now I am trying to get an MC implementation of the Managed* stuff that uses JBoss MC to:
1/ manage the *Service objects (wiring and callbacks)
2/ provide a managed interface to know about what exists and managed their life cycle
3/ be integrated with other MC beans that may exist in the same Kernel (so it is possible to create dependencies between a portlet container and another service, etc...)
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4130850#4130850
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4130850
18 years, 1 month
[Design of Messaging on JBoss (Messaging/JBoss)] - Re: JBM 2 Management Interfaces
by timfox
"mazz(a)jboss.com" wrote : "timfox" wrote :
| |
| | I didn't talk about the new JBoss5 embedded console and this may address this point you bring up.
| |
| | The new JBoss5 embedded console will actually ship with the RHQ "plugin container" running in-process with it. So, the "big iron" and the embedded console will use the same RHQ plugin architecture. The embedded console will actually be:
| |
| | a) a web app war with its own little seam-based UI (not the big-iron RHQ core UI but with some shared RHQ UI code nonetheless)
| | b) the RHQ plugin container (the same plugin container running in the RHQ Agent - the RHQ Agent is just a shell that wraps the RHQ plugin container)
| | c) the RHQ JBossAS5 plugin, which is deployed in the plugin container
| |
| | So, it is concievable that you could write your jbm management UI and have it interface with the RHQ plugin (that talks to your jbm management interface) by embedding the plugin container just like the JBoss5 microcontainer's embedded console will do. That way you have one plugin that works in either your smaller mgmt UI console AND the big-iron RHQ Server stuff.
| |
|
| Now that sounds interesting.
|
|
|
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4130844#4130844
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4130844
18 years, 1 month
[Design of Messaging on JBoss (Messaging/JBoss)] - Re: JBM 2 Management Interfaces
by mazz＠jboss.com
"timfox" wrote :
| It's just a shame we can't get the nice UI unless we have the "big-iron" server.
I didn't talk about the new JBoss5 embedded console and this may address this point you bring up.
The new JBoss5 embedded console will actually ship with the RHQ "plugin container" running in-process with it. So, the "big iron" and the embedded console will use the same RHQ plugin architecture. The embedded console will actually be:
a) a web app war with its own little seam-based UI (not the big-iron RHQ core UI but with some shared RHQ UI code nonetheless)
b) the RHQ plugin container (the same plugin container running in the RHQ Agent - the RHQ Agent is just a shell that wraps the RHQ plugin container)
c) the RHQ JBossAS5 plugin, which is deployed in the plugin container
So, it is concievable that you could write your jbm management UI and have it interface with the RHQ plugin (that talks to your jbm management interface) by embedding the plugin container just like the JBoss5 microcontainer's embedded console will do. That way you have one plugin that works in either your smaller mgmt UI console AND the big-iron RHQ Server stuff.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4130840#4130840
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4130840
18 years, 1 month
[Design of Messaging on JBoss (Messaging/JBoss)] - Re: JBM 2 Management Interfaces
by timfox
"mazz(a)jboss.com" wrote :
|
| Agreed. RHQ is for production management. If you want a small, simple management UI (for, say, developers to use), RHQ is not what you want to use.
|
| But, what you will want to do is make your management interface remotely accessible so you CAN plug into a production management environment (like RHQ) so I can manage your jbm services along side of my other production apps/services.
|
| So, I can import my jbm services into RHQ's inventory along with my JBossAS servers, and other managed products so, when I *do* deploy jbm in production, I can manage it with all my other things in a single management platform. Because if I have to load up your management console UI separately from my other management tools just to manage jbm, that would suck too. Its a "production" enviroment vs. "development" environment thing.
|
Well.. I guess if we just expose our beans via JMX using the standard JDK stuff as Jeff suggested, then we have the best of both worlds.
It's just a shame we can't get the nice UI unless we have the "big-iron" server.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4130829#4130829
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4130829
18 years, 1 month