Bug 736050 - Domain jar being packaged in rhq.ear lib directory
Summary: Domain jar being packaged in rhq.ear lib directory
Alias: None
Product: RHQ Project
Classification: Other
Component: Build System
Version: 4.1
Hardware: All
OS: All
high vote
Target Milestone: ---
: ---
Assignee: RHQ Project Maintainer
QA Contact: Mike Foley
Depends On:
Blocks: jon3
TreeView+ depends on / blocked
Reported: 2011-09-06 14:20 UTC by Jay Shaughnessy
Modified: 2012-02-07 19:30 UTC (History)
1 user (show)

Fixed In Version: 4.2
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed:

Attachments (Terms of Use)

Description Jay Shaughnessy 2011-09-06 14:20:22 UTC
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.

Comment 1 Jay Shaughnessy 2011-09-07 14:19:40 UTC
(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

Comment 2 Jay Shaughnessy 2011-09-07 14:20:59 UTC
Tester Note:  Verify that rhq-core-domain jar is not present in the
.../default/deploy/rhq.ear/lib directory.

Comment 3 Mike Foley 2011-09-07 18:24:55 UTC
this will be in RHQ, not JON.  no functional regression associated with this.

Comment 4 Mike Foley 2011-09-08 14:07:05 UTC
verified RHQ 09/08/2011 daily build

Comment 5 Mike Foley 2012-02-07 19:30:08 UTC
changing status of VERIFIED BZs for JON 2.4.2 and JON 3.0 to CLOSED/CURRENTRELEASE

Comment 6 Mike Foley 2012-02-07 19:30:31 UTC

Note You need to log in before you can comment on or make changes to this bug.