This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 736050 - Domain jar being packaged in rhq.ear lib directory
Domain jar being packaged in rhq.ear lib directory
Status: CLOSED CURRENTRELEASE
Product: RHQ Project
Classification: Other
Component: Build System (Show other bugs)
4.1
All All
high Severity high (vote)
: ---
: ---
Assigned To: RHQ Project Maintainer
Mike Foley
:
Depends On:
Blocks: jon3
  Show dependency treegraph
 
Reported: 2011-09-06 10:20 EDT by Jay Shaughnessy
Modified: 2012-02-07 14:30 EST (History)
1 user (show)

See Also:
Fixed In Version: 4.2
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Jay Shaughnessy 2011-09-06 10:20:22 EDT
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 10:19:40 EDT
(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 10:20:59 EDT
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 14:24:55 EDT
this will be in RHQ, not JON.  no functional regression associated with this.
Comment 4 Mike Foley 2011-09-08 10:07:05 EDT
verified RHQ 09/08/2011 daily build
Comment 5 Mike Foley 2012-02-07 14:30:08 EST
changing status of VERIFIED BZs for JON 2.4.2 and JON 3.0 to CLOSED/CURRENTRELEASE
Comment 6 Mike Foley 2012-02-07 14:30:31 EST
marking VERIFIED BZs to CLOSED/CURRENTRELEASE

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