[
https://issues.apache.org/jira/browse/DELTASPIKE-674?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14090421#comment-14090421
]
Sven Panko commented on DELTASPIKE-674:
---------------------------------------
Thanks for all your feedback. ConfigResolver could be definitely refactored to
see whether some (non-public) methods might be removed or changed (my
implementation was just a proof of concept, so I preferred adding methods
instead of changing existing ones).
As for the SPI approach - I have to admit I usually work in a Spring-only
environment (my current project is my first Java EE project) with OSGi and
Blueprint. I would use the service registry or the bundle's application context
to get something like a classloader resolver strategy and simply use that.
That being said - I could imagine having an SPI interface (let's call it
ClassloaderResolverStrategy) that will be searched for during
ConfigResolver.resolveConfigSources(). But in order to find it the search needs
to be done within the context of a TCCL that actually sees the implementation.
This is the point where the injection point is used in my approach. Is there a
way we could use the SPI approach in this scenario? If so, I'd be happy to help
out and implement such a solution.
A different option would be to allow a user to control the property resolution
by extending the ConfigProperty annotation by adding a new property similar to
Blueprint's [context-class-loader
property|http://www.eclipse.org/gemini/blueprint/documentation/reference/1.0.2.RELEASE/html/service-registry.html#service-registry:export:ccl];
we could provide a sensible default and let the user overwrite it if desired.
> 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)
