I'm seeing the domain jar in rhq.ear/lib. It's not supposed to be there. The domain jar should only be in the top level ear directory, as an exploded ejb jar. Having it in lib will cause unpredictable classloading, may impact patching, and, for dev environments, will be missed by clean domain builds. So, we need to get it out of there.
(9:44:30 AM) lkrejci: jshaughn: have you checked modules/enterprise/bindings? it depends on domain and server includes it because of CLI alerts (9:45:03 AM) jshaughn: i was just looking at that (9:45:29 AM) jshaughn: not sure if that could be an issue in some transitive way, thanks for the pointer (9:47:08 AM) lkrejci: just wanted to point that out because it's a relatively new thing... it's a RHQ scripting environment abstraction that is shared between CLI and server-side CLI alerts (9:48:31 AM) jshaughn: yes. i'm suspicious of it (9:49:04 AM) jshaughn: it's one of the few rhq jar deps in the ear (9:49:23 AM) jshaughn: and the only one that has a domain dep (9:50:45 AM) jshaughn: but it hasn't changed in a while. (9:58:16 AM) lkrejci: jshaughn: that doesn't mean that it isn't the culprit ;) (9:58:33 AM) jshaughn: I think it is, testing now (10:09:11 AM) jshaughn: lkrejci: that was it. Thanks to "tips from ips" for pointing out the nifty 'mvn dependency:tree' goal. keep that one in your toolbox for easily seeing where maven dependencies are coming from. (10:10:38 AM) lkrejci: jshaughn: ok, cool... how did you fix it? just declared the dep as provided? (10:11:17 AM) jshaughn: it's been this way since *February*! I just got (un)lucky I guess and bumped into it because 1) I was working on domain changes in the dev env and 2) the classloader decided to use that lib jar as opposed to the ejb jar. I'm guessing up until then the classloader had been using the ejb jar first, by luck. (10:12:01 AM) lkrejci: whoops.. (10:12:05 AM) jshaughn: lkrejci: no, the binding pom stays as is, the ear jar declares an exclusion in its binding dep, telling it not to pull the domain jar transitively (10:12:38 AM) lkrejci: k, makes sense (10:13:34 AM) jshaughn: this type of thing is really difficult to detect as the effect is removed from the cause. (10:13:47 AM) ips: so it went into rhq 4.0 and 4.1. luckily, we don't patch rhq (10:13:58 AM) jshaughn: yes, it must have (10:14:05 AM) ips: it's good that jay caught it before the jon release (10:14:09 AM) jshaughn: but right, probably not a problem for the rhq releases
Tester Note: Verify that rhq-core-domain jar is not present in the .../default/deploy/rhq.ear/lib directory.
this will be in RHQ, not JON. no functional regression associated with this.
verified RHQ 09/08/2011 daily build
changing status of VERIFIED BZs for JON 2.4.2 and JON 3.0 to CLOSED/CURRENTRELEASE
marking VERIFIED BZs to CLOSED/CURRENTRELEASE