Replacement JAR for b89 for UPNP testing (Apr 12)

Notes on testing the latest builds of MapTool

Moderators: dorpond, trevor, Azhrei

User avatar
Azhrei
Site Admin
Posts: 12086
Joined: Mon Jun 12, 2006 1:20 pm
Location: Tampa, FL

Re: Replacement JAR for b89 for UPNP testing

Post by Azhrei »

jfrazierjr wrote:Well.. I don't have the source, but at some point it has to be turned into some type of XML document object. At that point while it's that(I can't remember off the top of my head the object name), it should be something like DomDocument which would have an load() method that would take a string as one of it's overrides which could be used to replace the existing content of the object. I do this far more often in .Net or Perl while debugging, but I have done it in the past many times in Eclipse with the Axis Soap Client... It takes a bit more doing in Java since the object model is not quite as easy to figure out as it is in .Net(though... the original MS XML 3 or 4 was FAR easier than the .Net versions!!!!)
I'll get the source up to the GitHub location. Can't do it right now, so it might be tomorrow.

User avatar
jfrazierjr
Deity
Posts: 5176
Joined: Tue Sep 11, 2007 7:31 pm

Re: Replacement JAR for b89 for UPNP testing

Post by jfrazierjr »

Azhrei wrote:
jfrazierjr wrote:Well.. I don't have the source, but at some point it has to be turned into some type of XML document object. At that point while it's that(I can't remember off the top of my head the object name), it should be something like DomDocument which would have an load() method that would take a string as one of it's overrides which could be used to replace the existing content of the object. I do this far more often in .Net or Perl while debugging, but I have done it in the past many times in Eclipse with the Axis Soap Client... It takes a bit more doing in Java since the object model is not quite as easy to figure out as it is in .Net(though... the original MS XML 3 or 4 was FAR easier than the .Net versions!!!!)
I'll get the source up to the GitHub location. Can't do it right now, so it might be tomorrow.
That's fine... if you have a way to mock up a web server to provide the input stream from a hard coded XML, that will do that trick also, though my method is more dynamic. The problem comes with using libraries that actually are built correctly, so if the stuff used by sbbi is stupid, then it may be far more painful that it should be and your approach may be far easier to handle(even if it's not as dynamic in "real time" to modify.). It really just depends on if the XML Parser used has something analogous to a load(String) as well as a load(InputStream) methods, and I know for a fact some libraries were just written rather short sightedly in this regard.
I save all my Campaign Files to DropBox. Not only can I access a campaign file from pretty much any OS that will run Maptool(Win,OSX, linux), but each file is versioned, so if something goes crazy wild, I can always roll back to a previous version of the same file.

Get your Dropbox 2GB via my referral link, and as a bonus, I get an extra 250 MB of space. Even if you don't don't use my link, I still enthusiastically recommend Dropbox..

User avatar
wolph42
Winter Wolph
Posts: 9999
Joined: Fri Mar 20, 2009 5:40 am
Location: Netherlands
Contact:

Re: Replacement JAR for b89 for UPNP testing

Post by wolph42 »

Azhrei wrote: All I can suggest is to redo the INSTALL steps from the beginning: put a fresh copy of MT in a directory and go through the a
I did exactly that. 2 fresh downloads 5 tests in total they all failed and all with the same error and lees dev is still working. I was really really thorough.

User avatar
Azhrei
Site Admin
Posts: 12086
Joined: Mon Jun 12, 2006 1:20 pm
Location: Tampa, FL

Re: Replacement JAR for b89 for UPNP testing

Post by Azhrei »

Crud.

And Lee's build is using the sbbi-upnp library? And the older commons-jxpath library as well, I presume?

To update to the newer JXPath library there were others that needed updating, including sbbi-upnp. My guess is that he is using the JAR that came with b87, which means his JAR doesn't even support the XML namespace elements, nor would it have the off by one fixes that I just made. Is this the build that even uses the sbbi-upnp library or is it using the cling library?

We won't be including cling in MT since the library is quite large. I'd like to find a single library that supports both UPNP 1.1 and NAT-PMP but some simple Google searches hasn't found anything yet.

I'm going to try the debugging technique discussed above and see if I can recreate your issue, wolph, without actually having your router. I'll report back later today. Thanks for all of your efforts!

User avatar
wolph42
Winter Wolph
Posts: 9999
Joined: Fri Mar 20, 2009 5:40 am
Location: Netherlands
Contact:

Re: Replacement JAR for b89 for UPNP testing

Post by wolph42 »

You're welcome. Let me know if you need anything. I've got a presentation tomorrow for the russian minister of education together with a huge delegation of university directors. I'll be working on that and after that I have a full weekend for myself to work on mt or do testing!

User avatar
jfrazierjr
Deity
Posts: 5176
Joined: Tue Sep 11, 2007 7:31 pm

Re: Replacement JAR for b89 for UPNP testing

Post by jfrazierjr »

Azhrei wrote: Is this the build that even uses the sbbi-upnp library or is it using the cling library?
I think that his build is using both and that it may still be failing with sbbi, but then cling picks it up and completes so it appears seamless to the end user. I could be wrong about that, but that's what I recall from Lee's thread and testing(though I never tested it myself.)
Azhrei wrote: I'm going to try the debugging technique discussed above and see if I can recreate your issue, wolph, without actually having your router. I'll report back later today. Thanks for all of your efforts!
I did happen to find "a" bit of source code out there on the interwebs(looks like it might have been a fork or at least a full copy to maintain the source somewhere) and unless the version you have is built drastically different from what I saw, my approach will be far more a PITA than is should be and your original thought approach would likely take you far less time to implement a small server at a URL and return the mocked up xml in an InputStream.

rant on stupid people
darn... I hate xml parsers that do stupid stuff like that where the only input method for an xml document(or whatever they call it) is from an InputStream or something like that. There is no reason why developers of such libraries can't support something like load(String) just as easily as load(InputStream) or it's equivalent other than pure darn laziness. This just makes real time debugging and swapping of xml content far darn harder than it really should be.. shame on you....bad developers, bad!!!
I save all my Campaign Files to DropBox. Not only can I access a campaign file from pretty much any OS that will run Maptool(Win,OSX, linux), but each file is versioned, so if something goes crazy wild, I can always roll back to a previous version of the same file.

Get your Dropbox 2GB via my referral link, and as a bonus, I get an extra 250 MB of space. Even if you don't don't use my link, I still enthusiastically recommend Dropbox..

User avatar
Azhrei
Site Admin
Posts: 12086
Joined: Mon Jun 12, 2006 1:20 pm
Location: Tampa, FL

Re: Replacement JAR for b89 for UPNP testing

Post by Azhrei »

response to jfrazierjr
Well, the devs of the parsers do that so they can support arbitrarily large incoming data streams! You've only got X amount of memory but the data stream could be infinitely sized.

Of course, if you're using a DOM then it doesn't matter cuz the whole thing has to fit into RAM anyway (which I suppose makes using a stream even more important or twice the memory would be used). With SAX it's not quite so terrible, but then SAX parsers are a bigger pain to write if you're only looking for certain elements...
my programming solution
Anyway, I did create a solution. The JXPathParser is a wrapper around the XMLParser that is used by the UPNP library. The wrapper helps trap XML that wouldn't validate but the library wants to be lenient and accept anyway. So I hooked into that and when it goes to do some error checking on the entire input it reads it into a String. Heh, there's my hook. :D

So I found the problem. There are a bunch of variables whose names end with "Ctx" (for context). They're used all over the place -- the code searches for a particular XML element, like "upnp:root/upnp:iconList" and then uses that context to do another search for the "upnp:icon[1]" that's inside there. The problem was that "iconListCtx" is different from "deviceCtx" and there was a simple typo in that the wrong variable name was being used! :?
Whew. So wolph's and cif's XML now make it through the parser. I'm hoping the updated JAR in the OP will fix their router problems and I'll probably wait on b90 until I hear from one of them. Or from someone else that has a router that reports an "iconList" and has verified that it doesn't break...

I'm pretty confident about this so I may do the build tonight even without confirmation.

Edit: I've committed the code to github.com:RPTools/upnplib.git if you want to look at it. Note that it doesn't build under Maven yet. I'm fairly new to the Maven command line so I'm still getting a handle on things, but it builds in Eclipse just fine. Note that the src/net/sbbi/upnp/jmx package needs to be excluded from the build (part the Maven problem re: libraries).
Last edited by Azhrei on Fri Apr 12, 2013 5:47 pm, edited 4 times in total.
Reason: added github reference

User avatar
CoveredInFish
Demigod
Posts: 3104
Joined: Mon Jun 29, 2009 10:37 am
Location: Germany
Contact:

Re: Replacement JAR for b89 for UPNP testing (Apr 12)

Post by CoveredInFish »

It doesnt seem to work .. no luck starting a server and on quit i have an NPE.
I can post the logfile but not right now - no time.
crash dump
java.lang.reflect.UndeclaredThrowableException
at com.sun.proxy.$Proxy0.handleQuit(Unknown Source)
at com.apple.eawt._AppEventLegacyHandler$7.dispatchEvent(_AppEventLegacyHandler.java:146)
at com.apple.eawt._AppEventLegacyHandler.sendEventToEachListenerUntilHandled(_AppEventLegacyHandler.java:168)
at com.apple.eawt._AppEventLegacyHandler.handleQuitRequestWith(_AppEventLegacyHandler.java:144)
at com.apple.eawt._AppEventHandler$_QuitDispatcher.performUsing(_AppEventHandler.java:387)
at com.apple.eawt._AppEventHandler$_QuitDispatcher.performUsing(_AppEventHandler.java:380)
at com.apple.eawt._AppEventHandler$_AppEventDispatcher$1.run(_AppEventHandler.java:489)
at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:209)
at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:708)
at java.awt.EventQueue.access$400(EventQueue.java:82)
at java.awt.EventQueue$2.run(EventQueue.java:669)
at java.awt.EventQueue$2.run(EventQueue.java:667)
at java.security.AccessController.doPrivileged(Native Method)
at java.security.AccessControlContext$1.doIntersectionPrivilege(AccessControlContext.java:87)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:678)
at net.rptools.maptool.client.swing.MapToolEventQueue.dispatchEvent(MapToolEventQueue.java:38)
at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:296)
at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:211)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:201)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:196)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:188)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:122)
Caused by: java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at net.rptools.maptool.client.ui.OSXAdapter.callTarget(OSXAdapter.java:154)
at net.rptools.maptool.client.ui.OSXAdapter.invoke(OSXAdapter.java:165)
... 22 more
Caused by: java.lang.NoClassDefFoundError: net/sbbi/upnp/messages/UPNPResponseException
at net.rptools.maptool.client.MapTool.disconnect(MapTool.java:1021)
at net.rptools.maptool.client.ui.MapToolFrame.close(MapToolFrame.java:1334)
at net.rptools.maptool.client.ui.MapToolFrame.closingMaintenance(MapToolFrame.java:1329)
at net.rptools.maptool.client.AppActions$66.execute(AppActions.java:2578)
at net.rptools.maptool.client.ui.MapToolFrame.macOSXExit(MapToolFrame.java:406)
... 28 more
Caused by: java.lang.ClassNotFoundException: net.sbbi.upnp.messages.UPNPResponseException
at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
... 33 more

