[
https://issues.apache.org/jira/browse/CASSANDRA-1778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12970404#action_12970404
]
Hudson commented on CASSANDRA-1778:
-----------------------------------
Integrated in Cassandra-0.7 #70 (See
[https://hudson.apache.org/hudson/job/Cassandra-0.7/70/])
> Change classloader strategy to load version from non system classloader
> -----------------------------------------------------------------------
>
> Key: CASSANDRA-1778
> URL: https://issues.apache.org/jira/browse/CASSANDRA-1778
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
> Affects Versions: 0.7 beta 3
> Reporter: Bram de Kruijff
> Assignee: Bram de Kruijff
>
> At present when initializing the StorageService,
> FBUtilities.getReleaseVersionString() tries to load the version.info
> resource from the ClassLoader.getSystemClassLoader(). This typically fails in
> an embedded scenario (such as an OSGi container) resulting in a dummy version
> at INFO and a stacktrace at WARN
> logger_.warn("Unable to load version.properties", e);
> return "debug version";
> My guess is that changing the implementation to using the
> FBUtilities.class.getClassLoader() for loading resources would solve it and
> will work in almost any case I can think off. However, as discussed on the
> Apache Felix mailing list, the only "right"way to do it is to allow an
> optional ClassLoader to be specified (@see
> http://www.mail-archive.com/us...@felix.apache.org/msg09060.html).
> This issue was initially reported at the Amdatu jira:
> http://jira.amdatu.org/jira/browse/AMDATU-127
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
