Details
-
Bug
-
Status: Closed
-
Minor
-
Resolution: Fixed
-
1.0.0
-
None
-
Mac OS X 10.9, Java 1.7.45, Wildfly 8.1
Description
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?
Attachments
Issue Links
- is related to
-
DELTASPIKE-837 PropertyFileConfig pickup via java.util.ServiceLoader
-
- Closed
-