User avatar
jfrazierjr
Deity
Posts: 5176
Joined: Tue Sep 11, 2007 7:31 pm

Re: Replacement JAR for b89 for UPNP testing (Apr 12)

Post by jfrazierjr »

CoveredInFish wrote: ....
Caused by: java.lang.NoClassDefFoundError: net/sbbi/upnp/messages/UPNPResponseException
at net.rptools.maptool.client.MapTool.disconnect(MapTool.java:1021)
at net.rptools.maptool.client.ui.MapToolFrame.close(MapToolFrame.java:1334)
at net.rptools.maptool.client.ui.MapToolFrame.closingMaintenance(MapToolFrame.java:1329)
at net.rptools.maptool.client.AppActions$66.execute(AppActions.java:2578)
at net.rptools.maptool.client.ui.MapToolFrame.macOSXExit(MapToolFrame.java:406)
... 28 more
Caused by: java.lang.ClassNotFoundException: net.sbbi.upnp.messages.UPNPResponseException
at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
... 33 more[/spoiler]
That makes it seem like either the updated sbbi jar file was not "installed" correctly(ie, you did not follow the right steps) or(my first instinct without digging deeper) the jar file did not build all of the class files needed to make a "complete" jar(or not in the correct folder structure).
I save all my Campaign Files to DropBox. Not only can I access a campaign file from pretty much any OS that will run Maptool(Win,OSX, linux), but each file is versioned, so if something goes crazy wild, I can always roll back to a previous version of the same file.

