Bug 927895

Summary:	META-INF "Dependencies: org.foo.module services" doesn't work for CDI Portable extensions
Product:	[JBoss] JBoss Enterprise Application Platform 6	Reporter:	Marek Schmidt <maschmid>
Component:	CDI/Weld	Assignee:	Stuart Douglas <sdouglas>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Marek Schmidt <maschmid>
Severity:	high	Docs Contact:
Priority:	high
Version:	6.1.0	CC:	cdewolf, dandread, jawilson, jdoyle, mharvey, myarboro, pzapataf, rsvoboda, smumford
Target Milestone:	ER3
Target Release:	EAP 6.1.1
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:	In previous versions of Red Hat JBoss Enterprise Application Platform 6 deployments with dependencies on CDI Portable Extensions delivered within modules would fail to deploy with the following exception: ---- org.jboss.weld.exceptions.DeploymentException: WELD-001408 Unsatisfied dependencies for type [<Extension Name>] ---- This was because deployments did not load CDI Portable Extensions from modules declared as dependencies. In order for an application to load a CDI Portable Extension defined in a extension JBoss Module , it was not sufficient for the application to declare a dependency on the extension JBoss Module. The application must also have declared a dependency on the Portable Extension class in its `META-INF/services/javax.enterprise.inject.spi.Extension` file. This version of Red Hat JBoss Enterprise Application Platform 6 includes a change in how deployments are loaded. Deployments are now loaded directly from the class loader, and then any duplicates from sub deployments are eliminated. The result of this change is that CDI portable extensions can now be loaded from a static module.	Story Points:	---
Clone Of:		Environment:	EAP 6.1.0.ER3
Last Closed:	2013-09-16 20:21:27 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Marek Schmidt 2013-03-26 13:04:19 UTC

Description of problem:

CDI portable extensions doesn't seem to work in a module.

Having a simple module "org.jboss.test.extensionModule" with

- a org.jboss.weld.tests.module.extension.FunExtension class imlementing javax.enterprise.inject.spi.Extension 
- and a META-INF/services/javax.enterprise.inject.spi.Extension file with "org.jboss.weld.tests.module.extension.FunExtension"

and a test jar which depends on this module, with a simple test class which injects FunExtension, declaring a dependency with :

"Dependencies: org.jboss.test.extensionModule services" 

in its manifest.

This test jar fails to deploy with

Caused by: org.jboss.weld.exceptions.DeploymentException: WELD-001408 Unsatisfied dependencies for type [FunExtension] with qualifiers [@Default] at injection point [[field] @Inject org.jboss.weld.tests.module
.extension.ExtensionTest.funExtension]

which seems as if the META-INF/services didn't get imported from the module.

The test works fine when I add the META-INF/services/javax.enterprise.inject.spi.Extension file to the test jar itself.

Version-Release number of selected component (if applicable):
EAP 6.1.0.ER3

Comment 2 Marek Schmidt 2013-03-26 13:09:09 UTC

Reproducer in an internal git:

git clone git://git.engineering.redhat.com/users/maschmid/weld-module-tests.git
cd weld-module-tests
export JBOSS_HOME=/path/to/jboss-eap-6.1
mvn clean verify -Darquillian=jbossas-managed-7 -Dtest=ExtensionTest

Comment 3 Stuart Douglas 2013-03-29 23:01:26 UTC

This requires a fairly major change to the way portable extensions are handled. Instead of just looking within the deployment we need to load them directly from the class loader, and then eliminate duplicates from each sub deployment. 

Given that no one has had a problem with this up until now, and it can be easily worked around by putting the META-INF/services file into the deployment itself, it will not be possible to get this into EAP 6.1.

Comment 7 Dimitris Andreadis 2013-05-02 13:33:04 UTC

So, we need to make sure the workaround works, and keep the bugzilla to fix this properly in a later release, possibly  EAP 6.2. Stuart, can you please create an upstream JIRA for this.? John, will also communicate this to Ericsson.

Comment 8 Dimitris Andreadis 2013-05-02 13:34:23 UTC

It also needs to be release noted.

Comment 9 John Doyle 2013-05-02 17:05:36 UTC

I added some release note text.  Please validate that it's accurate and complete.

Comment 10 Marek Schmidt 2013-05-03 13:22:02 UTC

Looks good to me. Any reason for this to be "Release note" and not a "known issue"?

Comment 11 Scott Mumford 2013-05-07 02:58:37 UTC

Thanks for the draft note, John.

You've provided some good backgrounding to the issue, but it isn't a complete release note...yet.

A complete release note for a resolved bug covers the Cause of the problem; the Consequence (how the product behaved because of the bug); the Fix (how the problem was resolved, with specifics!); and the Result (how the product behaves now). ECS refers to this model as 'CCFR'.

So far your text really only has the first 'C' (with an implied 'F' if a reader knows how to declare a dependency on the  Portable Extension class). So we need a bit more info if the issue is resolved.

If this is still a Known Issue, however (as Marek suggests), the text should include a 'workaround' (if one exists) instead of a Fix and an approximate ETA on the permanent fix. The Cause and Consequence are still required.

If the missing info (based on the resolved/known status) is posted here, I'll write up a draft note for inclusion.

Comment 12 Scott Mumford 2013-05-17 02:58:36 UTC

Added a draft Release Note based on John's info.

As there is very little time left for technical review on this, I'm marking this issue for inclusion in the 6.1.0 Release Notes prior to technical verification

Please comment if the draft is incorrect.

######
Original Info:

Cause
Deployments do not load CDI Portable Extensions from modules declared as dependencies.

Consequence
Deployments with dependencies on CDI Portable Extensions delivered within modules will fail to deploy with the following exception.
org.jboss.weld.exceptions.DeploymentException: WELD-001408 Unsatisfied dependencies for type [<Extension Name>]

Workaround
In order for an application to load a CDI Portable Extension defined in a extension JBoss Module, it is not sufficient for the application to declare a dependency on the extension JBoss Module.  The application must also declare a dependency on the  Portable Extension class in its META-INF/services/javax.enterprise.inject.spi.Extension file.

Comment 13 JBoss JIRA Server 2013-05-24 01:47:07 UTC

Stuart Douglas <stuart.w.douglas> updated the status of jira WFLY-1370 to Resolved

Comment 15 Jimmy Wilson 2013-06-26 00:26:43 UTC

Proposing for 6.1.1.

Comment 16 Marek Schmidt 2013-07-18 11:17:02 UTC

Verified on EAP 6.1.1.ER3

Comment 17 Scott Mumford 2013-07-31 04:08:55 UTC

Added a revised release note draft since this bug is now resolved. Please review and confirm technical accuracy.

Including base-matter here for further reference if required:

Cause: 

CDI portable extensions were not picked up from a static module that had its services exposed to the deployment

Consequence: 

CDI Portable extensions from a static module were not working unless they were explicitly activated in the deployment with META-INF/services/javax.enterprise.inject.spi.Extension file.

Fix: 

The way CDI portable extensions are loaded was changed, so they will be picked up from any module that has its services exposed to the deployment

Result: 

CDI portable extensions can now be loaded from a static module.

Comment 18 Marek Schmidt 2013-08-06 07:23:48 UTC

*** Bug 988093 has been marked as a duplicate of this bug. ***

Comment 19 Scott Mumford 2013-08-29 00:23:51 UTC

Marking for exclusion from the 6.1.1 Release Notes document as an entry for this bug could not be completed or verified in time.

Comment 20 Scott Mumford 2013-08-29 00:24:14 UTC

Marking for exclusion from the 6.1.1 Release Notes document as an entry for this bug could not be completed or verified in time.