63.com
From: guaishushu1...@163.com
Date: 2019-09-03 20:25
To: dev
Subject: Re: Re: ClassLoader created by BlobLibraryCacheManager
is not
using context classloader
guaishushu1...@163.com
From: guaishushu1...@163.com
Date: 2019-09-03 20:23
To: dev
Subject: Re: Re: ClassLoader created by BlobLibrary
e:
> > >>>>> I see the problem Jan. What about the following proposal: Instead
> of
> > >>>>> using
> > >>>>> the LocalEnvironment for local tests you always use the
> > >>>>> RemoteEnvironment
> > >>&g
t;>>> but when testing it locally you spin up a MiniCluster in the same
> >>>>> process
> >>>>> and initialize the RemoteEnvironment with
> >>>>> `MiniCluster#getRestAddress`.
> >>>>> That way you would always submit a jar with
gt; wrote:
guaishushu1...@163.com
From: guaishushu1...@163.com
Date: 2019-09-03 20:25
To: dev
Subject: Re: Re: ClassLoader created by BlobLibraryCacheManager
is not
using context classloader
guaishushu1...@163.com
From: guaishushu1...@163.com
Date: 2019-09-03 20:23
To: dev
Subject: Re: Re: ClassLoade
not
using context classloader
guaishushu1...@163.com
From: guaishushu1...@163.com
Date: 2019-09-03 20:23
To: dev
Subject: Re: Re: ClassLoader created by BlobLibraryCacheManager is not
using context classloader
guaishushu1...@163.com
From: Jan Lukavský
Date: 2019-09-03 20:17
To: dev
Su
is
> >> supposed t execute must be present when being started.
> >>
> >> Cheers,
> >> Till
> >>
> >> On Tue, Sep 3, 2019 at 2:27 PM guaishushu1...@163.com <
> >> guaishushu1...@163.com> wrote:
> >>
> >>>
>
started.
Cheers,
Till
On Tue, Sep 3, 2019 at 2:27 PM guaishushu1...@163.com <
guaishushu1...@163.com> wrote:
guaishushu1...@163.com
From: guaishushu1...@163.com
Date: 2019-09-03 20:25
To: dev
Subject: Re: Re: ClassLoader created by BlobLibraryCacheManager is not
using context class
Loader created by BlobLibraryCacheManager is not
using context classloader
guaishushu1...@163.com
From: guaishushu1...@163.com
Date: 2019-09-03 20:23
To: dev
Subject: Re: Re: ClassLoader created by BlobLibraryCacheManager is not
using context classloader
guaishushu1...@163.com
From: Jan Lukavsk
guaishushu1...@163.com <
guaishushu1...@163.com> wrote:
>
>
>
>
> guaishushu1...@163.com
>
> From: guaishushu1...@163.com
> Date: 2019-09-03 20:25
> To: dev
> Subject: Re: Re: ClassLoader created by BlobLibraryCacheManager is not
> using context classloader
guaishushu1...@163.com
From: guaishushu1...@163.com
Date: 2019-09-03 20:25
To: dev
Subject: Re: Re: ClassLoader created by BlobLibraryCacheManager is not using
context classloader
guaishushu1...@163.com
From: guaishushu1...@163.com
Date: 2019-09-03 20:23
To: dev
Subject: Re: Re
guaishushu1...@163.com
From: guaishushu1...@163.com
Date: 2019-09-03 20:23
To: dev
Subject: Re: Re: ClassLoader created by BlobLibraryCacheManager is not using
context classloader
guaishushu1...@163.com
From: Jan Lukavský
Date: 2019-09-03 20:17
To: dev
Subject: Re: ClassLoader
guaishushu1...@163.com
From: Jan Lukavský
Date: 2019-09-03 20:17
To: dev
Subject: Re: ClassLoader created by BlobLibraryCacheManager is not using
context classloader
Hi Till,
the use-case is pretty much simple - I have a REPL shell in groovy,
which generates classes at runtime
Hi Till,
the use-case is pretty much simple - I have a REPL shell in groovy,
which generates classes at runtime. The actual hierarchy is therefore
system class loader -> application classloader -> repl classloader
(GroovyClassLoader actually)
now, when a terminal (sink) operation in the
Hi Jan,
I've talked with Aljoscha and Stephan offline and we concluded that we
would like to avoid the usage of context class loaders if possible. The
reason for this is that using the context class loader can easily mess up
an otherwise clear class loader hierarchy which makes it hard to reason
I’m not saying we can’t change that code to use the context class loader. I’m
just not sure whether this might break other things.
Best,
Aljoscha
> On 2. Sep 2019, at 11:24, Jan Lukavský wrote:
>
> Essentially, the class loader of Flink should be present in parent hierarchy
> of context
Essentially, the class loader of Flink should be present in parent
hierarchy of context class loader. If FlinkUserCodeClassLoader doesn't
use context class loader, then it is actually impossible to use a
hierarchy like this:
system class loader -> application class loader -> user-defined
Hi,
I actually don’t know whether that change would be ok. FlinkUserCodeClassLoader
has taken FlinkUserCodeClassLoader.class.getClassLoader() as the parent
ClassLoader before my change. See:
Hi Jan,
this looks to me like a bug for which you could create a JIRA and PR to fix
it. Just to make sure, I've pulled in Aljoscha who is the author of this
change to check with him whether we are forgetting something.
Cheers,
Till
On Fri, Aug 30, 2019 at 3:44 PM Jan Lukavský wrote:
> Hi,
>
>
Hi,
I have come across an issue with classloading in Flink's MiniCluster.
The issue is that when I run local flink job from a thread, that has a
non-default context classloader (for whatever reason), this classloader
is not taken into account when classloading user defined functions. This
is
19 matches
Mail list logo