Get your Dropbox 2GB via my referral link, and as a bonus, I get an extra 250 MB of space. Even if you don't don't use my link, I still enthusiastically recommend Dropbox..

User avatar
jfrazierjr
Deity
Posts: 5176
Joined: Tue Sep 11, 2007 7:31 pm

Re: Replacement JAR for b89 for UPNP testing (Apr 12)

Post by jfrazierjr »

jfrazierjr wrote:
CoveredInFish wrote: ....
Caused by: java.lang.NoClassDefFoundError: net/sbbi/upnp/messages/UPNPResponseException
at net.rptools.maptool.client.MapTool.disconnect(MapTool.java:1021)
at net.rptools.maptool.client.ui.MapToolFrame.close(MapToolFrame.java:1334)
at net.rptools.maptool.client.ui.MapToolFrame.closingMaintenance(MapToolFrame.java:1329)
at net.rptools.maptool.client.AppActions$66.execute(AppActions.java:2578)
at net.rptools.maptool.client.ui.MapToolFrame.macOSXExit(MapToolFrame.java:406)
... 28 more
Caused by: java.lang.ClassNotFoundException: net.sbbi.upnp.messages.UPNPResponseException
at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
... 33 more[/spoiler]
That makes it seem like either the updated sbbi jar file was not "installed" correctly(ie, you did not follow the right steps) or(my first instinct without digging deeper) the jar file did not build all of the class files needed to make a "complete" jar(or not in the correct folder structure).
Weird... inside the jar file, the class appears to be right, so that's very odd. CiF, could you make sure that you don't have the either of the other sbbi* files in the lib folder? It's possible that if something was moved around in the code, that the wrong version is loading or some other such oddness, but that would be really odd...
I save all my Campaign Files to DropBox. Not only can I access a campaign file from pretty much any OS that will run Maptool(Win,OSX, linux), but each file is versioned, so if something goes crazy wild, I can always roll back to a previous version of the same file.

