I just tested a simple service loader with the patch and it works fine even
if the jar is not in the classpath.
On Tue, Aug 9, 2016 at 10:41 AM, Sangjin Lee wrote:
> It uses ClassLoader.getResources() so there shouldn't be anything specific
> to the form of the resource (jar or not). But I'll te
Based on the sentiment in the "[DISCUSS] 2.6.x line releases" thread, I
have moved forward with some of the initial effort in creating a 2.6.5
release. I am forking this thread so we have a dedicated 2.6.5 release
thread.
I have gone through the git logs and gathered a list of JIRAs that are in
br
Aaron Fabbri created HADOOP-13476:
-
Summary: CredentialProviderFactory fails at class loading from
libhdfs (JNI)
Key: HADOOP-13476
URL: https://issues.apache.org/jira/browse/HADOOP-13476
Project: Hado
It uses ClassLoader.getResources() so there shouldn't be anything specific
to the form of the resource (jar or not). But I'll test it later.
On Tue, Aug 9, 2016 at 9:06 AM, Sean Busbey wrote:
> ServiceLoader API stuff won't load out of the unpacked version, right?
>
> On Tue, Aug 9, 2016 at 11:0
ServiceLoader API stuff won't load out of the unpacked version, right?
On Tue, Aug 9, 2016 at 11:00 AM, Sangjin Lee wrote:
> I'd like to get feedback from the community (especially those who might
> remember this) on HADOOP-13410:
> https://issues.apache.org/jira/browse/HADOOP-13410
>
> It appear
I'd like to get feedback from the community (especially those who might
remember this) on HADOOP-13410:
https://issues.apache.org/jira/browse/HADOOP-13410
It appears that Hadoop's RunJar adds the original jar to the app's
classpath even though the unjarred contents of the jar are in the
classpath.
For more details, see
https://builds.apache.org/job/hadoop-qbt-trunk-java8-linux-x86/128/
[Aug 8, 2016 4:19:54 PM] (varunsaxena) MAPREDUCE-6748. Enhance logging for
Cluster.java around
[Aug 8, 2016 4:42:53 PM] (varunsaxena) YARN-4910. Fix incomplete log info in
ResourceLocalizationService (Jun
Another reason I like the 3.0.0-alphaX approach is the ease of
communicating compatibility guarantees.
A lot of our compatibility guarantees (e.g. API/wire compat) mention
"within a major release". For the user, thinking of 3.0.0 as the beginning
of a major release seems easier than 3.2.0 being th
Most people I talked to found 3.0.0-alpha, 3.1.0-alpha/beta confusing. I am
not aware of any other software shipped that way. While being used by other
software does not make an approach right, I think we should adopt an
approach that is easy for our users to understand.
The notion of 3.0.0-alphaX
