Modularization of plugins
by Elias Ross
I was thinking, it'd be nicer if the standard plugins were all located
in a separate git repositories. It would make it easier to git clone,
and later extend/improve each of them without having the concern of
tracking the main project.
Of course, they are so many, it's not likely practical. Perhaps just
the plugins in one repository by itself?
You end up in a situation where you must first master doing the
complete build (which I haven't!) to contribute to one part of it. I
keep getting hung on GWT for some reason.
12 years, 12 months
Creation of child resources
by Heiko W.Rupp
Hi,
for as7, deploying an app is a 3 step process
- upload the file into the domain
- add it to the domain
- add it to a server group
Steps 1&2 are usually done in one go. But the user may select to have step 3 separately
(e.g. when uploading an app to the domain and then in turn activating it on 'test', 'integration' and
'production' server groups).
How can I tell the plugin (at server group level) via plugin descriptor to either
take an upload (works) or take it from some existing source?
Is the later possible at all?
Heiko
--
Reg. Adresse: Red Hat GmbH, Technopark II, Haus C,
Werner-von-Siemens-Ring 14, D-85630 Grasbrunn
Handelsregister: Amtsgericht München HRB 153243
Geschaeftsführer: Brendan Lane, Charlie Peters, Michael Cunningham, Charles Cachera
12 years, 12 months
Alternate plugin handling
by David A. Webster
This is another topic I have discussed with the JON/RHQ product team at
JBossWorld and via conference call; the notion of a finer grained plugin
model for RHQ.
RHQ and JON were initially designed to support standard, stock containers,
JBoss, Tomcat, etc... These containers have a consistency across the
Enterprise. We can count on every JBoss server to be, well, a JBoss
server no matter where it is deployed. It might have a few
customization's like Java startup options (-Dxxx) and a modified classpath
and few custom MBeans deployed, but bottom line, one JBoss or Tomcat
instance looks pretty much like any other instance.
The result is, from the server perspective, the plugin's are "pushed", or
at the agent side, the agent simply polls the JON server to periodically
pull any new or update plugins. The assumption being, that whatever is
running on the managed node is consistent with what is running everywhere
and all the registered plugins are pulled down to every agent attached to
the JON server instance.
As we have discovered here, JON/RHQ is also a potentially very powerful
tool for managing stand alone Java process as well. It's provisioning
mechanisms and ability to write custom plugins, in particular JMX plugins
makes it very attractive as a management platform for stand alone Java. We
code most of our services as Stand Alone using Spring IOC, thus no need to
host in a container.
The problem here is, the processes can all be very different from one
another, in particular, each set of processes may have a very unique set
of MBeans to manage that set. There is no high level of consistency from
instance to instance other than they are all running in a JVM. Therefore,
the global push (or from the agent perspective, the universal pull of
everything) kind of breaks down. If I have 250 stand alone JVMs, each
with a custom set of MBeans, each with it's own plugin to support those
MBeans, on each agent node, I get my plugin, but also get 249 other
plugins I have no interest in and lord knows what that does to my agent
JVM Heap or resource utilization?
Proposal would be the development of a new kind of plugin, the "private"
plugin, where you drop the plugin into the agent plugin deploy folder, not
the server, the agent reports the plugin to the server, the server exposes
it in inventory discovery, but the plugin only lives at the one agent it
was deployed to. What you end up with is the standard agent plugin that
is today "public", meaning it is blasted out to every agent the server
knows about, but another "private" one that handled and only exists on the
agent it was deployed to.
Not sure how much rework to the agent plugin system this would entail, but
it would make JON a much better tuned product to support large stand alone
Java environments like out.
David Webster
Union Pacific Railroad
Lead Architect-Web Infrastructure
Systems Engineering
Phone: (402) 544-1094 | Email: dawebster(a)up.com
12 years, 12 months
Dashboard portlet names
by Heiko W.Rupp
Hi,
I had started after a clean install my RHQ UI in Japanese locale and then later switched to German.
That mostly works great, except for the names of the Dashboards:
This sounds odd - will users use RHQ in a multilanguage environement, where they sometimes start
the English and sometimes the Japanese UI ?
I think this behavior would be very inconvenient for them.
Deleting the Dashboard will bring a new clean one in the current language back,
but this is perhaps no option for those multilanguage users.
Heiko
12 years, 12 months
RHQ Feature updates or bugs?
by David A. Webster
Having just returned from JBossWorld and having had some very fruitful
discussions with the JON team, Alan Santos and Charles Crouch, it was
suggested that we (Union Pacific Railroad) register with the RHQ project
and submit some of our internal research here, so as to be considered for
inclusion into future releases of JON. I am not entirely clear on the
best way to submit code as I am not sure whether these constitute "bugs"
or are more complicated feature requests. Will await guidance before
proceeding on these.
I have three specific issues to cover on the product that concern two
specific JON or RHQ plugins; the Generic JMX plugin and the Tomcat plugin
1) The "extensibility" of the Generic JMX plugin is a problem because
some the class members are declared "private" and really should be
"protected". If they aren't obvious from the code samples we can provide,
I can confer with my internal developers as to what specific class members
are applicable.
2) Ability to attach to a local JVM's MBean server without the need for a
JMX remoting. We have written a new Generic JMX plugin that makes use of
the Java Attach API to enable the RHQ agent to discover JVMs that are not
exposed via JMX remoting. These JVMs must be running under the same OS
user account as the agent. This is critical to large enterprise
operations that do not want to manage hundreds or thousands of JVM JMX
ports and all the security implications that entails. This will also
allow us to use JON/RHQ to manage our vast array of Stand Alone Java
process. I have code I would like to submit that demonstrates this. The
idea is that it should, most likely, be rolled into the standard Generic
JMX plugin
3) Expose Tomcat JNDI Datasources in the Tomcat Plugin. This has
notoriously been missing from the standard Tomcat plugin in JON 2.x and
RHQ 3.x. It exposes deployed applications but not container configured
datasources. I have a sample Tomcat datasource plugin, but I imagine it
should be part of the standard Tomcat plugin.
Of lesser concern are:
1) Allow for re-deployment of applications to Tomcat. Today, if an
application already exists, the deployer throws an error that it already
exists, forcing you delete the application and the deploy it again in a
two step procedure. Should be able to simply redeploy any war file.
Probably a bug and will enter a bugzilla report if I cannot find a
reference to it the bug reports but may be a "feature request", not sure.
This may already be in RHQ 4.0...
2) Ability to use custom startup scripts and pass parameters to them for
the stop/start/recycle for the standard JBoss EAP/EWP plugin. Today, you
cannot pass any custom startup parameters to JBoss EWP/EAP stop/start.
This is probably a "bug" and I can submit a Bugzilla report on it, if it
has not already been addressed.
3) Standard Stand Alone JVM start/stop plugin -- allows for a standardized
script and GUI to start, stop, recycle or get status info on any JVM
process, container or not. The standard script contains start(), stop(),
recycle(), and status() that can then call very detailed dependent scripts
to manage the application lifecycle of any JVM. A critical part of using
JON to manage stand alone Java processing. This is currently embedded in
our re-vamped Generic JMX plugin, but could/should be broken out into a
separate plugin or added to something else.
Regards,
David Webster
Union Pacific Railroad
Lead Architect-Web Infrastructure
Systems Engineering
Phone: (402) 544-1094 | Email: dawebster(a)up.com
12 years, 12 months
version updated to 4.1.0-SNAPSHOT in master (commit de10090)
by Ian Springer
This means next time you pull, you'll need to do a "mvn clean
-Penterprise && mvn install -Penterprise" from the root. Note, if you
get errors from mvn clean that it can't find such and such module just
use "find . -name target | xargs rm -rf" instead.
13 years
Fwd: RHQ plugins on OSGI
by Heiko W.Rupp
Can we help Galder?
Anfang der weitergeleiteten E-Mail:
> Von: Galder Zamarreño <galder(a)redhat.com>
> Datum: 6. Mai 2011 16:55:35 MESZ
> An: "Heiko W.Rupp" <hrupp(a)redhat.com>
> Betreff: RHQ plugins on OSGI
>
> Hi Heiko,
>
> Congrats on the 4.0 release of RHQ. We're however dependant on https://bugzilla.redhat.com/show_bug.cgi?id=657754 in order to make Infinispan work in an OSGI environment.
[16:57:43] <pilhuhn> galderz what exactly do you need ?
[16:59:09] <galderz> pilhuhn: https://bugzilla.redhat.com/show_bug.cgi?id=657754 - basically modifying the build so that the annotation jars are compatible with OSGI
[16:59:27] <pilhuhn> this is only for the pluginAnnotations module - right?
[16:59:51] <galderz> pilhuhn: yeah, but maybe also rhq-helpers and rhq-parent
[17:01:31] <pilhuhn> that scares me
13 years
IE links (BZ 697590)
by Ian Springer
The native event handler code is checked into master and working nicely
(see CoreGUI.onPreviewNativeEvent()). Currently, the event override code
only executes if the browser is IE. However, I am thinking we may want
to always execute it, no matter what the browser is, so that we can call
CoreGUI.goToView() and leverage the "stay on the same subtab when
switching from a resource or group details view to another resource or
group details view" logic provided by that method. That way, if the user
is at the Inventory>Children subtab for resource A and clicks on A's
child resource B, they will be taken to the Inventory>Children tab for
resource B, rather than its default subtab (Summary>Activity). However,
I can't think of any other use cases besides Inventory>Children off the
top of my head, so maybe it's not worth doing. What do you think?
https://bugzilla.redhat.com/show_bug.cgi?id=697590
13 years
RHQ 4.0.0 has been released
by Heiko W.Rupp
Hello,
it is my pleasure to announce the release of RHQ 4.0.0
Then months of hard work have passed since RHQ 3.0.0 ...
... and they have brought
• new SmartGWT-based GUI
• support for Postgres 9.0
• support for deleting Agent plugins
• support for executing an RHQ CLI script when an alert fires (for more info, see this blog)
• improved authorization for content repositories - public/private repos, repo owners, and MANAGE_REPOSITORIES priv
• Much improved MySQL agent-plugin (by Steve Milidge)
• New logfile alert-sender (by Steve Milidge)
and much more.
Check out the release notes at http://rhq-project.org/display/RHQ/Release+Notes+4.0.0
and the binary from http://sourceforge.net/projects/rhq/files/rhq/rhq-4.0.0/
Thanks to everyone who has contributed to this effort; be it via code contributions, bug reports or cookies :)
Heiko (on behalf of the RHQ team)
--
Reg. Adresse: Red Hat GmbH, Technopark II, Haus C,
Werner-von-Siemens-Ring 14, D-85630 Grasbrunn
Handelsregister: Amtsgericht München HRB 153243
Geschaeftsführer: Brendan Lane, Charlie Peters, Michael Cunningham, Charles Cachera
13 years