Need advice about agent plugin design
by Steven North
I am trying to design an RHQ/JON agent plugin to manage a software
resource with the following characteristics:
- there is the software itself (the installation);
- there are a variable number of "bundles" of configuration information
about 250KB in size each which need to be read from and written to the
agent; and
- there are "log" files which can 10-50MB in size each which need to be
read from the agent.
I think I am pretty clear on how to handle the software itself--just
like any number of other agents.
I am not sure how to handle the configuration bundles and the large log
files.
We might want to have the RHQ/JON server manage different versions of
these configuration files and distribute them to multiple remote agents.
Is there some existing domain object that would handle the read/write
aspect of the configuration bundles (zip files)? Could the "package"
concept be used for these? Would we need to create a new domain object
on the server side for these bundles? If so, is there an example of
this kind of thing?
For the log files, I see some mention of the SupportFacet. Would this
be appropriate for retrieving large log files? Is there an example of this?
We expect to access the configuration bundles and the log files using
remote client operations because we have a separate GUI tool to
build/edit the configuration bundles and to correlate and analyze the
log files. Is there an example of using a remote client to pull files
from and push files to remote agents?
Thanks in advance for any advice you can give or examples you can point to.
Steve
10 years, 1 month
Availability collection interval defaults
by Jay Shaughnessy
In [most likely] RHQ 4.4 there will be several improvements to
Availability collection and handling. One of the major changes is
/Prioritized Availability Collection/.It means plugin developers can
optimize their types to set out of box availability collection
intervals. And users can alter the interval at template/group/resource
granularities. The inherent difficulty, like other default metric
enablement/collection interval settings, is how to decide what the
settings should be.Out of box we want to be conservative while still
being useful.
There are two topics that need discussion, the built-in defaults and how
to approach the plugin-specific overrides.
_*Built-In Defaults*_
The current defaults are based on category; server types are set to 1
minute and service types to 5 minutes.This actually increases avail
checking as previously everything was 5 minutes. These defaults are not
set in stone, they are just numbers I picked.
The 1 minute server default aims to increase the avail checking on types
that are more likely to be important. This affects a small percentage
of types and so far everyone has informally agreed that this seems like
a good setting. Of course plugin descriptors can override the default.
The 5 minute service default simply maintains the default avail scan
period from earlier versions, giving a nod to backward compatibility.
This setting can easily be debated. Increasing the default to, say 10
or 15 minutes, would give immediate performance benefit out of box. As
the majority of resources would be checked less often. This raises a
few fundamental questions: Is slow avail checking even useful? is
backward compatibility even relevant here? Is a slow default a good
idea seeing that plugins can easily override the defaults, and users can
further optimize their settings?
Note also that availability collection can now be disabled on a type,
out of box. Which means that it will immediately be assigned the avail
of its parent. This is likely appropriate for any component that simply
returns UP in its getAvailability() implementation.
*_Plugin-specific Overrides_*
To be clear, it is a goal that our most critical plugins be optimized
out of box to better today's performance, increase avail checking for
the most important resources and lessen or disable avail checking for
less important resources. The question is, who knows what these
settings should be? How do we go about making these setting changes?
Please chime in with your thoughts.
12 years, 1 month
Arquillian integration
by Lukas Krejci
Hello,
This is just a short notice about and an introduction to the integration between Arquillian testing framework and RHQ's plugin container.
What does this all mean, you say?
We have a long term problem with the not-so-easy testing of our agent plugins. This work is not going to make that a breeze, but will help you get over one of the hurdles.
If you were a plugin developer, you'd know that setting up a plugin container in your tests so that you could do some testing on your code while running in a real "agent-like" environment required quite a bit of setup - you'd have to collect the jars of plugins your plugin is dependent upon, stash them in some directory, create another directory for the "data" the plugin container or plugins can store away, configure the plugin container to use these and then finally start it up. This required both maven and code magic to get in all working. Not impossible but inconvenient to the point where we didn't really bother unless absolutely necessary.
If, God forbid, you had to test the plugin container itself and use a bunch of plugins to test upgrade/deployment/classloading/dependency issues, you know all too well how difficult that was.
Now consider this code:
@PluginContainerInstance(discoverServers = true)
public class MyClass extends Arquillian {
@Deployment(name = "simplePlugin")
public static RhqAgentPluginArchive getTestPlugin() {
return ShrinkWrap.create(RhqAgentPluginArchive.class, "test-plugin-1.0.0.jar")
.addClasses(TestDiscoveryComponent.class, TestResourceComponent.class)
.setPluginDescriptor("test-rhq-plugin.xml");
}
@DiscoveredResources(plugin = "testPlugin", resourceType = "TestServer")
private Set<Resource> testResources;
@Test
public void testPluginDeployed() {
Assert.assertEquals(testResources.size(), 1, "There should be one resource with the test type");
}
}
This deploys the plugin that consists of one resource type with TestDiscoverComponent as its discovery class and TestResourceComponent as its component class defined by the test-rhq-plugin.xml plugin descriptor. Prior to each test, there is going to be a server discovery and the discovered resources (for a specified resource type) are going to be stashed in a field. The test code can then easily check the discovery results and see if all data on the resources were correctly set. This is of course skimming over a lot of details - mainly how to set up your environment so that the discovery code of your resource type discovers what you expect, but that part is actually beyond the scope of arquillian integration (even though you *can* use arquillian to startup JBossAS for example).
Now imagine that your plugin depends on other plugins - remember those antrun stanzas we have in virtually every plugin pom?
@PluginContainerInstance(discoverServers = true)
public class MyClass extends Arquillian {
@Deployment(name = "simplePlugin")
public static RhqAgentPluginArchive getTestPlugin() {
return ShrinkWrap.create(RhqAgentPluginArchive.class, "test-plugin-1.0.0.jar")
.addPackages(true, "org.rhq.plugins.myPlugin")
.setPluginDescriptor("test-rhq-plugin.xml")
.withRequiredPluginsFrom(
DependencyResolvers.use(MavenDependencyResolver.class).includeDependenciesFromPom("pom.xml")
.resolveAs(JavaArchive.class, new ScopeFilter("compile", "runtime")));
}
@DiscoveredResources(plugin = "testPlugin", resourceType = "TestServer")
private Set<Resource> testResources;
@Test
public void testPluginDeployed() {
Assert.assertEquals(testResources.size(), 1, "There should be one resource with the test type");
}
}
There are 2 changes from the previous example - the "addPackages()" call to include classes en-mass and the "withRequiredPluginsFrom()" which is being passed the compile and runtime dependencies from the maven's pom.xml of the project. This is going to scan the test-rhq-plugin.xml for the list of plugins it should look for in the provided list of jars (the ones from the pom) and deploy them along with the plugin itself into the plugin container (recursively, of course - if the plugins depend on yet another plugins, they're included, too).
There is one more thing that I figured might be useful in the plugin testing - @ResourceComponentInstances annotation that is similar to the "@DiscoveredResources" from the previous examples but provides the actual resource components instead of just the resources.
There is also a way of manually deploying stuff into the plugin container as well as manually start and stop the whole PC - interestingly, this is provided by Arquillian itself.
The plugin container inside these tests runs by default in the embedded mode. It is possible to reconfigure it (in arquillian.xml file that provides bootstrap config for arquillian containers) though there is not yet an easy way of configuring the PC to use specific server-services (i.e. a mocked-out RHQ server that we sometimes use in our tests).
The code for all this is for now in a feature branch, because I want to do some more experiments/stabilization on it before it goes to master.
You can checkout the "feature/arquillian-integration" branch to see the code in "modules/arquillian-integration".
For a slightly more elaborate test that shows all the features currently available, you can see the RhqAgentPluginContainerTest in the modules/arquillian-integration/container" module (http://git.fedorahosted.org/git/?p=rhq/rhq.git;a=blob;f=modules/arquillia...).
Ideas for making this better or cover even more ground while testing our plugins are more than welcome.
Lukas
12 years, 1 month
RHQ Release
by Stefan Negrea
Hello Everybody,
I will start the process to cut a new RHQ release. It should take about 2 hours. Please refrain from committing any code into the master branch during this time. I will send an email out as soon as the process finishes.
Thank you,
Stefan Negrea
Software Engineer
12 years, 2 months
do NOT dump messages/exception stacks to stdout/stderr
by John Mazzitelli
+ } catch (JsonParseException e) {
+ e.printStackTrace();
+ } catch (JsonMappingException e) {
+ e.printStackTrace();
+ } catch (IOException e) {
+ e.printStackTrace();
I just saw a checkin to the JBossAS 7 plugin with the above code in it.
This is a gentle reminder - our code conventions in the PC and plugins
are strict - do NOT dump stuff via System.out, System.err OR
e.printStackTrace. I just had to fix something like this yesterday
because someone got a stack trace dumped on the agents console - I had
to go in and convert it to a log message so the exception stack wasn't
bombarding the user on the console.
We want everything logged. This is for several reasons:
1) for support purposes, put the info in a log so we can see it later
2) for user friendliness, don't bombard the user on the agent console
with stack dumps and odd error messages (odd to the user)
3) if the agent is running as a service, those messages will go
unnoticed anyway
So, use a logger and log the exception, do not just simply print it to
stdout/stderr.
12 years, 2 months
Fwd: [ANNOUNCE] Security Update 2012-02-27 released
by Heiko W.Rupp
FYI ..
Anfang der weitergeleiteten E-Mail:
> Von: Selena Deckelmann <selena(a)postgresql.org>
> Datum: 27. Februar 2012 16:51:45 MEZ
> An: pgsql-announce(a)postgresql.org
> Betreff: [ANNOUNCE] Security Update 2012-02-27 released
>
> The PostgreSQL Global Development Group today released security updates for all active branches of the PostgreSQL object-relational database system, including versions 9.1.3, 9.0.7, 8.4.11 and 8.3.18.
>
> Users of pg_dump, users of SSL certificates for validation or users of triggers using SECURITY DEFINER should upgrade their installations immediately. All other database administrators are urged to upgrade your version of PostgreSQL at the next scheduled downtime. More details on the security fixes are included below.
>
> Features affected by bug fixes in this update include: binary replication and hot standby, GIN, WITH, foreign data wrappers, PL/pgsql, PL/python, inet datatype, intarray, pgcrypto, pg_upgrade, pg_restore and pg_dump. Users of these features should apply the updates as soon as possible.
>
> This release contains 45 fixes to version 9.1, and a smaller number of fixes to older versions, including:
>
> * Fix btree index corruption from insertions concurrent with vacuuming
> * Recover from errors occurring during WAL replay of DROP TABLESPACE
> * Fix transient zeroing of shared buffers during WAL replay
> * Fix postmaster to attempt restart after a hot-standby crash
> * Fix corner case in SSI transaction cleanup
> * Update per-column permissions, not only per-table permissions, when changing table owner
> * Fix handling of data-modifying WITH subplans in READ COMMITTED rechecking
> * Fix for "could not find plan for CTE" failures
> * Fix unsupported node type error caused by COLLATE in an INSERT expression
> * Avoid crashing when we have problems deleting table files post-commit
> * Fix recently-introduced memory leak in processing of inet/cidr
> * Fix GIN cost estimation to handle column IN (...) index conditions
> * Fix I/O-conversion-related memory leaks in plpgsql
> * Teach pg_upgrade to handle renaming of plpython's shared library (affecting upgrades to 9.1)
>
> As with other minor releases, users are not required to dump and reload their database or use pg_upgrade in order to apply this update release; you may simply shut down PostgreSQL and update its binaries. Perform post-update steps after the database is restarted.
>
> This update includes three security fixes for the following issues:
>
> * CVE-2012-0866: Permissions on a function called by a trigger are not checked.
> http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-0866
>
> This fix prevents users from defining triggers which execute functions on which the user does not have EXECUTE permission.
>
> CREATE TRIGGER failed to make any permissions check on the trigger function to be called. An unprivileged database user could attach a trigger function to a table they owned and cause it to be called on data of their choosing. Normally, this would execute with the permissions of a table owner, and thus not give additional capability. However, if a trigger function is marked SECURITY DEFINER, privilege escalation is possible.
>
> * CVE-2012-0867: SSL certificate name checks are truncated to 32 characters, allowing connection spoofing under some circumstances.
> http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-0867
>
> This fixes SSL common name truncation, which could allow hijacking of an SSL connection under exceptional circumstances.
>
> When using SSL certificates, both clients and servers can be configured to verify the other's host name against the common name in the certificate it presents. However, the name extracted from the certificate was incorrectly truncated to 32 characters. Normally that just results in a verification failure, but if the actual host name of a machine is exactly 32 characters long, it could, in principle, be spoofed. The risk of this actually happening appears unlikely, and an attacker would still need to take additional steps outside of PostgreSQL to succeed with an exploit.
>
> * CVE-2012-0868: Line breaks in object names can be exploited to execute code when loading a pg_dump file.
> http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-0868
>
> This fix removes '\n' and '\r' from dumpfile comments.
>
> pg_dump copied object names into comments in a SQL script without sanitizing them. An object name that includes a newline followed by an SQL command would result in a dump script in which the SQL command is exposed for execution. When and if the dump script is reloaded, the command would be executed with the privileges of whoever is running the script - often a superuser.
>
> All supported versions of PostgreSQL are affected.
>
> Download new versions now:
>
> Main download page: http://www.postgresql.org/download/
> Source code: http://www.postgresql.org/ftp/source/
> Binary packages: http://www.postgresql.org/ftp/binary/
> One-click installer, including Windows packages: http://www.enterprisedb.com/products/pgdownload.do
>
--
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: Mark Hegarty, Charlie Peters, Michael Cunningham, Charles Cachera
12 years, 2 months
Re: Supported Browsers
by mike thompson
After the GWT 2.4.0/SmartGWT 3.0 upgrade the recommended browsers for RHQ4.3 is:
The forum says the the smartGWT web browser support is determined by the SmartClient version.
SmartClient 8.2 applications run in the following standard web browsers:
Internet Explorer 6.0-9.x (Windows)
Firefox 2.0-7.x (Windows/MacOS/Linux: 3.0+ only)
Safari 3.0-5.x (MacOS/Windows)
Chrome 9.x-15.x (MacOS/Windows)
Opera 9.x-10.x (Windows/MacOS: beta)
As well as the following mobile device web browsers:
Safari on iOS
Android web browser
On Feb 22, 2012, at 7:47 AM, Charles Crouch wrote:
> Given you can't get formal "support" for RHQ, at least not from RH, how about we just say something like: "Here is the list of *recommended* browsers for RHQ4.3..." ?
>
> Mike, what should that list be now after the various component upgrades?
>
> Cheers
> Charles
>
> ----- Original Message -----
>> From what I can see, we don't currently have anything in the RHQ docs
>> about which browsers are supported. We should add something (perhaps
>> on
>> http://rhq-project.org/display/JOPR2/Prerequisites). Note, for RHQ,
>> "supported" means developers have used it and haven't noticed any
>> major
>> issues; this is obviously a different definition than what
>> "supported"
>> means for JON, and the list of supported browsers for JON will be a
>> subset of the list of browsers supported by RHQ.
>>
>> On 02/22/2012 10:12 AM, mike thompson wrote:
>>> Now that RHQ is on GWT 2.4.0 and SmartGWT 3.0 the list of supported
>>> browsers has expanded. Will there be a formal change in browser
>>> version support as well?
>>>
>>>
>>> I say this noticing some peculiarities with Fire Fox 10, but it is
>>> not a supported browser so I'm not sure how much attention be
>>> given to it. However, reality is most likely that our users
>>> outside of RHEL will be on FF10 and not FF3.6.
>>>
>>> Thoughts and opinions on this?
>>> _______________________________________________
>>> rhq-devel mailing list
>>> rhq-devel(a)lists.fedorahosted.org
>>> https://fedorahosted.org/mailman/listinfo/rhq-devel
>>
>>
>> --
>> Ian Springer
>> Principal Software Developer
>> JBoss Operations Network
>> Red Hat
>> ian.springer(a)redhat.com
>>
>> _______________________________________________
>> rhq-devel mailing list
>> rhq-devel(a)lists.fedorahosted.org
>> https://fedorahosted.org/mailman/listinfo/rhq-devel
>>
> _______________________________________________
> rhq-devel mailing list
> rhq-devel(a)lists.fedorahosted.org
> https://fedorahosted.org/mailman/listinfo/rhq-devel
12 years, 2 months
rhq 4.3 blockers?
by Charles Crouch
Now that John and Mike have gotten passed the bug with the search bar, are there any more issues that would prevent an RHQ4.3 release?
Obviously we need to get master tests passing again, but I believe Ian and Stefan are looking at that.
And Mike needs to merge in refs/heads/BZ795833
Anything else?
Thanks
Charles
12 years, 2 months
Searchbar Issues in Web Mode
by mike thompson
After having fixed the enter key not working and the star, arrow and patternField, the next issue is that is appears that the Criteria is injecting some weird javascript to the domain that cause the search to come back erroneous.
Scenario:
From Inventory -> Services type do a search for 'version' in the search bar.
We will run the same scenario through both 'Dev mode' and then 'Web mode (compiled)'
This is the Dev Mode Logging
Thu Feb 23 13:13:09 PST 2012 FINE: Table.TableFilter Pressed Enter key2
Thu Feb 23 13:13:09 PST 2012 FINE: Table.TableFilter searchBarValue : version, hiddenValue:
Thu Feb 23 13:13:09 PST 2012 FINE: Table.TableFilter fetchFilteredTableData
Thu Feb 23 13:13:09 PST 2012 FINE: In Table.refresh()
Thu Feb 23 13:13:09 PST 2012 FINE: org.rhq.enterprise.gui.coregui.client.inventory.resource.ResourceSearchView.refresh() using criteria [Criteria[{search=version, resourceType.category=SERVICE}]]...
Thu Feb 23 13:13:09 PST 2012 FINE: Table.refresh dataSource != null
Thu Feb 23 13:13:09 PST 2012 FINE: Resetting paging on org.rhq.enterprise.gui.coregui.client.inventory.resource.ResourceDatasource...
Thu Feb 23 13:13:09 PST 2012 FINE: Array filter: resourceType.category=[[Service]]
Thu Feb 23 13:13:09 PST 2012 FINE: Filter: search=[version]
Thu Feb 23 13:13:09 PST 2012 FINE: org.rhq.enterprise.gui.coregui.client.inventory.resource.ResourceDatasource using [PageControl[firstRow=0, size=50]] for fetch request.
Thu Feb 23 13:13:09 PST 2012 FINE: RPC method invocation: ResourceGWTService_Proxy.findResourcesByCriteria
Thu Feb 23 13:13:09 PST 2012 FINE: RPCTracker register: TrackingRequestCallback[id=28, name=ResourceGWTService_Proxy.findResourcesByCriteria, age=0]
Thu Feb 23 13:13:09 PST 2012 FINE: SessionRpcRequestBuilder is adding sessionId(-1961737963) to request(http://192.168.1.3:7080/coregui/org.rhq.enterprise.gui.coregui.CoreGUI/ResourceGWTService)
POST http://192.168.1.3:7080/coregui/org.rhq.enterprise.gui.coregui.CoreGUI/Re...
200 OK
118ms
(line 42)
Thu Feb 23 13:13:09 PST 2012 FINE: Table.refresh markForRedraw()
Thu Feb 23 13:13:09 PST 2012 FINE: ****** Pressed Enter in SearchBar
Thu Feb 23 13:13:09 PST 2012 FINE: Table.TableFilter Pressed Enter key2
Thu Feb 23 13:13:09 PST 2012 FINE: Table.TableFilter searchBarValue : version, hiddenValue: version
Thu Feb 23 13:13:09 PST 2012 FINE: OnValueChange in SearchBar: version
Thu Feb 23 13:13:09 PST 2012 INFO: Loading [2] types with facets=[[]]...
Thu Feb 23 13:13:09 PST 2012 FINE: RPC method invocation: ResourceTypeGWTService_Proxy.findResourceTypesByCriteria
Thu Feb 23 13:13:09 PST 2012 FINE: RPCTracker register: TrackingRequestCallback[id=29, name=ResourceTypeGWTService_Proxy.findResourceTypesByCriteria, age=0]
Thu Feb 23 13:13:09 PST 2012 FINE: SessionRpcRequestBuilder is adding sessionId(-1961737963) to request(http://192.168.1.3:7080/coregui/org.rhq.enterprise.gui.coregui.CoreGUI/ResourceTypeGWTService)
POST http://192.168.1.3:7080/coregui/org.rhq.enterprise.gui.coregui.CoreGUI/Re...
200 OK 38ms
As you can see Dev Mode completes without error.
Now, we run the same search in 'Web mode'.
This is the web mode logging
Thu Feb 23 13:00:44 GMT-800 2012 FINE: Table.TableFilter Pressed Enter key2
B5209B...he.html (line 1484)
Thu Feb 23 13:00:44 GMT-800 2012 FINE: Table.TableFilter searchBarValue : version, hiddenValue: ejb
B5209B...he.html (line 1484)
Thu Feb 23 13:00:44 GMT-800 2012 FINE: Table.TableFilter fetchFilteredTableData
B5209B...he.html (line 1484)
Thu Feb 23 13:00:44 GMT-800 2012 FINE: In Table.refresh()
B5209B...he.html (line 1484)
Thu Feb 23 13:00:44 GMT-800 2012 FINE: org.rhq.enterprise.gui.coregui.client.inventory.resource.ResourceSearchView.refresh() using criteria [Criteria[{search={0=v, 1=e, 2=r, 3=s, 4=i, 5=o, 6=n, cT=function Bpd(a) { return Pod(this, VL(a, 1)); }, eQ=function Cpd(a) { return Tod(this, a); }, gC=function Fpd() { return WW; }, hC=function Gpd() { return Wod(this); }, tS=function Hpd() { return qpd(this); }, cM={1=1, 628=1, 636=1, 641=1}}, resourceType.category=SERVICE}]]...
B5209B...he.html (line 1484)
Thu Feb 23 13:00:44 GMT-800 2012 FINE: Table.refresh dataSource != null
B5209B...he.html (line 1484)
Thu Feb 23 13:00:44 GMT-800 2012 FINE: Array filter: resourceType.category=[[Service]]
B5209B...he.html (line 1484)
Thu Feb 23 13:00:44 GMT-800 2012 FINE: Filter: search=[{0=v, 1=e, 2=r, 3=s, 4=i, 5=o, 6=n, cT=function Bpd(a) { return Pod(this, VL(a, 1)); }, eQ=function Cpd(a) { return Tod(this, a); }, gC=function Fpd() { return WW; }, hC=function Gpd() { return Wod(this); }, tS=function Hpd() { return qpd(this); }, cM={1=1, 628=1, 636=1, 641=1}}]
B5209B...he.html (line 1484)
Thu Feb 23 13:00:44 GMT-800 2012 FINE: org.rhq.enterprise.gui.coregui.client.inventory.resource.ResourceDatasource using [PageControl[firstRow=0, size=50]] for fetch request.
B5209B...he.html (line 1484)
Thu Feb 23 13:00:44 GMT-800 2012 FINE: RPC method invocation: ResourceGWTService_Proxy.findResourcesByCriteria
B5209B...he.html (line 1484)
Thu Feb 23 13:00:44 GMT-800 2012 FINE: RPCTracker register: TrackingRequestCallback[id=22, name=ResourceGWTService_Proxy.findResourcesByCriteria, age=0]
B5209B...he.html (line 1484)
Thu Feb 23 13:00:44 GMT-800 2012 FINE: SessionRpcRequestBuilder is adding sessionId(-1961737963) to request(http://192.168.1.3:7080/coregui/org.rhq.enterprise.gui.coregui.CoreGUI/ResourceGWTService)
B5209B...he.html (line 1484)
POST http://192.168.1.3:7080/coregui/org.rhq.enterprise.gui.coregui.CoreGUI/Re...
200 OK 91ms
B5209B...he.html (line 2854)
Thu Feb 23 13:00:44 GMT-800 2012 FINE: Table.refresh markForRedraw()
B5209B...he.html (line 1484)
Thu Feb 23 13:00:44 GMT-800 2012 FINE: ****** Pressed Enter in SearchBar
B5209B...he.html (line 1484)
Thu Feb 23 13:00:44 GMT-800 2012 FINE: Table.TableFilter Pressed Enter key2
B5209B...he.html (line 1484)
Thu Feb 23 13:00:44 GMT-800 2012 FINE: Table.TableFilter searchBarValue : version, hiddenValue: version
B5209B...he.html (line 1484)
Thu Feb 23 13:00:44 GMT-800 2012 FINE: OnValueChange in SearchBar: version
B5209B...he.html (line 1484)
Thu Feb 23 13:00:44 GMT-800 2012 SEVERE: At [Thu Feb 23 13:00:44 GMT-800 2012] MessageCenter received: Invalid search expression.
B5209B...he.html (line 1484)
Thu Feb 23 13:00:44 GMT-800 2012 FINE: In Table.refresh()
You can see that the criteria built are incorrect with the weird javascript stuff injected into it; and this only occurs in web mode.
If anyone has experience with this sort of thing please pipe up otherwise John Sanda and I will continue to figure this out.
Current hotspot is around building the criteria.
12 years, 2 months
Supported Browsers
by mike thompson
Now that RHQ is on GWT 2.4.0 and SmartGWT 3.0 the list of supported browsers has expanded. Will there be a formal change in browser version support as well?
I say this noticing some peculiarities with Fire Fox 10, but it is not a supported browser so I'm not sure how much attention be given to it. However, reality is most likely that our users outside of RHEL will be on FF10 and not FF3.6.
Thoughts and opinions on this?
12 years, 2 months