[
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)
