if you have a javaagent you can otherwise you can't but beam can proxy all
instances it sees which would be enough while the transforms* don't create
their own classloaders without reusing the TCCL. On the deserialization
side it is easy since it is beam land and it "just "needs to find back or
I'm assuming that you have control over the application environment. Would
it be possible to replace the ObjectInputStream that the JVM provides with
your own version that uses the thread context class loader and manage the
classloader per thread depending on what "application" owns that thread?
(answered inline)
Le mer. 13 juin 2018 à 18:42, Lukasz Cwik a écrit :
> Thanks for the example Romain.
>
> I took a look through it and was wondering whether it is only the root
> objects in the deserialization tree that need to implement
> SerializableService?
> Do lots of things need to
Thanks for the example Romain.
I took a look through it and was wondering whether it is only the root
objects in the deserialization tree that need to implement
SerializableService?
Do lots of things need to implement SerializableService typically?
What do you do with types that you don't control
Note sure the example is atomic enough but in
https://github.com/Talend/component-runtime/blob/master/component-runtime-manager/src/main/java/org/talend/sdk/component/runtime/manager/finder/StandaloneContainerFinder.java#L40
the "instance()" is a singleton used by all the runtime of the framework.
Romain, can you point to an example of a global singleton registry that
does this right for class loading (it may allow people to work towards such
an effort)?
On Tue, Jun 5, 2018 at 10:06 PM Romain Manni-Bucau
wrote:
> It is actually very localised in runner code where beam should reset the
>
It is actually very localised in runner code where beam should reset the
classloader when the deserialization happens and then the runner owns the
classloader all the way in evaluators.
If IO change the classloader they must indeed handle it too and patch the
deserialization too.
Here again (we
Perhaps we can also adopt a practice of making our own APIs explicitly pass
a Classloader when appropriate so we only have to set this when we are
entering code that does not have good hygiene. It might actually be nice to
have a lightweight static analysis to forbid bad methods in our code.
Kenn
I totally agree, but there are so many Java APIs (including ours) that
messed this up so everyone lives with the same hack.
On Mon, Jun 4, 2018 at 3:41 PM Andrew Pilloud wrote:
> It seems like a terribly fragile way to pass arguments but my tests pass
> when I wrap the JDBC path into Beam
It seems like a terribly fragile way to pass arguments but my tests pass
when I wrap the JDBC path into Beam pipeline execution with that pattern.
Thanks!
Andrew
On Mon, Jun 4, 2018 at 3:20 PM Lukasz Cwik wrote:
> It is a common mistake for APIs to not include a way to specify which
> class
It is a common mistake for APIs to not include a way to specify which class
loader to use when doing something like deserializing an instance of a
class via the ObjectInputStream. This common issue also affects Apache Beam
(SerializableCoder, PipelineOptionsFactory, ...) and the way that typical
I'm having class loading issues that go away when I revert the changes in
our use of Class.forName added in https://github.com/apache/beam/pull/4674.
The problem I'm having is that the typical JDBC GUI
(SqlWorkbench/J, SQuirreL SQL) creates an isolated class loader to load our
library. Things work
12 matches
Mail list logo
