Mark Struberg resolved DELTASPIKE-648.
    Resolution: Fixed

finally fixed. You need to configure the PropertyFileConfig via 
java.util.ServiceLoader for EARs on some containers.

See DELTASPIKE-837 for more info.

> @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.3.0
>         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

Reply via email to