Get your Dropbox 2GB via my referral link, and as a bonus, I get an extra 250 MB of space. Even if you don't don't use my link, I still enthusiastically recommend Dropbox..

User avatar
Azhrei
Site Admin
Posts: 12086
Joined: Mon Jun 12, 2006 1:20 pm
Location: Tampa, FL

Re: Replacement JAR for b89 for UPNP testing (Apr 12)

Post by Azhrei »

The filename was probably not changed after being copied. This line:

Code: Select all

Caused by: java.lang.NoClassDefFoundError: net/sbbi/upnp/messages/UPNPResponseException
says that the class couldn't be found, but it's easily seen inside the JAR file. Since the MANIFEST.MF in the main MapTool JAR has the classpath's library name hard-coded to be "sbbi-upnplib-1.0.5-nodebug.jar" or "sbbi-upnplib-1.0.5-debug.jar", it will only find it under one of those names.

My guess is the filename extension didn't get changed! :D

User avatar
CoveredInFish
Demigod
Posts: 3104
Joined: Mon Jun 29, 2009 10:37 am
Location: Germany
Contact:

Re: Replacement JAR for b89 for UPNP testing (Apr 12)

Post by CoveredInFish »

I'll do install it fresh again, but it'll won't happen before tomorrow - hell of a work day today :-( I would surprised if it was such a stupid mistake on my side, but then ... not that it never happened before.

I did have checked that I renamed the zip to jar and that there is only one sbbi*.jar in the lib-folder.

