[
https://issues.apache.org/jira/browse/DELTASPIKE-648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14329167#comment-14329167
]
Mark Struberg commented on DELTASPIKE-648:
------------------------------------------
[~johndament]]
I fear all JBoss containers are broken with EARs. This problem is actually not
a fault of DeltaSpike to be honest. But I think we still need to support it.
[~majson]
I was working like mad on this for the last week or so. You might probably
already have read the blog I wrote about the various containers and how they
work
https://struberg.wordpress.com/2015/02/18/cdi-in-ears/
I also wrote a smallish EAR which just logs out a bit of information about
ClassLoaders, TCCL, scanned beans, etc
https://github.com/struberg/cdi-ear-test
If you let this run on WildFly or JBossAS then you will quickly see the issue.
The Extension from WAR1 will also get fed with the classes from WAR2 and the
other way around. If you have an Extension only in the EAR-lib it will
automatically pick up the classes from ALL WARs as well. Thus our Set<Class<?
extends ConfigSourceProvider>> might contain classes which you actually MUST
NOT SEE.
I'm still trying to get my head around it and I have the gut feeling that I
might have found a pretty generic solution for this issue. But I still need to
test this out on various servers.
> @ConfigProperty in Wildfly 8.1 not working correctly
> ----------------------------------------------------
>
> Key: DELTASPIKE-648
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-648
> Project: DeltaSpike
> Issue Type: Bug
> Components: Configuration
> Affects Versions: 1.0.0
> Environment: Mac OS X 10.9, Java 1.7.45, Wildfly 8.1
> Reporter: Sven Panko
> Assignee: Mark Struberg
> Priority: Minor
> Fix For: 1.0.1, 1.2.2
>
> Attachments: DELTASPIKE-648.patch
>
>
> I am not quite sure if my problem is related to the (already closed)
> DELTASPIKE-451, but it is quite similar in behavior:
> * I have an EAR file that packages a few EJB jars (these are NOT contained in
> the lib directory of the EAR)
> * the application.xml uses the default isolation mechanism, which means that
> all libs in /lib have access to all classes (although I don't think this is
> relevant in my case since my EJB jars are not located in /lib)
> * inside one of the EJB jars I put a property file that should be used ONLY
> by beans inside this jar file
> * I created an implementation of PropertyFileConfig and provided the path to
> this property file
> * during startup I can see that the property file is correctly detected and
> stored in the hashmap using the EAR classloader
> * I have a bean (@Singleton, @Startup) inside the aforementioned EJB jar that
> expects a property to be injected via @Inject @ConfigProperty - which does
> not work
> I debugged the startup process and detected that the property injection into
> the bean fails because the lookup into the hashmap will not be done with the
> EAR classloader, but with the jar's classloader, which is totally
> understandable. What I do not understand, however, is, why the resolution
> process which kicks in afterwards does no longer find my PropertyFileConfig
> implementation, which worked in the EAR classloader case.
> My temporary solution now is to put a
> META-INF/services/org.apache.deltaspike.core.spi.config.ConfigSourceProvider
> file into the EJB jar and reference a custom ConfigSourceProvider. This file
> is always picked up correctly (interestingly in both cases, the EAR
> classloader and the jar classloader).
> Shouldn't the ConfigResolver pick up my PropertyFileConfig implementation in
> both cases as well?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
