[ https://issues.apache.org/jira/browse/DELTASPIKE-648?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Rafael Benevides updated DELTASPIKE-648: ---------------------------------------- Attachment: DELTASPIKE-648.patch The Attached file replaces {code} ClassLoader currentClassLoader = ClassUtils.getClassLoader(null); {code} by {code} ClassLoader currentClassLoader = ConfigResolver.class.getClassLoader(); {code} This is due because ClassUtils#getClassLoader returns the ContextClassLoader of the current Thread first. ConfigResolver should always get the same ClassLoader. > @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: Rafael Benevides > Priority: Minor > 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.2#6252)