[ 
https://issues.apache.org/jira/browse/DELTASPIKE-451?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13833932#comment-13833932
 ] 

Mark Struberg commented on DELTASPIKE-451:
------------------------------------------

Hi!

I fear I need some more info!

We already have a Map<ClassLoader, ConfigSource[]> which gets filled if it's 
not yet resolved.
This means that if you boot with the EAR ClassLoader, then only this info will 
get set at that time. Once you have a request to a single webapp in your EAR 
and you get another ClassLoader, then the ConfigSources (+ all it's values) 
will resolved with this new ClassLoader.
This is done because it's perfectly possible to have different configurations 
in different webapps of your ear.
A problem might arise if you inject this information into an @ApplicationScoped 
bean which is in your EAR lib. Because our @ConfigProperty producers are of 
course creating a @Dependent value (there are multiple reasons for this: a.) 
Strings cannot be proxied, b.) we need the InjectionPoint info). The first 
access will determine the value you'll get injected in  your shared 
@ApplicationScoped bean and no further resolving will be done. 

If you got hit by this very problem, then it's not a DeltaSpike issue but 
something which is a common pitfall with EAR scenarios. I suggest you move all 
the configs you need for your classes in shared libraries to those shared 
libraries as well.

If you got hit by another problem then please further elaborate on your exact 
constellation - txs!

>  Using @ConfigProperty in an EAR File on JBoss 7 fails
> ------------------------------------------------------
>
>                 Key: DELTASPIKE-451
>                 URL: https://issues.apache.org/jira/browse/DELTASPIKE-451
>             Project: DeltaSpike
>          Issue Type: Bug
>          Components: Configuration
>    Affects Versions: 0.5
>         Environment: JBoss 6.1.1 EAP (JBoss AS 7.2.1) on Windows XP
>            Reporter: Thomas Stemmer
>            Assignee: Mark Struberg
>
> I'm using @ConfigProperty for loading properties from a propertyfile. This 
> works fine as long as I deploy the application as an WAR File. If I wrap the 
> WAR in an EAR File the Properties won't get loaded. This is caused by the 
> different classloaders for startup (EAR) and property access (WAR).
> In Detail:
> - The properties are loaded on EAR Startup with the EAR classloader
> - The properties are put in the 
> org.apache.deltaspike.core.api.config.ConfigResolver.configSources HashMap, 
> the key is the EAR Classloader
> - The properties are accessed in the WAR File, so the WAR classloader is used
> - The ...ConfigResolver.getConfigSources() uses the WAR classloader as a key 
> for the HashMap
> - No properties are found because of the wrong key (WAR instead of EAR 
> classloader)
> Possible Solution by Mark Struberg from the mailinglist:
> "We should walk up the parent ClassLoader chain like we do in 
> BeanManagerProvider."
> http://mail-archives.apache.org/mod_mbox/deltaspike-dev/201311.mbox/%3C1385476770.76979.YahooMailNeo%40web28902.mail.ir2.yahoo.com%3E



--
This message was sent by Atlassian JIRA
(v6.1#6144)

Reply via email to