[
https://issues.apache.org/jira/browse/DELTASPIKE-674?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14080789#comment-14080789
]
John D. Ament commented on DELTASPIKE-674:
------------------------------------------
I think it has something to do with us either consistently following the Java
EE specs or giving people what they ask for.
The fix for DELTASPIKE-648 is inherently good, but introduces some conditions
around the way you package. I literally walk around these days wearing a sign
that says "DEPLOY A WAR," even when I get push back. There is no problem with
WARs that use many JARs (I currently deploy one that has 27 internal libraries
in it, but I'm building all REST apps.. no JSF).
By us using the EAR ClassLoader, we're ensuring that we're scanning the whole
archive. The downside is that you may end up with properties that you don't
expect in your module. The best solution for this would be to use the
classloader of the caller (e.g. ClassUtils.getClassLoader(injectionPoint.get
something...) ) however it's a bit difficult to find the actual caller class.
Perhaps we can add a parameter to the annotation that indicates the classloader
class to use?
> 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)
