1 of 1 people found this helpful
often, the wsdl is loaded from disk, rather than from the service's ?wsdl url. Check to see if the wsdl is stored on disk somewhere, or perhaps in meta-inf. Refresh all copies of it.
I did try searching for the wsdl yesterday. I even went so far as to try to search my entire computer for the phantom method name, "checkDMAS". I found nothing. But that may be a limitation of Windows Search, in Windows 7. I know that in earlier versions of Windows, the search function would ignore certain file types. I wonder if that is also happening here. I will look for a better search tool.
I was able to set Windows search to find hidden and system files, and still no luck finding the source of the phantom method.
This is highly frustrating. So who knows where these functions (JavaMethodImpl.freeze, AbstractSEIModelImpl.freeze, RuntimeModeler.buildRuntimeModel, WSServiceDelegate.addSEI, or WSServiceDelegate.getPort) get their list of method names? You would think that someone would know.
Try this. Add this line to the end of the eclipse.ini file (not sure if the file is named the same in JBDS, but there should be an ini file in the base directory):
Then run the console version of Eclipse (eclipsec.exe). This version opens a console window. Make sure you have set up Command Prompt screen buffer height to a large number, you're going to get a lot of output and you don't want it scrolling out of the buffer. Actually, you might want to start eclipsec.exe from the ocmmand line and redirect stdout and stderr to a file:
eclipsec > output.log 2>&1
Run your build/tests until you get the error. Exit Eclipse and open up that file.
This option causes the JVM to print the name of every class that was loaded and the full path for the JAR file that contains the class. This should help you find where the "hidden" JAR file is located.
I got a lot of output (12,485 lines), but no mention of the 'phantom' operation. In fact, there was no mention of any of my custom classes. That was surprising.
In that case, Eclipse is running the tests in a separate VM. I have no idea how to convince Eclipse to add those options to the java command when it runs tests. However, if you watch the running processes, and catch the java process running the unit tests, you can grab the command used to run the tests and run the same by hand from a command line, adding the option in there. If you are on Win 7 (or similar), Task Manager might show you the command line. Better yet, get Process Explorer from sysinternals - that lets you copy and paste the command line.
The command turned out to be 14,500+ characters. When I ran it separately in a .bat file, it terminated very quickly. There were only 658 lines of output, ending with:
[Loaded java.text.Format$Field from shared objects file] [Loaded java.text.MessageFormat$Field from shared objects file] Could not connect to: : 49251 java.net.ConnectException: Connection refused: connect at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.PlainSocketImpl.doConnect(Unknown Source) at java.net.PlainSocketImpl.connectToAddress(Unknown Source) at java.net.PlainSocketImpl.connect(Unknown Source) at java.net.SocksSocketImpl.connect(Unknown Source) at java.net.Socket.connect(Unknown Source) at java.net.Socket.connect(Unknown Source) at java.net.Socket.(Unknown Source) at java.net.Socket.(Unknown Source) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.connect(RemoteTestRunner.java:560) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:377) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196) [Loaded java.lang.Shutdown from shared objects file] [Loaded java.lang.Shutdown$Lock from shared objects file]
I greatly appreciate the help, Peter.
Previously, I did start a new JBDS workspace and re-extract all of the code from our SVN repository, but that has not helped. So now I think that I will take a more brute-force approach and delete just about everything but the Java and JBDS software itself, and start over.
If there are any 'cleaning' hints that you want to pass along, that would be appreciated.
I am relatively new to Java and J2EE (about 2 years), but I have long development experience prior to that, in Windows (VB) and VMS (C, Fortran). Is there any controversy in the Java world about the complexity of this environment? There is a lot going on "under the covers" in an effort to "help" the developer. In an effort to protect the developer from complexity, it creates its own complexity.
Looks like Eclipse is doing some things under the hood, part of which is opening port 49251. Don't ask me why. My recommendation: don't run the unit tests in Eclipse. Make the developers run the unit tests from the command line (you said the tests ran fine from Hudson, so make the run the same script on their desktop).
I'll add this to the long list of ways that Eclipse can make your life miserable! Personally, I only use Eclipse as a glorified text editor. I rarely use any of the supplied wizards. And I never build or run tests from within Eclipse - all that I do from the command line.
One more thought. Try both of these:
1) Create a new workspace and move your project to it. Eclipse keeps a lot of crud in the workspace/.metadata directory, perhaps that is where the old class with that method is hiding.
2) If that doesn't fix the issue, reinstall Eclipse. Taht's as simple as unzippin it into a different location (you don't evene have to remove the old one). Then run it. Perhaps there is a plugin that is mistakenly caching things in the eclipse/plugins directory (I've ran across a few plugins that do this).
Well... now I feel foolish...
I was so focused on the WSDL that I failed to notice that I had multiple copies of the client-stubs.jar file containing my generated (by wsconsume) client-side stubs. These had been generated from the OLD WSDL (including the two methods). So my service was providing the right WSDL and the right service interface, but my client was expecting an interface with two more methods.
I used a Windows tool called Astrogrep to search every file on my hard drive for the obsolete method name. It turned up in a LOT of places ... I just kept deleting those files until I hit the jar file and the light went on ....