You are viewing a plain text version of this content. The canonical link for it is here.
Posted to mapreduce-dev@hadoop.apache.org by Sangjin Lee <sj...@apache.org> on 2016/08/09 16:00:34 UTC
HADOOP-13410
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. As long as the file is a jar (or its variant), this seems
completely superfluous. My suspicion is that the line of code that adds the
jar to the classpath may have been left there by accident.
Could anyone confirm this? Does anyone see an issue with removing the jar
from the classpath? I've tested the fix with a couple of simple apps, and I
didn't see a problem.
Thanks,
Sangjin
Re: HADOOP-13410
Posted by Sangjin Lee <sj...@apache.org>.
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 <sj...@apache.org> wrote:
> 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 <bu...@cloudera.com> wrote:
>
>> ServiceLoader API stuff won't load out of the unpacked version, right?
>>
>> On Tue, Aug 9, 2016 at 11:00 AM, Sangjin Lee <sj...@apache.org> 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 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. As long as the file is a jar (or its variant), this seems
>> > completely superfluous. My suspicion is that the line of code that adds
>> the
>> > jar to the classpath may have been left there by accident.
>> >
>> > Could anyone confirm this? Does anyone see an issue with removing the
>> jar
>> > from the classpath? I've tested the fix with a couple of simple apps,
>> and I
>> > didn't see a problem.
>> >
>> > Thanks,
>> > Sangjin
>>
>>
>>
>> --
>> busbey
>>
>
>
Re: HADOOP-13410
Posted by Sangjin Lee <sj...@apache.org>.
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 <sj...@apache.org> wrote:
> 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 <bu...@cloudera.com> wrote:
>
>> ServiceLoader API stuff won't load out of the unpacked version, right?
>>
>> On Tue, Aug 9, 2016 at 11:00 AM, Sangjin Lee <sj...@apache.org> 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 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. As long as the file is a jar (or its variant), this seems
>> > completely superfluous. My suspicion is that the line of code that adds
>> the
>> > jar to the classpath may have been left there by accident.
>> >
>> > Could anyone confirm this? Does anyone see an issue with removing the
>> jar
>> > from the classpath? I've tested the fix with a couple of simple apps,
>> and I
>> > didn't see a problem.
>> >
>> > Thanks,
>> > Sangjin
>>
>>
>>
>> --
>> busbey
>>
>
>
Re: HADOOP-13410
Posted by Sangjin Lee <sj...@apache.org>.
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 <bu...@cloudera.com> wrote:
> ServiceLoader API stuff won't load out of the unpacked version, right?
>
> On Tue, Aug 9, 2016 at 11:00 AM, Sangjin Lee <sj...@apache.org> 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 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. As long as the file is a jar (or its variant), this seems
> > completely superfluous. My suspicion is that the line of code that adds
> the
> > jar to the classpath may have been left there by accident.
> >
> > Could anyone confirm this? Does anyone see an issue with removing the jar
> > from the classpath? I've tested the fix with a couple of simple apps,
> and I
> > didn't see a problem.
> >
> > Thanks,
> > Sangjin
>
>
>
> --
> busbey
>
Re: HADOOP-13410
Posted by Sangjin Lee <sj...@apache.org>.
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 <bu...@cloudera.com> wrote:
> ServiceLoader API stuff won't load out of the unpacked version, right?
>
> On Tue, Aug 9, 2016 at 11:00 AM, Sangjin Lee <sj...@apache.org> 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 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. As long as the file is a jar (or its variant), this seems
> > completely superfluous. My suspicion is that the line of code that adds
> the
> > jar to the classpath may have been left there by accident.
> >
> > Could anyone confirm this? Does anyone see an issue with removing the jar
> > from the classpath? I've tested the fix with a couple of simple apps,
> and I
> > didn't see a problem.
> >
> > Thanks,
> > Sangjin
>
>
>
> --
> busbey
>
Re: HADOOP-13410
Posted by Sean Busbey <bu...@cloudera.com>.
ServiceLoader API stuff won't load out of the unpacked version, right?
On Tue, Aug 9, 2016 at 11:00 AM, Sangjin Lee <sj...@apache.org> 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 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. As long as the file is a jar (or its variant), this seems
> completely superfluous. My suspicion is that the line of code that adds the
> jar to the classpath may have been left there by accident.
>
> Could anyone confirm this? Does anyone see an issue with removing the jar
> from the classpath? I've tested the fix with a couple of simple apps, and I
> didn't see a problem.
>
> Thanks,
> Sangjin
--
busbey
---------------------------------------------------------------------
To unsubscribe, e-mail: common-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: common-dev-help@hadoop.apache.org
Re: HADOOP-13410
Posted by Sean Busbey <bu...@cloudera.com>.
ServiceLoader API stuff won't load out of the unpacked version, right?
On Tue, Aug 9, 2016 at 11:00 AM, Sangjin Lee <sj...@apache.org> 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 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. As long as the file is a jar (or its variant), this seems
> completely superfluous. My suspicion is that the line of code that adds the
> jar to the classpath may have been left there by accident.
>
> Could anyone confirm this? Does anyone see an issue with removing the jar
> from the classpath? I've tested the fix with a couple of simple apps, and I
> didn't see a problem.
>
> Thanks,
> Sangjin
--
busbey
---------------------------------------------------------------------
To unsubscribe, e-mail: mapreduce-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: mapreduce-dev-help@hadoop.apache.org