initial i18n work is complete
by Joseph Marques
The initial work for internationalizing the web application is now
complete. You can see the tokens with their values in:
...coregui/src/main/resources/org/rhq/enterprise/gui/coregui/client/Messages.properties
If you want to add translations for other languages, all you need to do
is add another file in the same directory suffixed with the locale like so:
...coregui/src/main/resources/org/rhq/enterprise/gui/coregui/client/Messages_de.properties
Once the translation is complete, go to CoreGUI.gwt.xml and enable that
localization in the build:
<extend-property name="locale" values="de" />
Keep in mind that due to the fact that we're using the static string
initialization technique [1], this will lengthen the overall build time
when you do this. If you were previously compiling two versions of the
application - one for FF, one for WebKit - this will now double the
number of compilation permutations - one for FF 'en', one for FF 'de',
one for WebKit 'en', and one for WebKit 'de'.
Once built, you can access the translated web application by going to:
...CoreGUI.html?locale=de
Keep in mind that when you switch locales, it's effectively loading an
entirely different application because the translated strings are
compiled directly into each permutation separately, thus you'll
experience the initial download/startup time again). There are other
ways to invoke the correct localized application, such as <meta> tags
and property providers [2], but we can cross that bridge a bit later.
Note: the Messages*.properties files should use UTF-8 encoding, which
will allow Unicode characters to be used directly in the properties.
I've already added the necessary <meta> tag to CoreGUI.html, to support
rendering correctly:
<meta http-equiv="content-type" content="text/html;charset=utf-8" />
If you have any questions, feel free to ping back.
-joseph
[1] -
http://code.google.com/webtoolkit/doc/latest/DevGuideI18n.html#DevGuideSt...
[2] -
http://code.google.com/webtoolkit/doc/latest/DevGuideI18nLocale.html#Loca...
13 years, 5 months
questions about (proposed changes for) role--group authz
by Joseph Marques
See questions below...
On 11/15/2010 03:02 PM, ips wrote:
> modules/enterprise/gui/coregui/src/main/java/org/rhq/enterprise/gui/coregui/client/admin/roles/RolesDataSource.java | 23 +++++++---
> modules/enterprise/gui/coregui/src/main/java/org/rhq/enterprise/gui/coregui/client/admin/users/UserEditView.java | 2
> 2 files changed, 18 insertions(+), 7 deletions(-)
>
> New commits:
> commit 9315519acb694b4147a598f5258c5ffb95b7ce2e
> Author: Ian Springer<ian.springer(a)redhat.com>
> Date: Mon Nov 15 15:01:58 2010 -0500
>
> don't attempt to fetch subjects or resourceGroups for a Role unless the logged-in user has MANAGE_SECURITY
>
> modules/enterprise/gui/coregui/src/main/java/org/rhq/enterprise/gui/coregui/client/admin/roles/RolesDataSource.java
>
> @Override
> @@ -99,6 +108,7 @@ public class RolesDataSource extends RPCDataSource<Role> {
> ...
> - criteria.fetchResourceGroups(true);
> criteria.fetchPermissions(true);
> - criteria.fetchSubjects(true);
> - // TODO: Uncomment this.
> - //criteria.fetchLdapGroups(true);
> +
> + if (this.globalPermissions.contains(Permission.MANAGE_SECURITY)) {
> + criteria.fetchSubjects(true);
> + criteria.fetchResourceGroups(true);
> + }
Fetching subjects should indeed be hidden behind MANAGE_SECURITY, but
should we allow a user with MANAGE_INVENTORY to be able to fetch the
corresponding groups for that role?
Looking further into this, I notice the same in RoleCriteria, where if
either of those fetches are specified then the user requires
MANAGE_SECURITY. Should the implementation instead be?
class RoleCriteria {
isSecurityManagerRequired() {
return this.fetchSubjects;
}
isInventoryManagerRequired() {
return this.fetchResourcesGroups;
}
}
>
> return criteria;
> }
> diff --git a/modules/enterprise/gui/coregui/src/main/java/org/rhq/enterprise/gui/coregui/client/admin/users/UserEditView.java b/modules/enterprise/gui/coregui/src/main/java/org/rhq/enterprise/gui/coregui/client/admin/users/UserEditView.java
> index adc834b..857ea0c 100644
> --- a/modules/enterprise/gui/coregui/src/main/java/org/rhq/enterprise/gui/coregui/client/admin/users/UserEditView.java
> +++ b/modules/enterprise/gui/coregui/src/main/java/org/rhq/enterprise/gui/coregui/client/admin/users/UserEditView.java
> @@ -126,7 +126,7 @@ public class UserEditView extends AbstractRecordEditor<UsersDataSource> {
> //
> private boolean areRolesReadOnly(Record record) {
> boolean isLdap = Boolean.valueOf(record.getAttribute(UsersDataSource.Field.LDAP));
> - return (!hasManageSecurityPermission || (getRecordId() == SUBJECT_ID_RHQADMIN) || isLdap);
> + return (!hasManageSecurityPermission || (getRecordId() == SUBJECT_ID_RHQADMIN) || isLdap);
I agree that editing the subjects and/or permissions for that role
should be constrained to those with MANAGE_SECURITY, but should a user
with MANAGE_INVENTORY be able to edit the resource groups associated
with the role?
13 years, 5 months
code review for {Group}{Plugin|Resource}ConfigurationUpdateCriteria
by Joseph Marques
Mazz, as requested...
> commit cec59ed94fc58149083943bcafcc2e94abc71359
> Author: John Mazzitelli<mazz(a)redhat.com>
> Date: Mon Nov 15 01:24:01 2010 -0500
>
> /modules/core/domain/src/main/java/org/rhq/core/domain/criteria/AbstractConfigurationUpdateCriteria.java
> ...
> +public abstract class AbstractConfigurationUpdateCriteria extends Criteria {
> + private static final long serialVersionUID = 1L;
> +
> + public static final String SORT_FIELD_CTIME = "ctime";
> + public static final String SORT_FIELD_STATUS = "status";
> +
> + private Integer filterId;
> + private Long filterStartTime; // requires overrides
> + private Long filterEndTime; // requires overrides
AbstractConfigurationUpdate has both createdTime and modifiedTime
fields. So I would either:
1) have filter{Created|Modified}{Start|End}Time filter pairs, or
2) keep the single filter{Start|End}Time pair, but change the generated
query fragments to "createdTime > :startTime" and "modifiedTime <
:endTime" respectively
> ...
> + public AbstractConfigurationUpdateCriteria() {
> +
> + filterOverrides.put("startTime", "ctime>= ?");
> + filterOverrides.put("endTime", "ctime<= ?");
> +
> + sortOverrides.put(SORT_FIELD_STATUS, "status");
> + }
Note, "ctime" should have been "createdTime", otherwise those filters
would have generated a query that didn't parse.
> modules/core/domain/src/main/java/org/rhq/core/domain/criteria/AbstractGroupConfigurationUpdateCriteria.java
> ...
> +public abstract class AbstractGroupConfigurationUpdateCriteria extends AbstractConfigurationUpdateCriteria {
> + private static final long serialVersionUID = 1L;
> +
> + private List<Integer> filterResourceGroupIds; // requires override
> +
> + public AbstractGroupConfigurationUpdateCriteria() {
> + filterOverrides.put("resourceGroupIds", "group.id IN ( ? )");
> + }
> +
> + public void addFilterResourceGroupIds(List<Integer> filterResourceGroupIds) {
> + this.filterResourceGroupIds = filterResourceGroupIds;
> + }
> +}
Please change the signature to take varargs and use
CriteriaUtils.getListIgnoringNulls. Here's the JDoc snippet for the
utility method:
/*
* remove nulls from the passed items, and return the resultant
list. return null if no non-null items exist.
* this is useful in criteria addFilterXXX methods which take
varargs, where a single null argument should be
* interpreted as a null collection (instead of one-item collection
whose first value is null).
*/
How is this used in practice? In an attempt to try and simplify the
programming model for adding search/filtering to our views, the "S[]
get{Array}Filter(DSRequest, String, Class<S>)" methods were added to
RPCDataSource. Here is a snippet of how simple it is to pull an array
of types out of the request using these helper methods.
AlertDataSource {
AlertCriteria getCriteria(DSRequest request) {
..
criteria.addFilterPriorities(getArrayFilter(request,
"severities", AlertPriority.class));
...
}
}
By returning an array, it's possible to pass that result directly to the
addFilterXXX varargs method, which CriteriaUtils then does further
processing on to ensure that the private member variable removes
elements that would generate invalid queries.
Also, varargs better supports the case where you only have one element
to filter one. From the interactive console / CLI and remote API
standpoints, it's easier just to pass a single element directly, rather
than having to wrap it in a collection.
> ...
> modules/core/domain/src/main/java/org/rhq/core/domain/criteria/PluginConfigurationUpdateCriteria.java
> ...
> +public class PluginConfigurationUpdateCriteria extends AbstractResourceConfigurationUpdateCriteria {
> ...
> + private List<Integer> filterResourceGroupIds; // requires overrides
> ...
> + public PluginConfigurationUpdateCriteria() {
> ...
> + filterOverrides.put("resourceGroupIds", "resource.id IN " //
> + + "( SELECT res.id " //
> + + " FROM ResourceGroup rg " //
> + + " JOIN rg.explicitResources res " //
> + + " WHERE rg.id = ? )");
Since resourceGroupIds is a collection, you need to say "where rg.id IN
( ? )". In other words, it needs to be an in-clause that contains a
sub-query with an in-clause. An example of this style is the
"explicitResourceIds" filter in ResourceGroupCriteria.
> ...
> + public void addFilterResourceIds(Integer... filterResourceIds) {
> + this.filterResourceIds = Arrays.asList(filterResourceIds);
> + }
> +
> + public void addFilterResourceGroupIds(Integer... filterResourceGroupIds) {
> + this.filterResourceGroupIds = Arrays.asList(filterResourceGroupIds);
> + }
See discussion about using CriteriaUtils above.
> modules/core/domain/src/main/java/org/rhq/core/domain/criteria/ResourceConfigurationUpdateCriteria.java
The following two issues were pre-existing:
The query fragment for "explicitResourceIds" in
ResourceConfigurationUpdateCriteria has the same issue as
"filterResourceGroupIds" PluginConfigurationUpdateCriteria above did.
The sub-query needs to use "WHERE rg.id IN ( ? ) " as opposed to "WHERE
rg.id = ? "
The varargs methods for ResourceConfigurationUpdateCriteria should
leverage CriteriaUtils.
13 years, 5 months
NPE after server bounce
by Heiko W.Rupp
Had the UI loaded when I bounced the server.
This created the following repeatedly in the logs
18:22:51,306 ERROR [[/coregui]] Exception while dispatching incoming RPC call
com.google.gwt.user.server.rpc.UnexpectedException: Service method 'public abstract org.rhq.core.domain.util.PageList org.rhq.enterprise.gui.coregui.client.gwt.AlertGWTService.findAlertsByCriteria(org.rhq.core.domain.criteria.AlertCriteria)' threw an unexpected exception: java.lang.RuntimeException: javax.ejb.EJBException:java.lang.NullPointerException -> java.lang.NullPointerException:null
at com.google.gwt.user.server.rpc.RPC.encodeResponseForFailure(RPC.java:378)
at com.google.gwt.user.server.rpc.RPC.invokeAndEncodeResponse(RPC.java:581)
at com.google.gwt.user.server.rpc.RemoteServiceServlet.processCall(RemoteServiceServlet.java:188)
at com.google.gwt.user.server.rpc.RemoteServiceServlet.processPost(RemoteServiceServlet.java:224)
at com.google.gwt.user.server.rpc.AbstractRemoteServiceServlet.doPost(AbstractRemoteServiceServlet.java:62)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:710)
at org.rhq.enterprise.gui.coregui.server.gwt.AbstractGWTServiceImpl.service(AbstractGWTServiceImpl.java:73)
13 years, 5 months
Time outs (on import)
by Heiko W.Rupp
I was trying to import a few resources.
Import failed and stuff was in the AD portlet.
I retired and got an error:
Caused by: java.lang.RuntimeException: javax.ejb.EJBException:java.lang.IllegalArgumentException: Can only commit resources with status: [COMMITTED] -> java.lang.IllegalArgumentException:Can only commit resources with status: [COMMITTED]
at org.rhq.enterprise.gui.coregui.server.gwt.ResourceGWTServiceImpl.importResources(ResourceGWTServiceImpl.java:289)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
After looking I saw that the resources actually were all in inventory already.
So basically it looks like this ran into a GWT session timeout so display was hosed,
but the backend continued to process stuff.
I know Mazz increased timeouts recently (Mazz?), so this may not happen that often,
but I still think that after some timeout the UI should try to reload the screen in
order to sync with the backend.
What am I missing here?
Heiko
--
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, 5 months
Oddity in prepare-wsdl of remoting ws client module
by Heiko W.Rupp
This module prints
prepare-wsdl:
[echo] *** Creating new wsdl
[echo] The JAVA HOME being used: /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home
[echo]
And then fails
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-antrun-plugin:1.6:run (client-distribution) on project rhq-remoting-webservices: An Ant BuildException has occured: The following error occurred while executing this line:
[ERROR] /im/rhq/modules/enterprise/remoting/webservices/src/main/scripts/rhq-client.build.xml:55: The following error occurred while executing this line:
[ERROR] /im/rhq/modules/enterprise/remoting/webservices/src/main/scripts/rhq-client.build.xml:123: Directory /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/lib creation was not successful for an unknown reason
Build lines in question are:
<mkdir dir="${java.jre.home}/lib" />
<mkdir dir="${java.jre.home}/../lib" />
java.jre.home/lib usually is a system dir - why would the script want to mkdir it?
Also java.jre.home/../lib is usually in system directories.
This may be an Apple VM issue, but it is strange anyway.
Heiko
--
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, 5 months
alignment of members of SmartGWT Canvases
by Ian Springer
I have been struggling the past few days to figure out why the members
within a HLayout (specifically, this.hlayout in AbstractSelector) were
being right-aligned. Nowhere had I specified to align anything to the
right. I kept explicitly specifying left alignment everywhere I could
think of, but still the members remained aligned to the right. This
afternoon, I finally figured it out. I had the following in my HLayout:
this.hlayout.setAlign(Alignment.LEFT);
this.hlayout.setAlign(Alignment.BOTTOM);
when I axed the this.hlayout.setAlign(Alignment.BOTTOM), the members
were left aligned and all was well.
So I took a look at the source for the two overloads of setAlign() in
the Layout class...
/**
* Alignment of all members in this Layout on the length axis.
Defaults to "top" for vertical Layouts, and "left" for horizontal Layouts.
*
* @param alignment alignment Default value is null
*/
public void setAlign(Alignment alignment) {
setAttribute("align", alignment.getValue(), true);
}
/**
* Alignment of all members in this Layout on the length axis.
Defaults to "top" for vertical Layouts, and "left"
* for horizontal Layouts.
*
* @param alignment alignment Default value is null
*/
public void setAlign(VerticalAlignment alignment) {
setAttribute("align", alignment.getValue(), true);
}
Notice, they both just set the "align" String attribute, so the second
call to setAlign() was just overwriting with "bottom" the value "left"
set by the first call. And for whatever reason (or more likely none at
all), Smart interprets "bottom" as right-align for an HLayout. My guess
is that their intention was for the VerticalAlignment method to only be
used for VLayouts, and the (horizontal)Alignment version to only be used
for HLayouts. If so, they should have split them up, one in the VLayout
class and the other in the HLayout class, rather than putting them both
in the Layout superclass. Or they should have had two underlying
JavaScript attributes - "align" and "verticalAlign", rather than just
"align". But as it stands, there's no way to specify both horizontal and
vertical alignment for a Layout (I think this is wrong - what do others
think?), and specifying vertical alignment on an HLayout will screw with
the horizontal alignment. So I think the rules of thumb are:
1) For HLayouts, only call setAlign(Alignment alignment) - do not call
setAlign(VerticalAlignment alignment)
2) For VLayouts, only call setAlign(VerticalAlignment alignment) - do
not call setAlign(Alignment alignment)
-- Ian
--
Ian Springer
Principal Software Developer
JBoss Operations Network
Red Hat
ian.springer(a)redhat.com
13 years, 6 months
GWTServiceLookup now supports custom timeouts
by John Mazzitelli
I committed a change to GWTServiceLookup so it can now support obtaining
manager proxies such that an RPC call can have a custom timeout.
The default timeout is now 10s. If you are in debug mode, all time outs
will be increased by an additional 30s. So if you are in debug mode, the
default timeout will be 40s. If you have a customized timeout of N
seconds, and you are in debug mode, the timeout will be N+30. (this
additional "fudge factor" is required since the gwt debug mode is much
slower than when running non-debug mode).
Today there is only one gwt service proxy that you can ask for a custom
timeout:
GWTServiceLookup.getResourceTypeGWTService(int timeout)
Since most of our proxies call methods that don't need very long
timeouts, we don't need extra APIs to customize the timeout (i.e. the
default is fine). Thus I only created this one for now (no need bloating
the code in GWTServiceLookup unnecessarily).
However, if you think you will need a service proxy with a custom
timeout, add a static method to GWTServiceLookup - just copy the one
no-arg method and add a "int timeout" param and pass that timeout value
to the secure() method. See that getResourceTypeGWTService as an example.
Note that, again, this will be a rare need and in fact we should strive
to have very fast RPC calls (subsecond should be the norm in this kind
of client-side/ajaxy/GWT style of app). However, today we may have
legacy queries/workflows that do take a long time to execute on the
server side. Until we can refactor things to work faster in this new
paradigm of gwt, this timeout feature will be useful.
13 years, 6 months
general RHQ feedback and roadmap
by Andreas Dietrich
Hello dear RHQ developers,
I just googled for "rhq roadmap" (this is what I found: https://fedorahosted.org/rhq/roadmap) and then had a look at the wiki (http://www.rhq-project.org/display/RHQ/Releases) and did not really find something similar.
... let's start a bit earlier so you could understand me as a production user (in the first place; in the second place a developer) ...
We as a company have quite some customers that want to have their machines and databases monitored. The same applies to our systems as well.
We have a self-developed monitoring tool in-place, but were searching for something more capable and extandable. In the end we decided to use RHQ.
Now that we are using it for quite some time and had to build quite a lot upon it to work for us, I would like you to give some feedback about how we use it, where the benefits are, what's missing and priorities we would see, where the development should go (I could research on existing ideas/feature issues etc. and create tons of feature requests, but I don't have the time and would like to summarize it for now).
Benefits:
- we can easily rollout RHQ agents to our platforms (Linux, Windows, AIX, HP-UX, ...) and it basically works (adjustments on JVM params necessary to stabelize agents on AIX, HP-UX)
- the setup of all the agents and the server takes some time, but it's not complicated
- we could rather easily integrate our own agent plugins (Oracle db monitoring, log file monitoring)
- we can setup alarms for our resources and manage them hierachically, with some useful bulk functionality (e.g. groups, templates, individual read-only rules)
- we can investigate issues based on detailed, aggregated and graphically represented data (enough and efficient for the monitoring itself and to track down potential problematic resources)
- there are much more, but the above is the essential part
Situation without our own modifications/extensions (most important first):
- managing up to 100 alerts per day is cumbersome (especially for maintenance situation on networks/tunnels and machines)
... the currently implemented screens and fitler pages are insufficient for this if you have a lot of resources and machines where alerts can't be ignored and deleted easily
( remember that one has to keep track of problems and is responsible for noticing details that might lead to future problems ... especially if it is on a b2b contract basis)
... a lot of this maintenance work is an essential part of our daily work and our customers and not so exceptional!
... we need auto-acknowledgement and deletion rules (combinable of customer / machine-regexp / resource-regexp / resource-type-regexp / resource-type-natkey*-regexp / resource-natkey*-regexp / alert-condition-type [AVAILABILITY|MEASUREMENT] / individually setable acknowledgement-status ["false", "recovered", "ignore", "todo", "maintenance", ... ] / start-time / end-time )
* natkey = natural key, e.g. "Platforms - Linux - CPU 0" or "mach1.company1.com - CPU 0"
-- all this must be managable in an easy to use (click- and scoll-optimized control view / dt. "Leitstand") (aggregated data displayed with meaningful colors, tooltips etc.)
(I will provide some anonymized screenshot if I have time to develop it so you have an idea how this looks like)
... imagine monitoring personal is informed via some notifications, now it needs to filter out the most critical customer/machine/database/resource that needs attention
... furthermore we need to fastly categorize or delete alerts so another person or myself do not have to deal with them again (or sees why it's there, who will work on it, what is planned todo there, how further similar alarms should be treated, ...)
- compatible groups do not inherit alert templates which makes them less useful
...e.g. a general "Log ERROR found" without some notification setup can't be modified for DB alerts "DB alert logs" group (e.g. we would like to get an email for this one)
- we can't auto-setup customer groups (the group definitions do not allow "and/or" conditions
... you can't say something like 'machine-*.area1.company1.com' and 'machine-*.area2.company1.com' belong to group 'company1'
- customers setup for RHQ usage (setup with view only rights on their group) can see all other users available
- of course there is more, but the above again are the more important to us (if I did not forget something ... I am in a hurry since I have a home office day and have to change the diapers of my son *puh* ;-))
I could write some more pages about this, but I think the alarm and resource management is the most important to work on for the current stage of the project.
I would leave e.g. the ongoing graphical enhancements (GWT, graph types) aside and concentrate on the essential and much more important features if it would be for our usage scenarios.
Of course I understand that a "fancy" looking project sells much better especially to managers, but if this is not an important point on the "roadmap" I would skip it for now and concentrate on the user that "does not like to use RHQ if possible". Because RHQ is only there to notice, track down and recover problematic resources", RHQ-setup and -cleanup are necessary evils that should be kept minimal. The real work (~95% of the time) should be spent on the problematic resource or some related one itself ... db setup/recovery, router, firewalls, os setup, application changes/restarts etc.
Kind regards
Andreas :-)
PS: Currently our own management overview is heavily based on Eclipse BIRT reports based itself on RHQ description XML tags (in description of inventories, alert definitions, groups), Oracle DB Views and Table Functions working over the RHQ DB. This is rather easy to implement and fast. We plan to extend it to utilize the RHQ client API to not only visualize the data, but modify it. Of course this is not nice since we should build this into RHQ itself. But it's easier to start with some DB schema you know than with the big RHQ monolith itself (We know hibernate, Struts, ADF, JSF and alike, but it's still hard to say for us how much time has to be spend then).
13 years, 6 months