Wait ... the version number is different ... did I missed the instructions to change that? Ah yes... didnt remember that. Hmm ... nah ... changing it to "sbbi-upnp-1.0.5-nodebug.jar" doesnt help, nor "sbbi-upnp-1.0.4-nodebug.jar".

Well ... out of time now ... back on it asap.

User avatar
wolph42
Winter Wolph
Posts: 9999
Joined: Fri Mar 20, 2009 5:40 am
Location: Netherlands
Contact:

Re: Replacement JAR for b89 for UPNP testing (Apr 12)

Post by wolph42 »

ok:
-redownloaded b89
-installed it
-deleted the both upnp libraries from the lib dir
- renamed the .zip to: sbbi-upnplib-1.0.5-nodebug.jar
- moved it into the lib dir
- started MT (failed due to j7 bug) edited .bat file and started again: it ran
- started server, upnp selected, port 51234
... good and bad news: not the previous error I was getting upto now... but getting a new error...
... forgot to clear the log, so closed mt , cleared log and tried again
- same error, but I did notice that the server HAD started, so started a second instance of MT and tried to connect remotely (it does show up in the list), but that gave a connection timeout.

log is attached. Note that the second instance of MT will also be part of this log, so it might be a bit confusing.
This was the error on screen
2013-04-13 14:14:47,303 [client.MapTool:291] ERROR - While configuring UPnP (2)
java.lang.RuntimeException: Error during lazy SCDP file parsing at http://192.168.178.1:49000/igdconnSCPD.xml
at net.sbbi.upnp.services.UPNPService.parseSCPD(UPNPService.java:207)
at net.sbbi.upnp.services.UPNPService.lazyInitiate(UPNPService.java:274)
at net.sbbi.upnp.services.UPNPService.getUPNPServiceAction(UPNPService.java:114)
at net.sbbi.upnp.messages.UPNPMessageFactory.getMessage(UPNPMessageFactory.java:58)
at net.sbbi.upnp.impls.InternetGatewayDevice.addPortMapping(InternetGatewayDevice.java:372)
at net.rptools.maptool.util.UPnPUtil.openPort(UPnPUtil.java:73)
at net.rptools.maptool.client.AppActionsrun(AppActions.java:1812)
at net.rptools.maptool.client.AppActions$ClientActionrun(AppActions.java:2708)
Caused by: java.lang.IllegalArgumentException: Unable to find any state variable named PortMappingNumberOfEntries for service urn:upnp-org:serviceId:WANIPConn1 action GetGenericPortMappingEntry argument NewPortMappingIndex
at net.sbbi.upnp.services.UPNPService.parseSCPD(UPNPService.java:192)
... 7 more

User avatar
jfrazierjr
Deity
Posts: 5176
Joined: Tue Sep 11, 2007 7:31 pm

Re: Replacement JAR for b89 for UPNP testing (Apr 12)

Post by jfrazierjr »

I checked the code on github(just browsed.. did not do a get of the code)... I thought here is that parseServiceStateVariables() has a problem similar to what Azhrei found with the iconList stuff where the wrong variable is being searched and thus no ServiceStateVariables are created... then the place where it explodes is failing because it can't find what it's looking for....
I save all my Campaign Files to DropBox. Not only can I access a campaign file from pretty much any OS that will run Maptool(Win,OSX, linux), but each file is versioned, so if something goes crazy wild, I can always roll back to a previous version of the same file.

Get your Dropbox 2GB via my referral link, and as a bonus, I get an extra 250 MB of space. Even if you don't don't use my link, I still enthusiastically recommend Dropbox..

User avatar
Azhrei
Site Admin
Posts: 12086
Joined: Mon Jun 12, 2006 1:20 pm
Location: Tampa, FL

Re: Replacement JAR for b89 for UPNP testing (Apr 12)

Post by Azhrei »

Thanks wolph; thanks Joe.

I'll take a look at the UPNP stuff right now before I do b90. I'd like to get this done so we don't need a b91! :?

Also working on the keypress-causes-NPE-immediately issue. I have a campaign file to try it out with and see if I can reproduce it.

Post Reply

Return to “Testing”