MF jsch version & ClassCastException

[King Lung Chiu]

Hi,

What version of jsch is Mediaflux using internally?

I'm having some trouble with the plugin I'm writing, which uses jsch 0.1.50, and I just wanted to check if there's any version conflict.

The specific error I'm getting is this:

--

java.lang.ClassCastException: com.jcraft.jsch.jce.KeyPairGenRSA cannot be cast to com.jcraft.jsch.KeyPairGenRSA

--

which I'm not getting in my local unit tests.

Thanks a lot, cheers,

King

[King Lung Chiu]

Also, just to add more context:

I've bundled all my dependencies into the single plugin jar for simplicity, and assume that when my plugin runs, the jsch classes in my jar will take precedence over the ones that come with Mediaflux.

Is this assumption correct?

thanks again,

King

[Evan Thomas]

We are also using 0.1.50. We had to exclude quite few Jsch classes from obfuscation in the server because of the strange way the Jsch loads classes, including com.jcraft.jsch.jce.* classes. These classes are then available in clear text to the class loader and, as Jason was explaining to me this very afternoon, the server version of the classes gets loaded first. 

You could try using plugin.module.library.add in your install script to install another copy of Jsch library along side the plugin.

Here is an example from one of our plugins:

   # Install the packages, if not already installed.

    set jar $nspace/arc-mf-hl7-plugin.jar

    set pim arc.mf.plugin.hl7.Hl7PluginModule

    if { [xvalue exists [plugin.module.exists :path $jar :class $pim]] == "false" } {

   plugin.module.add :path $jar :class $pim  :lib lib/slf4j-log4j12-1.6.6.jar

    }

    plugin.module.library.add :path $jar :class $pim :lib lib/slf4j-log4j12-1.6.6.jar

If this doesn’t work, can you provide an example that we can test with.

Thanks,

Evan.

Evan Thomas

Senior Software Engineer

ARCITECTA

5/26-36 High Street, Northcote

Victoria, Australia 3070

T:+61 3 8683 8527

M:+61 423 000 246

F:+61 3 9005 2876

Skype: evanathomas

http://www.arcitecta.com

Privileged/Confidential Information may be contained in this message. If you are not the addressee indicated in this message (or responsible for delivery of the message to such person), you may not copy or deliver this message to anyone. In such case, you should destroy this message and kindly notify the sender by reply email. Please advise immediately if you or your employer does not consent to email or messages of this kind. Opinions, conclusions and other information in this message that do not relate to the official business of Arcitecta shall be understood as neither given nor endorsed by it.

--
You received this message because you are subscribed to the Google Groups "mediaflux" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mediaflux+...@googlegroups.com.
To post to this group, send email to medi...@googlegroups.com.
Visit this group at http://groups.google.com/group/mediaflux.
For more options, visit https://groups.google.com/groups/opt_out.

[King Lung Chiu]

On 17 December 2013 22:40, Evan Thomas <evan....@arcitecta.com> wrote:

We are also using 0.1.50. We had to exclude quite few Jsch classes from obfuscation in the server because of the strange way the Jsch loads classes, including com.jcraft.jsch.jce.* classes. These classes are then available in clear text to the class loader and, as Jason was explaining to me this very afternoon, the server version of the classes gets loaded first. 

I see, thanks Evan.

It appears the selective obfuscation and the server's version of the classes taking precedence might be part of the the cause of the problems.

I also recompiled without bundling jsch so my code would rely purely on the MF supplied classes and it's now getting class not found errors. (for com.jcraft.jsch.KeyPair - looks like it's obfuscated in the supplied classes)

I'll try including the jsch lib a different way and see if fixes my problems.

Thanks,

King

[King Lung Chiu]

OK,

After experimenting with installing the library separately, I'm still getting the following error:

--

> nig.spike :genKeyPair testuser

error: executing nig.spike: [arc.mf.server.Services$ExServiceError]: call to service 'nig.spike' failed: java.lang.ClassCastException: com.jcraft.jsch.jce.KeyPairGenRSA cannot be cast to com.jcraft.jsch.KeyPairGenRSA

--

The specific line in my code causing the error:

--

     com.jcraft.jsch.KeyPair kpair = com.jcraft.jsch.KeyPair.genKeyPair(

         new JSch(), com.jcraft.jsch.KeyPair.RSA, size);

--

ie. the function called is in the external library.

My plugin module shows the library is specified:

--

> plugin.module.describe :class "nig.mf.plugin.sink.LoggingSinkModule"

    :module -class "nig.mf.plugin.sink.LoggingSinkModule" -path "/plugins/cvl-spikes-plugin.jar"

        :aid "2271"

        :services

            :service "nig.spike"

        :lib -aid "2276" "/libs/jsch-0.1.50.jar"

--

So probably 2 questions here:

1) After adding the jsch library to my plugin, does MF run the plugin with my supplied library? Or would the MF-supplied jsch library still take precedence?

2) If the latter: what JDK version should I compile my code with to match the MF code? I'm guessing this might be part of the problem.*

* I think I was told to use JDK 6, but the recent forum post seems to say otherwise.

Thanks again,

King

[King Lung Chiu]

bump