Re: Casting PyObjects to Java Interfaces fails when constructed from a URLClassLoader
John Hubbard <[email protected]> Fri, 20 May 2016 08:23:49 -0700
| Newsgroups | gmane.comp.lang.jython.user |
|---|---|
| Organization | NSO |
| Message-ID | <[email protected]> |
On 05/19/2016 05:22 PM, Jimmy Mauri wrote:
> For context, see sample project in:
> https://github.com/ElCubanoPoderoso/jython-classloader-issue
>
> I have a use-case where I must support dynamically loaded .jar files
> as hot-deployable subapplications. I was having trouble in instances
> where if the .jar file was redeployed (say I made a code change and
> need to update the environment), Jython starts to break down with
> class casting. Upon the first deployment, the application is able to
> properly load the .jar file, instantiate the main class which creates
> the interpreter with the packaged URLClassLoader into the
> PySystemState object, interprets the script and creates the class
> object with the appropriate java interface cast to it.
>
> However, the second invocation of said project causes the casting to
> fail on subsequent executions, converting the object to a PySingleton
> and rejecting the cast. I'm having trouble understanding what I need
> to do to resolve my issue. Not being able to properly coerce the
> object to the expected java interface is causing forced workarounds to
> add wrapper objects to utilize them in Java code.
>
> Note: This is only observed when trying to cast to interfaces that
> reside inside the .jar file and not in the system classloader.
>
> The sample GitHub project linked was simplified to generate a
> proof-of-concept that can be invoked via JUnit to reproduce the error.
>
> My question is: what is wrong with my current implementation that is
> causing this issue? As part of the requirement, I must be able to
> redeploy without shutting down the JVM. Any help in this matter would
> be appreciated.
I'm not sure if this is your issue but remember that in Java two
instantiations of the same class from two different class loaders are
for all intents and purposes not the same class. Given an object of
class C loaded by class loader A and another object of class C loaded by
class loader B you cannot cast from the first to the second. Jython's
duck typing protects you from some of this (e.g. within the Jythin
interpreter you can call all methods on either instantiation of C),
however if you try to pass a C instantiated by CL A to a any class
loaded in CL B that will fail.
If this sounds like your issue let me know and I can tell you more about
how we deal with this in our application (which uses multiple instances
of a custom classloader to isolate different components). Its been a
while since I've seen it but I seem to recall that the hint that I'd run
into this from within our application was getting a ClassCastException
with a message something like: 'cannot cast a foo.bar to foo.bar'.
--
-john
To be or not to be, that is the question
2b || !2b
(0b10)*(0b1100010) || !(0b10)*(0b1100010)
0b11000100 || !0b11000100
0b11000100 || 0b00111011
0b11111111
255, that is the answer.
------------------------------------------------------------------------------
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
_______________________________________________
Jython-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jython-users