RHQ-2059
by John Mazzitelli
I just checked in the root plugin classloader stuff. Lots of changes. I did a full enterprise clean build and ran the full test suite (took 16 minutes to build) - all tests pass. I ran the agent and did a quick smoke test - imported RHQ Agent, Jopr Server and Postgres. Things look to be working (this did NOT magically happen :) I had lots of code/fix iterations to get this right).
Here's a few things you need to know:
1) Somehow we allowed plugins to access the clientapi module (i.e. some plugins had a dependency on clientapi jar). This is wrong and should not have been. clientapi is strictly for agent<->server. The plugins should only access the plugin-api jar (plugin-api is for agent<->plugins). I removed all of those dependencies both RHQ and Jopr plugins and things build - all but ONE! The JbossAS-5 plugin. If you try to run that on the latest code, you will get a NoClassDefFoundError - you need to refactor out all dependency on clientapi.
2) I don't think embedded Jopr needs to do anything special - the default should be that the root plugin classloader does not hide any classes from the plugins (everything should load like it did before). I need the embedded jopr guys to smoke test this.
3) tomcat plugin needs testing due to my removal of its dependency on the platform plugin (again, that was not supposed to be - I fixed that). Jay - let me know how that testing goes. Just inventory things and see if you can collect metrics and maybe execute a command. If you can without getting any NoClassDefFoundErrors, you are good to go.
Any problems, ping me. Let me know if you get any NoClassDefFoundErrors now. I'm now off to trying to get the "classloader per resource instance" to work.
14 years, 10 months
moving EJB resources under their respective ejb-jars in JBAS5 plugin
by Charles Crouch
pros and cons of moving the EJB resources under their respective ejb-jars in JBAS5 plugin...
pro1: no duplicate beans next to each other, e.g. foo EJB in two different ears, which you could get in the "global" view
pro2: EJB resources disappear when ejb-jar resource deleted
pro3: beans grouped by the ejb-jar that contains them - no way to sort them that way otherwise
con1: multiple EJB resource types, one under standalone ejb-jars, one under embedded ejb-jars. This means alert/metric templates need to be defined twice on EJB resources.
con2: EJB1/2 beans exposed through the profile service needs massaging so that they are related to their ejb-jar deployments in order to support this model.
con3: this is not how it will work with the JBAS4 plugin.
con4: no way to view all ejbs in one place in embedded except in the navtree
Mitigation
con1: use xml entity declarations to remove duplication of resource type definitions. alert/metric template definitions typically shouldnt need to be changed that frequently
Outstanding concerns
-Need to know how much work con2 would be.
14 years, 11 months
plugin deployment/update fixes
by John Mazzitelli
http://jira.rhq-project.org/browse/RHQ-2097
I enhanced our plugin update stuff on the server side so it supports things reconciling what happens when a plugin is in the database and on the file system and what to do based on the plugin's version, md5, timestamp.
I wrote a bucket of unit tests to confirm the different scenarios actually work. All tests pass on my box repeatedly.
The tests are here: http://svn.rhq-project.org/repos/rhq/trunk/modules/enterprise/server/jar/...
The test matrix defining what scenarios I test and how each scenario will play out is here:
I have four dummy plugins - version 1.0 with a JUNE timestamp, 1.0 with FEBRUARY timestamp and same with version 1.1 (one with JUNE and one with FEBRUARY timestamp). Our stuff now looks at the plugin version to determine which is the latest or not - only if the version is the same (and md5 is different) do we look at timestamp of the plugin. When we release plugin pack updates and patches, we should update their version strings (which is what we should have done before but couldn't because our plugin update implementation didn't deal with that).
Let me know if you see any holes in the test coverage (any scenario I missed?)...
// Here is a matrix of scenarios we are going to test.
// "Winning Plugin" means the plugin considered the most up-to-date (not obsolete).
// "Reason" == "exists" means the winning plugin was the only one that existed
// "Reason" == "version" means the winning plugin had the newer version
// "Reason" == "time" means the winning plugin had the newer/later timestamp
// ==========================================================================
// | Plugins Deployed In: | Winning | Reason | Side
// # | Filesystem | Database | Plugin | | Effects
// ==========================================================================
// 0 | 1.0-feb | 1.0-feb | N/A | N/A | steady state - all up-to-date
// 1 | 1.0-feb | N/A | Filesystem | exists | DB row created
// 2 | N/A | 1.0-feb | Database | exists | file created
// 3 | 1.0-jun | 1.0-feb | Filesystem | time | DB row updated
// 4 | 1.0-feb | 1.0-jun | Database | time | file 1.0-feb deleted, file 1.0-jun created
// 5 | 1.1-jun | 1.0-jun | Filesystem | version | DB row updated
// 6 | 1.0-jun | 1.1-jun | Database | version | file 1.0-jun deleted, file 1.1-jun created
// 7 | 1.1-feb | 1.0-jun | Filesystem | version | DB row updated
// 8 | 1.0-jun | 1.1-feb | Database | version | file 1.0-jun deleted, file 1.1-feb created
// ------ the tests below have two plugins deployed on the file system ------
// 9 | 1.0-feb | 1.0-feb | Filesystem | time | file 1.0-feb deleted,
// | 1.0-jun | | | | DB row updated
// --------------------------------------------------------------------------
// 10| 1.0-feb | 1.0-jun | None | N/A | file 1.0-feb deleted,
// | 1.0-jun | | | |
// --------------------------------------------------------------------------
// 11| 1.0-feb | 1.1-feb | Database | version | files 1.0-feb/jun deleted,
// | 1.0-jun | | | | file 1.1-feb created
// --------------------------------------------------------------------------
// 12| 1.0-feb | 1.0-feb | Filesystem | version | file 1.0-feb deleted,
// | 1.1-jun | | | | DB row updated
// --------------------------------------------------------------------------
// 13| 1.0-feb | 1.1-feb | Filesystem | time | file 1.0-feb deleted,
// | 1.1-jun | | | | DB row updated
// --------------------------------------------------------------------------
// 14| 1.0-feb | 1.0-feb | None | N/A | all files are the same but
// | 1.0-feb-2 | | | | one of the files gets deleted
// --------------------------------------------------------------------------
14 years, 11 months
plugin classloader - child first?
by John Mazzitelli
What would blow up if our plugin classloaders were all always child-first? Specificially, instances of our ChildFirstPluginClassLoader class?
I'm trying to see how I can make this stuff easier. And I'm thinkig - what if there was no choice - the plugin classloader is always child-first so it will always try to resolve classes using the plugin jars first, and only if the plugin cannot resolve them will it go up to its parents?
14 years, 11 months
plugin deps
by John Mazzitelli
next time you svn up and run the server, make sure nothing funky happens during plugin deployment.
I checked in some code for http://jira.rhq-project.org/browse/RHQ-2118
I wrote some unit tests and did some tests by deploying all our plugins except the jboss-as and jboss-cache plugins and things seemed to work as expected (obviously with some resource types not existing because the plugins were missing).
I did not test hot-deployment on the server, but I don't think touched anything that would affect it - however, if you are hot-deploying plugins, just make sure you don't see any oddities.
Any problems, JIRA it and let me know.
The major change here is you no longer need to specify <depends> for plugins that are optional (that is, plugins where you do not need classes - this means if you have several "runs-inside" or "sourcePlugin" metadata, you no longer are required to deploy all the plugins that satisfy all the runs-inside's/sourcePlugin's).
I *think* this closes out 2118 - let me know if you think otherwise.
http://jira.rhq-project.org/browse/RHQ-2059 is still left - that's the hard one :}
14 years, 11 months
DEV_AS_5_TMP branch merged back to trunk
by Lukas Krejci
All,
The temporary branch is now merged back into the trunk.
If there's anything you find missing as a result of the merge, you can stone me
on #jboss-on ;)
Cheers,
Lukas
14 years, 11 months
