WELD-1837:Weld SE does not support empty beans.xml files #817
Conversation
|
Triggering build using a merge of 4c14c9f on branch 2.2: |
|
Build 408 is now running using a merge of 4c14c9f on branch 2.2: |
|
Thanks Stefan, the fix looks very good. Would you mind adding a test for the issue? You can use the following test as an example of an automated Weld SE test with multiple modules: https://github.com/weld/core/blob/master/environments/se/core/src/test/java/org/jboss/weld/environment/se/test/provider/MultiModuleCDIProviderTest.java |
|
Build 408 outcome was SUCCESS using a merge of 4c14c9f on branch 2.2: |
1 similar comment
|
Build 408 outcome was SUCCESS using a merge of 4c14c9f on branch 2.2: |
|
Ok, I will add the test. |
|
Triggering build using a merge of 721a87d on branch 2.2: |
|
Triggering build using a merge of d3c3e9a on branch 2.2: |
|
Build 412 is now running using a merge of d3c3e9a on branch 2.2: |
|
Build 412 outcome was FAILURE using a merge of d3c3e9a on branch 2.2: |
1 similar comment
|
Build 412 outcome was FAILURE using a merge of d3c3e9a on branch 2.2: |
|
retest this please |
|
Triggering build using a merge of d3c3e9a on branch 2.2: |
|
Build 414 is now running using a merge of d3c3e9a on branch 2.2: |
|
Build 414 outcome was SUCCESS using a merge of d3c3e9a on branch 2.2: |
|
Merged, thanks! |
Weld SE has a problem while scanning bean archives, if the application has multiple archives with an empty beans.xml. Only the last detected archive is considered.
An empty beans.xml is represented with the constant org.jboss.weld.bootstrap.spi.BeansXml.EMPTY_BEANS_XML. The problem is, that implementations of org.jboss.weld.environment.deployment.discovery.BeansXml use this .EMPTY_BEANS_XML as key in a HashMap, which should contain all discovered bean archives. But because the key for jars with an empty beans.xml is always the same, they are not discovered properly.
The approach to solve this problem is to use the beansXmlUrl as key for the Map. I introduced a new helper class "ScanResult" which aggregates the beansXml and beanArchiveRef so that further processing of the scan result is influenced as less as possible.
Remark: I did not test the WebAppBeanArchiveScanner because this is not used in my environment. The DefaultBeanArchiveScanner seams to work correctly after this change.