Update on REST api
by Heiko W.Rupp
Hi,
it's been a time since I last wrote about the REST api here in the mailing list [1].
Since then a few updates have happened:
- it is now possible to obtain raw metrics via the api to e.g. analyze it in R [2]; the
examples at http://localhost:7080/rest/ have been updated to show graphs for the last 7 days
of raw data using D3.js
- the api allows to push metrics into the server, as well as read/update baseline data [3]
and last but not least we have announced the rhq-samples project [4], which also
features examples of using the REST api.
The existing api methods still sometimes lack proper handling of caching or
conditional get, returning location headers. Any contribution is welcome.
If you want to start diving in here, you could start by allowing to push availabilities
into the server.
Heiko
[1] https://fedorahosted.org/pipermail/rhq-devel/2011-November/001384.html
[2] http://javablogs.com/Jump.action?id=685875
[3] http://javablogs.com/Jump.action?id=689757
[4] http://javablogs.com/Jump.action?id=683200
http://javablogs.com/Jump.action?id=683200
--
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, 3 months
Content System - Versioning
by Stefan Negrea
Hello Everybody,
I just want to raise awareness regarding a couple of recent changes to the content system. These details are important for plugin developers that use the content system. If you are working on a server or agent plugin that interacts with the content system I would highly recommend to read this email carefully. Most likely the changes I will detail in this email do not impact existing plugins but I highly recommend a review of existing code to make sure it works as intended and as expected.
The content system stores data in a myriad of tables. The PackageVersion table is the most important because it links package metadata with actual content. Internal RHQ server queries use the version field of this table to uniquely identify a package. The content system can store multiple packages with the same name, but they are uniquely identified by the version. So [ROOT.war version=1.1] is stored only once in the database irrespective if the actual war content is different. Just to give an example, ROOT.war is deployed by default on both JBoss AS4 and JBoss AS5 and discovered by both plugins as [ROOT.war version=0]. The first server that gets inventoried wins the battle to store its ROOT.war content on the RHQ server. When a second application server is inventoried, the RHQ server considers that [ROOT.war version=0] is already stored and does not act on the agent request to store content. These details combined with some agent discovery issues resulted in a set of problems for deploying and retrieving content deployed.
The solution that I proposed and implemented preserves existing server code for the content system. The updates were done to the CLI, UI, three agent plugins (Tomcat, JBoss AS4, JBoss AS5), and four server plugins (remote repository syncing) to populate the version field with something that uniquely identifies that actual content. So, the version field is populated with the SHA256 of the content. After this changes the package [ROOT.war version=[sha256=abcd1234] ] is correctly identified based on its content and not on some arbitrary version. The old version concept was then made optional (in the UI and CLI) and stored in display version field, which was in the design but not used. After these changes a package version data will look like this: [ROOT.war version=[sha256=abcde123] display version=1.1].
Just to recap, your plugin will most likely work the same even after this set of changes. I highly encourage anybody to review their code that interacts with the content system to make sure it does not have the same version problems. Another recommendation would be to update existing code to use SHA256 for version and move the existing version concept to the display version field.
Please feel free to contact me if you have any questions or concerns.
Thank you,
Stefan Negrea
Software Engineer
12 years, 3 months
Managed AS 7 as children of HostController?
by Heiko W.Rupp
Hi,
currently I've set up managed AS7 instances to be servers below the platform, in parallel to the host controllers,
as they are technically speaking separate OS processes.
This has the drawback that the admin needs to manually import them every time he adds a new managed AS
through the UI.
Also another point is that the management connection to them actually runs through the host controller, but
it seems like in the component classes I can not access the plugin config and other properties of the host controller
in order to to use them (this only showed up as an issue now that AS requires security).
So I want to move the managed AS instances below HostController as child resources.
Objections?
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: Mark Hegarty, Charlie Peters, Michael Cunningham, Charles Cachera
12 years, 4 months
compiling GWT from maven tip
by John Mazzitelli
I just saw this tip - has anyone tried this soyc setting?
-------- Forwarded Message --------
Following configuration help to reduce memory consumption of of GWT compiler:
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>gwt-maven-plugin</artifactId>
<version>2.4.0</version>
<executions>
<execution>
<goals>
<goal>compile</goal>
</goals>
<configuration>
<!-- This arg is needed for compilation to finish
properly. If it's not set, maven runs out of memory because of
exhaustive report generating --> <soyc>false</soyc>
</configuration>
</execution>
</executions>
</plugin>
12 years, 4 months
bundling of JAXB jars w/ Server and Agent
by Ian Springer
IIRC, we included the JAXB jars in the lib/endorsed dir of both Server
and Agent since, unlike Java 6, Java 5 did not include JAXB. Now that
we've dropped support for Java 5, I think we can look into dropping the
JAXB jars. The two jars are about 1 MB in size, so that's a decent
amount of fat to trim from the Agent, which we like to keep lean and
mean. On the Server, there are some other javax jars in lib/endorsed/
(JAX-WS, etc.) that we can also look into dropping.
Any other thoughts on this before I create a BZ?
12 years, 4 months
Server-side CLI scripts secured in master
by Lukas Krejci
I just pushed a series of security fixes to the RHQ server that disallow the
CLI scripts running on the server (i.e. the alert scripts) from doing local
JNDI lookups (other than through the "blessed" interface provided to the
scripts using the *Manager predefined variables).
This prevents the scripts from accessing the RHQ server's internals like local
SLSBs, entity manager, raw database connection, etc.
If you see any unexpected security exceptions while running the master build,
shout at me :)
The only time you should see a security exception is when your alert script
tries to do something illegal (exit JVM, do a JNDI lookup inside the RHQ
server, ...). You should NEVER see a security exception nor any change in
functionality if the alert scripts are not involved.
Lukas
12 years, 4 months