[
https://issues.apache.org/jira/browse/DELTASPIKE-674?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14080672#comment-14080672
]
Sven Panko commented on DELTASPIKE-674:
---------------------------------------
Just for clarification: is it an expected behavior that the ConfigProperty
resolution always uses the EAR classloader even if I explicitly set the flag
for isolated sub-deployments?
I am asking this, because the documentation at
https://docs.jboss.org/author/display/WFLY8/Class+Loading+in+WildFly states:
{quote}
The Java EE specification says that portable applications should not rely on
sub deployments having access to other sub deployments unless an explicit
Class-Path entry is set in the MANIFEST.MF. So portable applications should
always use Class-Path entry to explicitly state their dependencies.
{quote}
This lead me to believe that isolated deployments are the rule, not the
exception. If so, why is the EAR classloader used for the resolution of
property files instead of the more specific module classloader?
> 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
>
> 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)
