org.kxml2.io.KXmlParser
HARMAN_icraigie
Posts: 660
Anyone had issues using kxml?
Getting "java.lang.NoClassDefFoundError: org/kxml2/io/KXmlParser" from a module on an NI running firmware 4_1_373.
Getting "java.lang.NoClassDefFoundError: org/kxml2/io/KXmlParser" from a module on an NI running firmware 4_1_373.
0
Comments
Ian and I talked about this already, this is just FYI.
A lot of things have changed with duet and v4 firmware. Some of the development packages that duet developers used in the past are no longer available with the v4 firmware. For instance, a lot, if not all of the "sun" packages are no longer available. Also the Mortbay packages are not available, these specifically are removed because AMX is not using the Mortbay web server anymore. The oscar bundled packages are now broken out to separate packages, some of them are not available. The list below are the new bundles that are provided in v4.
drwx
1 user group 0 Jan 1 1980 AmxMail
drwx
1 user group 0 Jan 1 1980 AppLoader
drwx
1 user group 0 Jan 1 1980 cm
drwx
1 user group 0 Jan 1 1980 device
drwx
1 user group 0 Jan 9 15:58 duet
drwx
1 user group 0 Jan 1 1980 ftpClient
drwx
1 user group 0 Jan 1 1980 httpServer
drwx
1 user group 0 Jan 1 1980 javaxServlet
drwx
1 user group 0 Jan 1 1980 kxml
drwx
1 user group 0 Jan 1 1980 log
drwx
1 user group 0 Jan 1 1980 master
drwx
1 user group 0 Jan 1 1980 ssl
Now you can see that the kxml bundle is still available, but in order to access it you must add a new declaration into your manifest file. You should be able to add this on the last line of your manifest file, make sure no space is in front of it.
DynamicImport-Package: *
Without this new declaration, and you attempt to use a class that is available on the controller and not specifically packed in our bundle, you will get the error that you see in Ian's post.
Jeff
If you are writing modules designed to go onto systems running v4 firmware a potentially nicer approach would be to import the packages you require from the kxml library.
So as a newbie in Duet dev, what is the best way for me to handle this? I'm writing a module which I expect will need to run on both v3 and v4 firmware editions. Surely I don't have to make and distribute two versions of the module? I mean, I can cope with that if it is the only way, but.... yuck!
Where can I find out what has/has-not been dropped in v4? It seems pointless designing for v3 if v4 drops my bundle dependencies. And designing for v4 without knowing what classes are available/relocated, well that is just guess-work. My biggest concern is that if I build on v3 (since I can see what is available) my dependencies may very well be gone in v4.
Roger McLean
Swinburne University
What class is missing?
I write a lot of duet modules, and do not need to have two versions, most of the classes that where in v3 are in v4, you just need to import the packages. This may not be the best way to do it, see thread, but it is what AMX recommends.
Add to your duet manifest file on the very last line, make sure no space is in front of the line!
DynamicImport-Package: *
Jeff
Anyway, it's the weekend for me now. I'll ponder the issue next week.
Roger McLean
Swinburne University.
Before sinking down to the murky depths of the Data link layer, I'm having a go at plain http connections. The javax.microedition.io package works fine for HTTP in v3, but can't be found in v4 even after the DynamicImport-Package: * hack to the Duet manifest. This bundle interested me since I also need to do HTTPS connections, but alas even the HttpsConnection class (shown in Cafe Duet) doesn't exist in v3 firmware, and throws the following error: "javax.microedition.io.ConnectionNotFoundException: The requested protocol does not exist"
Finding the right classes to build my modules on still feels like being spun around several times, before trying to throw a rock at a can in the dark. Some documentation showing what is in the new v4 bundles would be more than handy. If I'm developing new code I can justify not supporting backwards compatibility. However I can not justify developing new code on v3 when I know, or it is very likely, that it will not work on v4.
I wonder how much time I will have to waste just hunting (in the dark) for the right bundle to build upon. While I don't like the though of it, my time may be better spent writing TLS in NetLinx. It still wouldn't address my need for Data link layer though.
Roger McLean
Swinburne University.
One thought regarding microedition.io, you could try adding the source for the classes you need to your module. I've done this with several classes that weren't a part of j2me.jar through the years.
I've got several modules with microedition.io as well as Jetty, so I decided not to move to v4 at this time. I have used AMX with Java to do some equipment monitoring systems in the past, mainly because of the hardware options, but at this point I'm moving all that to Linux.
Gday Sonny,
Thanks for the hints - I'll keep pursuing my options. I hadn't thought to include the non-included bundles... I guess I have been spoilt doing NetLinx programming for the last 10 year. I found the following is quite informative on both v3 and v4 firmware: System.getProperties().list(System.out);
Roger McLean
Swinburne University.