10:59 a.m.
On 1/11/11 10:21 AM, Heiko W.Rupp wrote:
Am 11.01.2011 um 16:55 schrieb Jason T. Greene:
> Retrofitting existing plugins for AS functionality is a non-option. They
> have to be integration with the domain APIs, else we just can't do
> unified configuration.
I completely understand your point.
The point I am trying to make is that users / projects have written
management plugins for RHQ/JON as they are the people that know their stuff.
Now not using this, but re-doing via domain imposes either a burden on AS
guys to rei-mplement or on the project to re-implement.
Yes but we can only consider options that meet the requirements.
Unfortunately this is just the cost of making a paradigm shift.
The current RHQ model is one where the AS plugin can have other
plugins
as children so that subsystems appear in the tree "in natural position". So
if a user e.g. installs portal on EAP, he would take the portlet-plugin, drop to
console and be able to monitor his portal.
Displaying it in the proper "place" is only part of the problem. Getting
the updates to apply correctly and consistently according to a
multi-node topology and it's policies is the real challenge. Also the
console is only one of the interfaces we are supposed to provide the
user (per requirements). Another is an API and a CLI. All of the
interfaces are supposed to be completely consistent.
>> But is this an actual requirement?
>
> I have not seen any requirements on reusing existing RHQ plugins. I am
> not sure what the JON schedule is, but at some point it will be updated
> to use the AS7 domain APIs, and I assume that the JON team will likely
> use an RHQ plugin to do that, since that is their architecture.
JON / RHQ would have a plugin that talks to the domain and discover and manage
stuff via this.
Nowadays JON has the base AS plugin which does the base stuff and a HornetQ plugin
which talks to HornetQ via JMX.
With the full domain management, either the RHQ team writes an AS plugin with the
knowledge of all (future) subsystems in it or we decompose again. Which means that
in this example the HornetQ team writes another plugin that goes through domain to
obtain
metrics and does configuration. I do not think the HornetQ guys will be happy to write
another
plugin.
The HQ subsystem in AS7 is mostly complete. They provide an internal API
that we build an AS subsystem on that adds the details to the domain.
Again, using the JMX plugin is a non-option. When someone changes an HQ
setting on a server group with 3 servers, it must be applied to all 3
servers, and it must show up in the configuration file and in the user
exposed domain API. This is what we have already acheived.
And the same will apply to customers who have written their specific
management stuff
and which they would need to re-do for AS7.
Having said this, I can imagine some way where the plugins (if they are JMX based) would
call via JMX plugin, but this one would intercept the calls and do them via domain
instead.
But I do not see management plugin code duplication as a good idea. Plugins for
subsystems
should be written by the subsystem owners and not by RHQ/JON nor by Base AS.
It's not really duplication as much as replacement. The whole concept of
domain management in the AS requires that the AS do the domain
management. There is just no way around that.
--
Jason T. Greene
JBoss, a division of Red Hat