[
https://issues.apache.org/jira/browse/DELTASPIKE-674?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14086008#comment-14086008
]
Sven Panko edited comment on DELTASPIKE-674 at 8/5/14 8:48 AM:
---------------------------------------------------------------
Ok, I found the problem. It is caused by the
ConfigurationExtension.registerUserConfigSources() method. This method collects
all PropertyFileConfig implementations and adds them programmatically to the
(automatically detected) config sources via ConfigResolver.addConfigSources().
Since classloader information is lost at that point, the addConfigSources()
method has no way to determine which bundle originally provided the config
sources and uses the classloader of the ConfigResolver class to add the config
source. Later on the lookup will be done using the bundle's classloader, which
of course will fail.
I fixed this by letting ConfigurationExtension.registerUserConfigSources() call
a newly created ConfigResolver.addConfigSources() method that expects a Map as
input, using the classloader of the PropertyFileConfig as the key and the
resolved sources as the value.
{{diff_DELTASPIKE-674_update1}} contains all changes from
{{diff_DELTASPIKE-674}} and the aforementioned bugfix.
There is one caveat, though. This fix must be considered invasive, because the
original ConfigResolver.addConfigSources() method cannot be fixed to
incorporate the correct classloader lookup. At the least it should be
deprecated if my changes will be applied, because in the future it should not
be used by extension developers.
Additionally I only tested it using John's wildfly-build-managed profile, I
don't know whether other profiles cause problems here as well.
was (Author: spanko):
Ok, I found the problem. It is caused by the
ConfigurationExtension.registerUserConfigSources() method. This method collects
all PropertyFileConfig implementations and adds them programmatically to the
(automatically detected) config sources via ConfigResolver.addConfigSources().
Since classloader information is lost at that point, the addConfigSources()
method has no way to determine which bundle originally provided the config
sources and uses the classloader of the ConfigResolver class to add the config
source. Later on the lookup will be done using the bundle's classloader, which
of course will fail.
I fixed this by letting ConfigurationExtension.registerUserConfigSources() call
a newly created ConfigResolver.addConfigSources() method that expects a Map as
input, using the classloader of the PropertyFileConfig as the key and the
resolved sources as the value.
{{diff_DELTASPIKE-674_update1}} contains all changes from
{{diff_DELTASPIKE-674}} and the aforementioned bugfix.
There is one caveat, though. This fix must be considered invasive, because the
original ConfigResolver.addConfigSources() method cannot be fixed to
incorporate the correct classloader lookup. At the least it should be
deprecated if my changes will be applied, because in the future it should not
be used by extension developers.
> Possible regression due to changes in ConfigResolver
> ----------------------------------------------------
>
> Key: DELTASPIKE-674
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-674
> Project: DeltaSpike
> Issue Type: Bug
> Components: Core
> Affects Versions: 1.0.1
> Environment: Java 1.7.45, Mac OS X 10.9, Wildfly 8.1
> Reporter: Sven Panko
> Assignee: Rafael Benevides
> Attachments: diff_DELTASPIKE-674, diff_DELTASPIKE-674_update1
>
>
> I just upgraded from 1.0.0 to 1.0.1 to see the fix in DELTASPIKE-648 in
> action. The problem now is: my property files are not picked up at all (I
> described my workaround in DELTASPIKE-648). I debugged the code to see that
> the changes are now in fact loading everything with the EAR classloader, but
> this loader fails to see my custom ConfigSourceProvider.
> Important to note: an additional thing I changed between this issue and the
> time I reported 648: I configured Wildfly to isolate supdeployments within an
> EAR, which was previously disabled. 1.0.0 still correctly sees my property
> files, but 1.0.1 does not. I haven't checked whether 1.0.1 picks up the files
> if I revert back to the unisolated state.
> My suspicion is that the EAR classloader does not see the
> ConfigSourceProvider's inside the EJB jars. Since every lookup now uses this
> classloader it will never see any such implementations unless they are part
> of the "global" module that is comprised of the jars in the /lib directory of
> the EAR.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
