re-ordering the tabs
by John Mazzitelli
I'm looking at the tabs, and I don't see any rhyme or reason why they
are ordered the way they are:
Summary, Monitor, Inventory, Operations, Alerts, Configuration, Events
Can I recommend we change this order to:
Summary, Inventory, Alert, Monitor, Operations, Configuration, Events
for the following reasons:
Summary, Inventory relate to what makes up the resource - what it IS -
it defines the resource itself and how its constituted. So we keep them
together and up front.
Alerts relate to what the resource did or is doing that is abnormal -
its really standalone. But we have it here, third, for a reason, see below.
Monitor, Operations, Configuration, Events are all subsystems that
describe what the resource is doing or can do. Thus, we keep them all
together. Since Operations, Config and Events are optional, they appear
after Monitor (thus, since Monitor always exists, its always first in
this group, the other three can appear in any combination depending on
the resource type).
Note:
Summary, Inventory, Alert and Monitor always exist - so the first four
tabs will always be in the same place for any resource (i.e. the UI will
be consistent no matter what resource you are looking for). e.g. If I
want to go to an alert tab, I know, regardless of what resource I'm
looking at, I need to go to the third tab.
And for groups, its basically the same - the first THREE tabs are always
the same. So, no matter what I'm looking at - a compat group, mixed
group, auto-group or individual resource, the first three tabs are
always the same. Full consistency of the tabs across every view - the
only tabs that come and go are the subsystem tabs and they are on the
far right - the location of summary, inventory, alerts, monitor never move.
Unless there are objections, I would like to alter the tabs so they
appear in the order as described above.
13 years, 4 months
testing without the embedded container
by John Sanda
A while back when I was testing JPQL queries that I had updated to
account for resource types being deleted, I got tired off using the
embedded container. The start up time in particular is what wore my
patience thin. It dawned on me as I was running my tests in core/domain,
which is where we define all of our JPQL queries, that there are only
two things for which we are using the embedded container in core/domain
tests - 1) entity manager and 2) transactions. We can get both of these
things without the embedded container. A little over a month I created a
branch in which I refactored all of the tests in core/domain such that
there is no longer any dependency on the embedded container.
Specifically, tests no longer inherit from AbstractEJB3Test.
Tests are instead relying on unitils (http://www.unitils.org). Unitils
provides a lot of useful, interesting features. There are three things
for which I was using it.
1) A persistence service. Unitils can inject an EntityManager,
EntityManagerFactory, and DataSource into tests using standard JEE
annotations.
2) A transaction service. Each test method by default is wrapped in a
transaction.
3) Integration with DbUnit. Unitils executes a dbunit data set
immediately before each test method is executed, ensuring that the
database is in a known, consistent state before the test begins.
There are a number of upsides to this change. The overall build time for
core/domain is a good bit faster. More importantly though, executing a
single test class is substantially faster since there is no longer the
overhead of bootstrapping the embedded container.
I simplified the control flow in a large number of tests. There is
longer any need for the try/finally/rollback pattern that we commonly
used. In fact, you will notice that the test code has been taken out of
those try/finally blocks altogether. This *does* mean that tests are
committing transactions, and that's ok since each test resets the
database (or more precisely, relevant parts of the database) before it
runs. Committing transactions has the added benefit of being able to
inspect the state of the database after a test failure. I am sure most
of us at some point have spent time debugging a test failure and
resorted to temporarily changing the rollback call to a commit in the
test method so that we could inspect the state of the database. That is
not only unnecessarily time-consuming, it is also very error-prone.
Using dbunit can and does simplify the set up logic for tests. It
provides a way to do test set up independent of the code under test. It
also makes for good documentation and makes tests more readable.
It would remiss of me not to point out some of the downsides of using
unitils. Unitils is somewhat of a glue framework in that it ties
together nicely some other frameworks for use in JUnit and TestNG tests.
Under the covers it uses spring, dbunit, hibernate, and several other
libraries. This can (and did for me) lead to some problems with
dependency management. Granted we are only talking about test scope, but
I still had to spend time resolving a few dependency conflicts.
Defining the dbunit data sets in xml might be considered another
downside. It limits the use of some refactoring tools. If I change part
of an entity mapping in the Java source file, I will have to
independently make any changes necessary to the data set file.
Everything in the xml data set is defined statically. If I need to
create a number of rows in a table that let's say differ in only ids, I
have to write out each one in the data set whereas a simple, compact
loop to generate those rows would likely be more preferable.
Fortunately, both dbunit and unitils are pretty flexible. We are not
limited to defining data sets in xml, although that is likely to be the
easiest and fastest approach most of the time.
The other issue with dbunit is that it does not manage foreign keys. For
an entity like ResourceType, care has to be taken to ensure that things
are deleted in the correct order; otherwise, you will run into FK
constraint violations. I have found though that once the data set is set
up, it is pretty easy to manage with respect to FKs.
I want to emphasize that my goal was not to simply replace the embedded
container with unitils. Rather, the intention was to make tests faster,
more concise, more reliabe, and easier to maintain. Unitils is just one
way to achieve this, but I do think it is a very good way to achieve it.
I did not integrate unitils into any of the server/jar tests since we
rely heavily on the embedded container there for accessing our SLSBs.
I did this work in the unitils branch, and it can all be found in a
single commit - 0e666c041b3047c5a8919325615569c0d95a06d7. Please look at
some of the tests in the branch. I would like to get some feedback and
consider eventually integrating this upstream into master.
- John
13 years, 4 months
new ImageManager - please use
by John Mazzitelli
In an effort to "clean up" the usage of the icons (that is, make sure we
use the new icons in coregui images/ and move away from portal war
images), there is a new ImageManager, which is analogous to the
LinkManager, except ImageManager gets you the links to the icon images.
For example, if you ever need the green/red availability icon, use:
ImageManager.getAvailabilityIcon(Boolean) (or one of its derivatives).
As you go through the code, if you see image/icon URLs hardcoded,
consider refactoring it to use the an ImageManager method (create one if
it doesn't have it).
This will be especially useful if/when we remove portal war because lots
of its images are still being referenced. If we use ImageManager, we can
a) ensure it only uses coregui icons and b) if it DOES use portal war
icons, its just a matter of adding the icon image to coregui and
changing the one or couple lines of code in the single class
ImageManager, rather than hunting down all the places we referenced the
image in the coregui client code.
I already refactored the avail icon usage that I could find. In
addition, the group view now actually shows the proper
green/red/yellow/grey group icons in the title area, using this new
ImageManager.
13 years, 5 months
subtab errors
by John Mazzitelli
I just did a git pull and I'm starting to see those "Invalid subtab:
Overview~" error messages again (notice the ~ in the error message).
This was a problem until Jay S. fixed it such that subtab IDs are used,
and not the actual title names. Did something regress?
I have the new implementation where the group Members/Membership subtabs
are collapsed into one, but I don't want to push it to the repo until
I'm sure master is in a good state (which I don't think it is).
Anyone else seeing master acting weird?
13 years, 5 months
Reports->Alert definitions
by Heiko W.Rupp
Reports->Alert definitions seems to show the templates section from the admin
menu and not the alert definitions created.
13 years, 5 months
Dashboard empty
by Heiko W.Rupp
Hi,
with the sources from this morning my time, the Dashboard is empty between Search bar and
bottom bar with the message center.
I see no issues in the server log , but the javascript protocol reports
queue depth is 1
org.rhq.enterprise.gui.coregui.CoreGUI/44E0B0134FECB35E564A3F36E5EC1DBE.cache.html:22039java.lang.NumberFormatException: For input string: "unbeschränkt"
"unbeschränkt" is actually the translation of "unlimited"
which I only have in de locale within
common_label_unlimited = unbeschränkt
The issue with the Dashboard also shows up in EN locale
Just removing the offending line from the DE translation does not fix it - perhaps this cached
somewhere?
If someone has an idea, please let me know, as I need to do a screenshot of the
current dashboard.
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
Fwd: [rhq] 3 commits - modules/enterprise
by John Mazzitelli
I took the liberty to make the follow change in master. I think we
talked about this a few weeks ago, but I was just around this area so I
figured I'd go do it.
The "save" button on our resource/plugin config pages were all the way
over on the right side of the screen. I moved them to be on the left
where (IMO) most people will look for them and it seems more consistent
with the way other things work.
If the majority think they'd rather keep the save button on the right,
the commit sha is found below that can be reverted.
-------- Original Message --------
New commits:
commit 44e258f3415ce45c48b0d97650bbe136e861136b
Author: John Mazzitelli <mazz(a)redhat.com>
Date: Wed Nov 24 18:13:14 2010 -0500
move the save button over to the left - all of our buttons are
always left-aligned on the screen - making the config editing views more
consistent. plus, no one looks for a save button on the top-right of a
screen :)
13 years, 5 months
group general properties expand/collapse
by John Mazzitelli
See attached for the new way we are going to show the general
properties/summary information for groups. (Simeon - you can see the
expand/collapse arrow here).
This seems to work nicely.
13 years, 5 months
Differences in db-upgrade.xml between master and release-3.0.0
by Lukas Krejci
No, I'm not going to talk about the new stuff that's been added to master ;)
Rather, I'd like to point out that there are schemaSpecs with the same version
number that have different contents in master and in release-3.0.0, which is
going to cause problems and disasters once we release code based on master and
people will want to upgrade their release-3.0.0-based RHQs/JONs to that
version.
You can view the diff by issuing:
git diff origin/release-3.0.0..origin/master
modules/core/dbutils/src/main/scripts/dbupgrade/db-upgrade.xml
I think that diff should only show additions at the very end of the file (i.e.
the new stuff in master) but unfortunately that's not the case.
I'm not sure if this is an exceptional case or how such differences were
handled in the past but I think this should be fixed before we make any more
releases from either branch. Obviously, this is going to break the upgrades
for people using the master dev builds, but they've been warned.. ;)
On the other hand all we need to care about is that everything up to 2.91
(which is the db version in release-3.0.0) matches between release-3.0.0 and
master even if the schemaSpec versions differ a bit.
Unfortunately I don't believe that is the case with version 2.88 in master
containing "stuff" that is not present in r3 at all and version 2.91 in r3
being 2.92 in master, which is going to cause errors during upgrade.
Bug https://bugzilla.redhat.com/show_bug.cgi?id=655156 already deals with a
need to add an upgrade step to release-3.0.0 which I think is an ideal
opportunity to sync up the upgrade in r3 and master.
Obviously, we can only sync like this before we release master. After that,
things are going to get very messy if there is going to be another release
based on release-3.0.0 branch with a new db upgrade step, which is yet another
plus point for our migration to liquibase which, therefore, should happen
before we release master imho.
Cheers,
Lukas
13 years, 5 months