[
https://issues.apache.org/jira/browse/DELTASPIKE-674?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sven Panko updated DELTASPIKE-674:
----------------------------------
Attachment: patch_DELTASPIKE-674
John, first of all many thanks for your explanation. I agree that serving all
party guests is cumbersome and tedious to say the least ;)
Since I had a real problem at hand now and didn't want to add all of my EJB
jars as a dependency to the EAR I took your idea to derive the classloader to
use for property lookup from the injection point and patched a few classes in
the core component. The result is that I now resolve every property using the
classloader that is responsible for loading the class that contains the
ConfigProperty annotation, which is exactly what I needed. I also added a
fallback if I don't specify a classloader, so that it reverts to the current
mechanism (ConfigResolver.class.getClassLoader()). I attached my solution to
this issue.
I would be delighted if my changes find its way into the project, but I am also
aware that it might need more testing - I only tested it in my scenario. All of
the existing unit tests work as expected of course.
> 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)
