[
https://issues.apache.org/jira/browse/DELTASPIKE-648?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
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
(v6.3.4#6332)
