Hi Chris,

Thank you for your suggestions. That brought me a step further. I tried
using the S7 manually and it works!

I will try to work on finding more about the class loading issue again
soon. Just to keep you all updated and document my findings:

I have a new error now. The PlcDriverManager gets the Clasloader from
the current thread. I found out that you can set the Classloader like this:

 ClassLoader cl = ClassLoader.getSystemClassLoader();
 Thread.currentThread().setContextClassLoader(cl);

That results in a different log output
PlcDriverManager: Instantiating new PLC Driver Manager with class loader
dalvik.system.PathClassLoader[DexPathList[[directory
"."],nativeLibraryDirectories=[/system/lib, /system/lib]]]
PlcDriverManager: Registering available drivers...
Unable to find driver for protocol 's7'

Now the driver manager seems to a have Classloader but still cannot load
the driver classes. Like you said the Dalvik system seems to work
differently.

Let's see if I can find something new next time.

Kind regards
Niklas


Am 08.01.20 um 10:56 schrieb Christofer Dutz:
> Hi Niklas,
> 
> Herhaps you need to manually build a classloader? But I don't quite know how 
> this is done. As far as I understood it, the Dalvik system is more a 
> cross-compilation thing that compiles Java bytecode to something Android can 
> run.
> You can probably just not use the DriverManager and instantiate the Driver 
> classes manually as a first test. This way you would avoid all of our 
> classloading-magic. 
> 
> Chris
> 
> 
> Am 07.01.20, 23:03 schrieb "Niklas Merz" <[email protected]>:
> 
>     Hello again,
>     
>     Julian motivated me and I quickly cobbled together a PLC4X Cordova
>     plugin to see if it works. I can now call PLC4X via Javascript in a web
>     app bundled with Cordova for Android :-).
>     
>     But I got the first problem. Seems like Cordova does class loading
>     differently than my pure Android example. PLC4X cannot load the S7
>     driver and fails at init.
>     
>     Android Log:
>     Instantiating new PLC Driver Manager with class loader
>     dalvik.system.PathClassLoader
>     
>     Cordova Log:
>     org.apache.plc4x.java.PlcDriverManager: Instantiating new PLC Driver
>     Manager with class loader null
>     
>     I am not really a Java expert but you may know how to fix this.
>     
>     Here is my plugin which is a PoC right now:
>     https://github.com/NiklasMerz/cordova-plugin-plc4x
>     
>     Niklas
>     
>     Am 07.01.20 um 21:06 schrieb Julian Feinauer:
>     > Whoop, whoop Niklas!
>     > Thanks for your work!
>     > 
>     > Julian
>     > 
>     > Von meinem Mobiltelefon gesendet
>     > 
>     > 
>     > -------- Ursprüngliche Nachricht --------
>     > Von: Niklas Merz <[email protected]>
>     > Datum: Di., 7. Jan. 2020, 20:56
>     > An: [email protected]
>     > Betreff: Re: PLC4X on Android?
>     > Hi all,
>     > 
>     > Turns out Netty seems to work just fine on Android, but we forgot to
>     > give the app network permission. I just pushed the latest changes to
>     > my example project and you can use for demos etc as you like.
>     > 
>     > https://github.com/NiklasMerz/plc4x-android-demo
>     > 
>     > The Android app project itself is not that special. I just added some
>     > dependencies and config code to get log4j properly working and did the
>     > permission requests.
>     > 
>     > Regards Niklas
>     > 
>     > Am 07.01.20 um 14:00 schrieb Christofer Dutz:
>     >> Hi Julian,
>     >>
>     >> I'll trust on your judgement here ... just wanted to mention we're 
> using OIO stuff ... so we keep it on the radar.
>     >>
>     >> Chris
>     >>
>     >> Am 07.01.20, 13:05 schrieb "Julian Feinauer" 
> <[email protected]>:
>     >>
>     >>     Hi Chris,
>     >>
>     >>     its not black and white.
>     >>     And Oio is deprecated for Netty 4.x but will be available till 
> Netty 5 comes out.
>     >>     And I discussed the RawSocket thing with Norman Maurer (Maintainer 
> of Netty) and he himself suggested/agreed to go with Oio for this use case as 
> the way Pcap works is more Oio-esque than Nio-esque so I did that.
>     >>     To Migrate it would mean 2 days of coding and whats really worse, 
> to hack a Nio-esque behavior for Pcap which would be pretty complex software 
> and hard to maintain.
>     >>     So I finally chose to go with Oio as its only deprecated to be 
> taken off maintenance and not because of stability or security or whatever.
>     >>
>     >>     Thus, it depends : )
>     >>
>     >>     Julian
>     >>
>     >>     Am 07.01.20, 12:53 schrieb "Christofer Dutz" 
> <[email protected]>:
>     >>
>     >>         Hi Julian,
>     >>
>     >>         Then we should update the RawSocketChannel as that is based on 
> OIO ...
>     >>         the PCAP Channel I don't really care as it's for testing and 
> development only anyway.
>     >>
>     >>         Chris
>     >>
>     >>         Am 07.01.20, 12:46 schrieb "Julian Feinauer" 
> <[email protected]>:
>     >>
>     >>             Hi Chris,
>     >>
>     >>             I agree that we should never use Oio for Productive Code 
> (instead of Serial where its fine, I think).
>     >>             But, yes, we could add other transports for "edge" cases 
> or something.
>     >>             Currently that’s just a toy project we try to get running, 
> but I see some interesting options there : )
>     >>
>     >>             Julian
>     >>
>     >>             Am 07.01.20, 12:39 schrieb "Christofer Dutz" 
> <[email protected]>:
>     >>
>     >>                 Hi all,
>     >>
>     >>                 I Think the OIO options are usually marked as 
> deprecated in favor of NIO.
>     >>
>     >>                 But I think we could do one thing. The same way I can 
> pass in a different ChannelFactory for testing or PCAP input or whatever we 
> want to use, we could have additional TCP channel-factories that explicitly 
> use OIO.
>     >>                 Then we could add a parameter such as 
> "androidCompatability=true" to the string and use that instead?
>     >>
>     >>                 Would that be an option?
>     >>
>     >>                 Chris
>     >>
>     >>
>     >>
>     >>                 Am 07.01.20, 12:01 schrieb "Julian Feinauer" 
> <[email protected]>:
>     >>
>     >>                     Hi folks,
>     >>
>     >>                     yesterday our good friend @Niklas 
> Merz<mailto:[email protected]> did a little bit of Android Vodoo to make 
> an Example of PLC4X for Android here: 
> https://github.com/NiklasMerz/plc4x-android-demo
>     >>                     So does PLC4X work on Android? No, not really…
>     >>
>     >>                     It turns out, that Netty does not really work on 
> Android (well it does but not with our settings)…
>     >>                     So we could see how far we’d like to push that.
>     >>                     As it seems one way could be to use Oio Instead of 
> Nio 
> (https://stackoverflow.com/questions/11007879/client-server-application-for-android-with-netty-integration).
>     >>                     Currently I see no need for that, but I think its 
> an interesting Idea (not talking about if someone should really do it, but 
> COULD do it).
>     >>                     If I find some time I will create a branch which 
> builds Netty on Oio instead of Nio and test it further with Niklas.
>     >>
>     >>                     Best
>     >>                     Julian
>     >>
>     >>
>     >>
>     >>
>     >>
>     >>
>     >>
>     >>
>     >>
>     >>
>     
> 

Reply via email to