How to make the changes of inventory connection effective in discovery component?
by Lin Gao
Hi:
If the value of one inventory connection is part of the resource
component name, how to make the resource component name reflecting the
changes of the inventory connection value.
below is an example:
rhq-plugin.xml:
<server name="HttpServer-Host" description="Http server host and port"
discovery="HttpHostDiscoveryComponent"
class="HttpHostResourceComponent"
supportsManualAdd="true">
<plugin-configuration>
<c:simple-property name="host" description="host of target http server" />
<c:simple-property name="port" description="port of target http server" />
</plugin-configuration>
</server>
HttpHostDiscoveryComponent.java:
public Set<DiscoveredResourceDetails> discoverResources(
ResourceDiscoveryContext<HttpHostResourceComponent> context)
throws InvalidPluginConfigurationException, Exception {
Set<DiscoveredResourceDetails> result = new
HashSet<DiscoveredResourceDetails>();
for(Configuration config: context.getPluginConfigurations()){
String host = config.getSimpleValue(PLUGIN_CONFIG_HOST_KEY,
null);
Integer port =
Integer.valueOf(config.getSimpleValue(PLUGIN_CONFIG_PORT_KEY, "80"));
String resourceKey = "HTTP_CHECK_" + host + ":" + port;
String resourceName = "Http Checker on: " + host + ":" + port;
String resourceVersion = "1.0.0";
String resourceDescription = "Http Checker on server: " +
host + ":" + port + ".";
DiscoveredResourceDetails resource = new
DiscoveredResourceDetails(context.getResourceType(), resourceKey,
resourceName, resourceVersion, resourceDescription, config, null);
result.add(resource);
}
return result;
}
If the host is defined to: 127.0.0.1 and port to: 80 when the server is
added manually, the name of this resource component in the navigate tree
is: "Http Checker on: 127.0.0.1:80", after that, if the host is
changed(inventory->connection->edit...), the name of the resource
component in the navigate tree is not changed, even re load the tree, so
how to make it changed also?
--
Best Regards
Lin Gao
JBoss Software Engineer
Red Hat China R&D Branch
IRC:lgao @ #jbosscn,#prod,#jbossas,#Eng-china
Phone: +86-10-6260-8252
Mobile Phone: +86-13811109928
E-Mail: lgao(a)redhat.com
13 years, 3 months
client-side synchronization (or lack thereof)
by Joseph Marques
On 12/21/2010 05:16 PM, Jay Shaughnessy wrote:
> modules/enterprise/gui/coregui/src/main/java/org/rhq/enterprise/gui/coregui/client/dashboard/DashboardView.java | 37 ++++++++--
> modules/enterprise/gui/coregui/src/main/java/org/rhq/enterprise/gui/coregui/client/dashboard/PortletWindow.java | 3
> 2 files changed, 34 insertions(+), 6 deletions(-)
>
> New commits:
> commit a2619e9946f686fdb50f161df01766d88964980f
> Author: Jay Shaughnessy<jshaughn(a)redhat.com>
> Date: Tue Dec 21 17:14:28 2010 -0500
>
...
> I've protected add/remove portlet using some synchronization but it we need
> to go further we may need to put a locking mechanism in place.
From the "Multithreading and Synchronization" section here --
http://code.google.com/webtoolkit/doc/latest/DevGuideCodingBasicsCompatib...
"JavaScript interpreters are single-threaded, so while GWT silently
accepts the synchronized keyword, it has no real effect.
Synchronization-related library methods are not available, including
Object.wait(), Object.notify(), and Object.notifyAll(). The compiler
will ignore the synchronized keyword but will refuse to compile your
code if the Object's related synchronization methods are invoked.
So this either needs to be remedied by disallowing further actions
(i.e., disabling buttons) until the first one completes, or by
persisting the individual dashboard delta (instead of the entire set of
portlets for the dashboard being modified) which would remove the race
condition.
13 years, 4 months
How to get the plugin configuration in parent resource ?
by Lin Gao
Hi, gurus:
I am fresher on RHQ plug-ins, I am writing a RHQ plug-in, and have a question on the plugin configuration:
My rhq-plugins.xml:
<plugin name="HttpCheck" displayName="Http Server Checker" ...>
<server name="Http Server Checker" discovery="HttpCheckServerDiscoveryComponent" class="HttpCheckResourceComponent">
<server name="HttpServer-Host" supportsManualAdd="true" discovery="HttpHostDiscoveryComponent" class="HttpHostResourceComponent">
<plugin-configuration>
<c:simple-property name="host" ... />
<c:simple-property name="port" type="integer" ... />
</plugin-configuration>
<service name="HttpServer-Path" supportsManualAdd="true" discovery="HttpPathDiscoveryComponent" class="HttpPathResourceComponent">
<plugin-configuration>
<c:simple-property name="path" ... />
</plugin-configuration>
</service>
</server>
</server>
</plugin>
The idea of this plugin is to check the specified path of one http server whether it is available.
In the
HttpPathResourceComponent.start(ResourceContext _context){
Configuration config = context.getPluginConfiguration();
String path = config.getSimpleValue("path", "/"); // Here get the path configuration
//TODO: How to get the host and port here ??
//TODO: What is the best practice to get the plugin configuration in parent resource ??
}
--
Best Regards
Lin Gao
13 years, 4 months
deploying ear/war bundle issue
by John Mazzitelli
I'm looking at the following BZ:
https://bugzilla.redhat.com/show_bug.cgi?id=659142
I was going to make this a setting in the ant recipe but figured I'd ask
for input just in case I'm missing something.. see comment here:
https://bugzilla.redhat.com/show_bug.cgi?id=659142#c5
This feature will only be supported by the ant bundle type regardless of
how we do it (see my comment #6).
For reasons I state in my comment #5, I'm leaning towards adding this
setting somehow in the recipe.. probably this:
<rhq:deployment-unit name="my-war" leaveTopDeployDirAlone="true">
where "leaveTopDeployDirAlone" is this new setting. BTW: I don't plan on
using that name - I need suggestions, I can't think of a good name for
this setting. Its supposed to mean: "this bundle will be deployed in a
directory where other files are - those other files must remain intact
so don't try to manage that top deploy directory and leave all files
there alone". But I need that said in a single word or two or three for
this attribute name :)
13 years, 4 months
Server-start wait seems to be computed wrong
by Heiko W.Rupp
Just saw this after my server was down for > 45mins
10:43:37,695 INFO [[/]] initializer: Forcing the server to wait [39540]ms to ensure agents know we went down
There must be some issue with computing that delay.
--
Reg. Adresse: Red Hat GmbH, Otto-Hahn-Strasse 20, 85609 Dornach bei München
Handelsregister: Amtsgericht München HRB 153243
Geschaeftsführer: Brendan Lane, Charlie Peters, Michael Cunningham, Charles Cachera
13 years, 4 months
PermissionsLoader
by John Mazzitelli
I introduced a new PermissionsLoader object and refactored all uses of
GWTServiceLookup.getAuthorizationService() so it uses the new loader.
This DOES NOT CACHE any permissions. However, it now provides a single
place where all loading of permissions will/should take place (assuming
everyone uses it now).
to use:
new PermissionsLoader().loadExplicitGlobalPermissions(new
PermissionsLoadedListener() {
public void onPermissionsLoaded(Set<Permissions> perms) {
...do your thing...
}
});
There are some benefits:
1) I looked at all uses of the AuthorizationService and they all had the
same pattern - onFailure() always logged a error message (but some
people duplicated Message.properties, even though they said basically
the same thing). onFailure rarely did anything else - if it did
something else, it was usually small, ~1 line of code. This
PermissionsLoader now provides you the onFailure code so we don't have
to cut-n-paste the same thing everywhere. And it therefore consistently
provides the same error message ("Failed to load the permissions - you
have none" or something like that). if you really need the exception
that occurred, you can get it from getLastError of the loader object
(but in all the usages of AuthorizationService, no one needed the
exception except to log it, which the loader now does for you).
2) You now only have to implement a single callback method -
onPermissionsLoaded. You will be given all permissions that you have as
the argument to that method - see javadoc for more.
3) We now have a single place where all permissions loading will take
place that will allow us to track the loading of permissions in the app
on the client side and will allow us to more easily introduce either a)
some caching in the future if we deem it necessary and/or b) code that
can help limit the amount of times we ask for the same kind of
permissions multiple times in the same request.
4) I cut down the number of lines of code needed and the code around
auth perm loading is now less cluttered.
13 years, 4 months
cobertura introduces bad ant dep
by John Mazzitelli
I had to fix the cobertura setup - specifically, I added a single line
to the root pom to put that dep in the test scope.
See:
https://bugzilla.redhat.com/show_bug.cgi?id=663517
and the BZ it blocks.
This was because it introduces a bad ant dependency that breaks the
bundle subsystem (and maybe others - cobertura jar and ant jar were
ending up in many places in the RHQ Server when they should not be since
they are for testing only).
Filip - I checked in the fix to master but I assigned that BZ over to
you to take a look and make sure that doesn't break anything. If it does
break, we can't go back to the way it was because it breaks bundles (you
can't create any bundles) so we'll need some other workaround.
In the meantime, using maven 2.2.1, my master builds ok and bundles are
working, but I did not run any tests or run with cobertura.
13 years, 4 months
plan for new GWT-based Operations GUI
by Ian Springer
Here is my current plan for the operations GUI. Comments welcome.
-- Ian
I. Scheduler widget
- new shared GWT widget that will allow user to define a schedule for
some action - user can choose to specify schedule using either a
multi-field form or a cron-syntax entry (see attached PDF for the
mockups from UXD)
- to support this we will need some new Trigger POJOs that will live
in core-domain - we cannot use the Quartz trigger classes as portal-war
does, because they would need to be gwt-compiled, and we don't want to
go there
--- the Trigger POJOs would be used by new OperationsManager SLSB
methods - e.g. scheduleOperationForResource(int resourceId, String
operationName, Configuration operationParams, String notes, Trigger trigger)
II. Abstract Base Classes for Operations Schedule and History
DataSources and Views
- to be subclassed for both Resource and Group Operations impl classes
III. Resource Operations Tab
A. Schedule subtab
- currently JSF iframe
- will consist of 2 parts - scheduled operation list view and
schedule new operation details view
- new operations detail view
--- everything will be on a single page
--- will have a pulldown menu with operation names at top of page -
when an operation is selected, its description and parameters (config
editor) will be displayed just below the pulldown menu
--- below the operation name/dsc/params will be the schedule form,
which will make use of the new scheduler widget
--- at the very bottom will be the Save, Reset?, and Cancel buttons -
these will be anchored at the bottom (i.e. they won't scroll vertically
with the rest of the view)
- details view for an existing scheduled operation will not be
supported in this first pass, but we hope to add that later
B. History subtab
- already ported to GWT, but details view doesn't work - need to fix that
- also look for bugs in the list view and fix any I find
IV. Group Operations Tab
A. Schedule subtab
- currently JSF iframe
- same as Resource subtab, except support for selecting serial versus
parallel, as well as ordering if serial
- any other differences?
B. History subtab
- currently JSF iframe
- same as Resource subtab, except support for drilling down on
operation results for each member of the group
- any other differences?
V. Other
- we may want to add a relation between a schedule and a Set of
history items, so we can display that correlation in the GUI
- Joe, Mazz - what else have I missed?
13 years, 4 months
review of commit ea30719
by Joseph Marques
> commit ea307199f414e3f155c4ababaabb5fee769c6c9c
> Author: Ian Springer<ian.springer(a)redhat.com>
> Date: Mon Dec 13 12:30:56 2010 -0500
>
> 2nd attempt at fixing subtab refresh when switching back to a subtab from another subtab on the same Resource or group, hopefully this time without breaking TableSection detail views (https://bugzilla.redhat.com/show_bug.cgi?id=661528); disable ack-all and delete-all buttons on alert history view if there are 0 alerts in the history
>
...
> modules/enterprise/gui/coregui/src/main/java/org/rhq/enterprise/gui/coregui/client/inventory/common/detai/AbstractTwoLevelTabSetView.java
> @@ -240,11 +240,12 @@ public abstract class AbstractTwoLevelTabSetView<T, U extends Layout> extends Lo
> if (subView instanceof BookmarkableView) {
> // Handle any remaining view items (e.g. id of a selected item in a subtab that contains a Master-Details view).
> ((BookmarkableView) subView).renderView(viewPath);
> - } else if (subView instanceof RefreshableView) {
> - if (subView.isDrawn()) {
> - // Refresh the data on the subtab, so it's not stale.
> - ((RefreshableView) subView).refresh();
> - }
> + }
> +
> + if (subView instanceof RefreshableView&& viewPath.isEnd()&& subView.isDrawn()) {
> + // Refresh the data on the subtab, so it's not stale.
> + Log.debug("Refreshing data for [" + subView.getClass().getName() + "]...");
> + ((RefreshableView) subView).refresh();
> }
>
> this.tabSet.markForRedraw();
Now I think we're dealing with a race condition. Since many
RefreshableViews are also BookmarkableViews, both checks may catch.
However, the renderView(ViewPath) method is not guaranteed to do all of
its work synchronously, so we may be calling refresh() before some or
all of the asynchronous work inside renderView(ViewPath) completes.
13 years, 4 months