problem with sync classes in domain
by John Mazzitelli
I noticed the following GWT compilation errors:
[INFO] [ERROR] Errors in
'jar:file:/home/mazz/.m2/repository/org/rhq/rhq-core-domain/4.1.0-SNAPSHOT/rhq-core-domain-4.1.0-SNAPSHOT.jar!/org/rhq/core/domain/sync/entity/SystemSettings.java'
[INFO] [ERROR] Line 141: No source code is available for type
java.util.Properties; did you forget to inherit a required module?
[INFO] [ERROR] Errors in
'jar:file:/home/mazz/.m2/repository/org/rhq/rhq-core-domain/4.1.0-SNAPSHOT/rhq-core-domain-4.1.0-SNAPSHOT.jar!/org/rhq/core/domain/sync/ExportWrapper.java'
[INFO] [ERROR] Line 38: No source code is available for type
java.io.InputStream; did you forget to inherit a required module?
We must be very careful when adding classes to the domain module. If you
do, you must look at the GWT output and make sure it can compile
everything properly.
In this case, these two classes in the ..domain.sync package are
utilizing Java API that are NOT available in GWT and thus can not be
used by the GWT client. Specifically, java.io classes.
It may be true that these classes are not going to be used by GWT
clients, however, we need to keep stuff out of the GWT compilation if
they a) are not to be intended to be used by GWT clients and/or b) they
can't be compiled by GWT.
We can discuss tomorrow how to fix this. We either a) must move these
out of the domain module entirely or b) figure out a good "exclusion"
policy for putting things in domain but keeping them out of the GWT
compilation unit. We already have one class in domain where we are doing
this, we just need to come up with a good naming policy so we can have a
place to put domain objects and keep them out of the GWT stuff.
12 years, 8 months
Out-of-band data for configurations
by Heiko W.Rupp
Hi,
currently when writing a configuration, we can only return "success" or throw an Exception on failure.
Is there a way to convey extra information on success?
Background: in as7 when e.g. changing the a port definition for the socket bindings, the result on
success may be "reload required" that should be presented to the user
(actually, that should even be a badge in the resource tree until the reload is done).
Any ideas?
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, 8 months
issue w/ installer on Oracle
by John Mazzitelli
I just logged some findings on this in
https://bugzilla.redhat.com/show_bug.cgi?id=718315
turns out, you can't have spaces surrounding equals signs in the
rhq-server.properties.
So, if you are seeing odd behavior with settings in
rhq-server.properties, check that you are using the syntax:
name=value
and NOT
name = value.
Don't know why that is yet - but, it is what it is right now.
On 07/01/2011 11:22 AM, Ian Springer wrote:
> While doing a silent upgrade install w/ an Oracle db, I saw the
> following in the server log:
>
> 2011-06-30 16:45:05,383 INFO
> [org.rhq.enterprise.installer.ConfigurationBean] Oracle does not need to
> have server-name,
> port and db-name individually set, skipping
>
> I then looked at my rhq-server.properties file and noticed some new
> lines had been appended to it, presumably by the installer:
>
> rhq.server.database.db-name=
> rhq.server.database.server-name=
> rhq.server.database.password=jon
> rhq.server.database.port=
>
> This doesn't seem right, because I already have all four of these props
> defined in rhq-server.properties:
>
> <snip>
> rhq.server.database.password = -17408cdce5dc39fc
> rhq.server.database.server-name = foo.redhat.com
> rhq.server.database.port = 1521
> rhq.server.database.db-name = JON
> <snip>
>
> I'm guessing the appending of the db-name, server-name, and port props
> are related to the log message above. I have no idea why the password
> prop was appended.
>
> My upgrade happened to fail, so I attempted to run the installer a
> second time but got the following error in the server log, presumably
> caused by the "rhq.server.database.password=jon" line which was appended
> to the properties file:
>
> 2011-06-30 17:34:55,274 FATAL
> [org.rhq.enterprise.installer.ConfigurationBean] Could not decrypt the
> password for some reason - auto-installation failed
> java.lang.Exception: Decoding db password failed:
> at
>
org.rhq.enterprise.installer.ConfigurationBean.decodePassword(ConfigurationBean.java:803)
> at
>
org.rhq.enterprise.installer.ConfigurationBean.save(ConfigurationBean.java:549)
> at
>
org.rhq.enterprise.installer.AutoInstallServlet.init(AutoInstallServlet.java:49)
> <snip>
> Caused by: java.lang.NumberFormatException: For input string: "jon"
> at
>
java.lang.NumberFormatException.forInputString(NumberFormatException.java:48)
> at java.lang.Integer.parseInt(Integer.java:449)
> at java.math.BigInteger.<init>(BigInteger.java:316)
> at
>
org.jboss.resource.security.SecureIdentityLoginModule.decode(SecureIdentityLoginModule.java:168)
> <snip>
>
> I've hit this several times now. Mazz, would you mind creating a BZ for
> it and getting a fix in if it's an easy one?
12 years, 9 months
Fwd: GitReady
by Charles Crouch
FYI
----- Forwarded Message -----
Sent: Monday, August 8, 2011 1:48:52 AM
Subject: GitReady
Just found this: http://gitready.com/
Very neat site with Git tips and tricks.
12 years, 9 months
writing tests
by John Sanda
As much as possible I try treat *unit* tests like documentation. I try
to keep the code simple which often times means repetitive and also try
to use self-describing method names that clearly express the intent of
the test. For example, in a test class I worked in recently,
DriftDetectorTest, I have a test method named
excludeEmptyDirsFromCoverageChangeSet. Another test method is
skipScheduleThatHasConfigDisabled.
There are a couple benefits to self-documenting test names. They can
read like a spec for the code under test which I find to be really
helpful. Secondly, when a test fails, it gives you some general (and
more often than not specific) idea about the nature of the failure.
Having good assertion messages also goes along way in helping quickly
identify root causes. I was just looking at a test failure on hudson,
and I see
java.lang.AssertionError: expected:<1> but was:<0>
Granted there is also a stack trace that tells me where the assertion
failed, but it does not provide any context. If I am the person who
wrote the test and the code under test, I probably don't need any
additional context. But if I am not the person who wrote the code, or if
I have not looked at the code in a long time, the additional context can
be very helpful. When writing tests, can we try to make a point of
providing some sort of useful message for asserts?
Thanks
- John
12 years, 9 months
CLI: Agent info incomplete
by Ondřej Žižka
Hi,
I wanted to filter discovered JBoss AS' by hostname.
Using resource's name seems unreliable, so I wanted to use
resource.agent.server
But that's never filled:
rhqadmin@stacks1.mw.lab.eng.bos.redhat.com:7080$ as.agent
Agent:
address:
affinityGroup:
agentToken:
backFilled: false
createdTime: 1312237924605
id: 10111
lastAvailabilityReport:
modifiedTime: 1312237924605
name:
port: 0
remoteEndpoint:
server:
status: 0
statusMessages: []
Is there some technical reason for that, or can it be fixed?
Thanks,
Ondra
12 years, 9 months
FYI - Drift branch requires clean build
by Jay Shaughnessy
I just pushed some refactoring that applies some naming conventions
resulting in class name, server plugin name change, etc. Highly
recommended that for dev ens to perform a clean build (clean
dev-container, new db, etc).
-J
12 years, 9 months