Bug 736050

Summary:	Domain jar being packaged in rhq.ear lib directory
Product:	[Other] RHQ Project	Reporter:	Jay Shaughnessy <jshaughn>
Component:	Build System	Assignee:	RHQ Project Maintainer <rhq-maint>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Mike Foley <mfoley>
Severity:	high	Docs Contact:
Priority:	high
Version:	4.1	CC:	hrupp
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	All
Whiteboard:
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:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	678340

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

marking VERIFIED BZs to CLOSED/CURRENTRELEASE