[Design of Messaging on JBoss (Messaging/JBoss)] - Re: JBM 2 Management Interfaces
by scott.stark@jboss.org
"timfox" wrote : "@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.
This is the main issue that requires administration to be treated as an aspect that can be applied as an integration concern. We override the default jms destinations to apply the management aspect in jbossas. In general, we need to support different aspect mappings to allow projects to use whatever is natural to them.
If you want to use jmx, fine. If you want to use the mc @ManagementObject stuff, fine. The integration layer need to define the correct aspect that allows this information to be properly brought into the management view of the environment.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4130913#4130913
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4130913
18 years, 1 month
[Design of JBoss Portal] - Re: future directions
by julien@jboss.com
The PF is a way to decouple the portal from its presentation layer so you can have the implementation of your choice:
- HTML (Classic)
- Ajax
- Flex
- Swing
the need really comes from the fact that the portal *must* not rely on a specific kind of presentation technology. For instance your portal should not behave differently if you use HTML or Ajax, what I mean by behave here is the portal logic, like if I click on page XYZ, it shows page page XYZ).
The PF does other things, I wrote a document that outlines it, you can see read it http://docs.google.com/Doc?id=dhfvtj95_1fnrk2f
We can discuss about it in that forum.
"thomas.heute(a)jboss.com" wrote : No the presentation framework sure doesn't rely on an ajax framework. It's decoupled from the view actually.
|
| If you want to base your view on YUI the good thing is that you can. But if your neighbor want it based on GWT (Which is quite popular, like it or not) he can, and if someone else want plain old HTML he can too.
|
| The presentation framework gives you the necessary abstraction ! We won't rely on a technology, it changes too quickly, and that's why the presentation framework is born :)
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4130909#4130909
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4130909
18 years, 1 month
[Design of Messaging on JBoss (Messaging/JBoss)] - Re: JBM 2 Management Interfaces
by bytor99999
Hi guys, glad to be a part of this conversation.
After reading through the thread, I thought I'd add my 2 cents with regards to using RHQ and Embedded Console, if that is the route you should choose. (Which I think is the best route :) )
OK, so think of this in just three parts.
1) The UI (Embedded Console)
2) Plugins and the RHQ Plugin Container
3) Your Management Interface for JBM
I hope you don't mind be going top down.
1) The Embedded Console is just a Seam app, so all it needs is something that can "deploy" a Seam app, I believe that includes the Microcontainer. The great thing about the console is that it is generic, just create a plugin and drop it in the plugins dir, and the console will display it nice and pretty. It does use the RHQ plugin container embedded in it. Think of this as an embedded RHQ agent, so no seperate server or agent to start up.
So its dependencies are
Seam
JSF
RichFaces
JSTL
JDom
3 apache commons jars
RHQ core
2) Plugins
You include whatever plugins you want the UI to display. This is the only thing for the UI that you will need to create. Mazz gave you all the info about plugins and what they need.
The plugin's dependencies are anything it needs to communicate to what it plans to manage and monitor. In a lot of cases it might already have been provided for you. In looking at our plugins, it is only the jmx-plugin that has one jar with it for the EMS library that it uses.
3)Your Management Interface for JBM.
Now this is completely up to you. All the plugin will need is an ability to connect to it, locally or remotely. Remotely more for everyone to re-use your plugin in other servers. So you can choose any transport you want. You just might need to include that transports jar files in the plugin jar.
Let me use an example of the AS 5 plugin.
AS 5 has the Profile Service which is the management interface that AS 5 exposes (3). In the AS 5 plugin, it simply does a JNDI lookup for the profile service and then just codes to that api. In the rhq-plugin.xml I define my resources and what props, metric statistics and operations each resource type can expose (2).
I simply drop the AS 5 plugin into the plugins directory of the Embedded Console war and now the Console manages and monitors AS 5 (1).
So the dependencies are very small, the JON team designed and built it such that it was as simple as possible for plugin developers to add management and monitoring capabilities to their products.
I hope that helps.
Thanks
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4130901#4130901
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4130901
18 years, 1 month