[
https://issues.apache.org/jira/browse/DELTASPIKE-648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14055327#comment-14055327
]
Rafael Benevides commented on DELTASPIKE-648:
---------------------------------------------
Tests added to check WAR and EAR utilisation...
> @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)
