Win a copy of Terraform in Action this week in the Cloud forum!

Kevin Eddy

Ranch Hand
+ Follow
since Feb 24, 2010
Cows and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Kevin Eddy

It does seem to work, but with some effort. Helps to read the tutorial pseudo backwards.
10 years ago
If you go through that tutorial you'll likely encounter a problem with the plugin goal. It has been deprecated. You'll have to use generate. I've not went through this yet but plan on trying to struggle with it in a day or so and see what I can get working. Let us know how it works out for you.
10 years ago
YAY!! I got it going. I needed to put the lib in the tomcat endorsed directory! Thanks Lester for getting me pointed in the right direction! Most appreciated.

11 years ago

I went through the information on that link. The Endorsed Directory Mechanism link is broken however
I looked at a few other pages that talked about this and although not directly related to this specific jar, they all seemed to suggest that the new version of the jar needs to be placed in the following directory.
C:\Program Files\Java\jdk1.6.0_16\jre\lib\endorsed
So as per what I read, I gave that the ole college try. I'm experiencing the exact same issue. You wouldn't happen to have another link to the Endorsed Directory Mechanism would you?

11 years ago

Lester Burnham wrote:Isn't that the same problem you asked about earlier: ?

It is related yes. However, this question is geared to the IDE (showing one thing, packaging another). I'm actually about to dive into your posting in the Web-Services forum.
I'm encountering a NoSuchMethodError on WebFault.class (interface) which is in a Metro 2.0 jar. When I look at the jar in the the netbeans IDE, the missing method, which is named messageName(), does not appear. However, Netbeans is packaging it inside the .war file. I browsed to the jar, found the class, and decompiled it and yes the messageName() method was indeed there.

My question is why is netbeans showing me one set of source code and then packaging another?

Well, whatever is part of the NetBeans installation has no impact on Tomcat at runtime.

I guess that means Tomcat is giving me the jdk version of the jar and not the one I packaged with the war file?
11 years ago
I'm completely stumped on the cause of this error. Well not completely, I'm on to it but very confused.
I've got to daisy chain two services.

SeviceB is up and working. I write clients to it all day long no problem. Junit tested the crap out of it and it's behaving.

When I deployed ServiceA, whose only purpose is to pass the message along, that's where I run into trouble. The problem I believe is with ServiceA.

Service A is a client of serviceB. ServiceA is also a web service itself. I can invoke the ServiceA's client code (client code to serviceB) with a MAIN method on serviceA and get back successful messages. However when I deploy ServiceA and write a test client to serviceA I'm getting the following error.

ServiceA is dying when it tries to get the port so it can communicate with serviceB. I checked the logs for serviceB and nothing shows so the request isn't making it there.

Here's what I know, the missing method, messageName(), is indeed not there. The question I have is why?
I check the library inside of netbeans and the method is not there. I'm using the metro library. However, when I browse to that jar (C:\Program Files\NetBeans 6.9.1\enterprise\modules\ext\metro\webservices-api.jar) and decompile the class, the method is there. My question is how can Netbeans 6.9.1 be pulling the incorrect jar into my application?

I'm running tomcat 6.0. I searched my entire hard drive and found the jar here, C:\Sun\AppServer\lib\endorsed\webservices-api.jar, which doesn't have that method either so I renamed it with a .old extension and put what I believed the correct version would be in its place but I"m having the same issue.


11 years ago
thanks for your replies. I was able to build a validationErrorHandler and then put then error on the on the MessageContext and check for it in my service.
Super article on that here:
11 years ago
Update to this problem. The custom wsdl is being returned correctly. I had altered the soap address and that change wasn't being reflected in the wsdl. However, other changes were showing up. This means that either tomcat or the jax-ws framework edits that part of the wsdl for you and supplies you with a soap addy. Is there a way to turn off wsdl publishing all together in jax-ws?
11 years ago
I'm using netbeans 6.9.1 to build a jax-ws web service. I need to return a custom wsdl.
I've used the following annotation.

However the autogenerated wsdl is still being returned when I query the web service for the wsdl in the browser like so:

I checked the war file and it's indeed in the wsdl folder where it's supposed to be. It's also where it needs to be in tomcat.

Any ideas on why my custom wsdl isn't being returned?
11 years ago
I'm writing a jax-ws document literal soap service. I have an int as an argument. I'm have a client that I test it with. I create a HttpURLConnection and basically pump a file with a soap message to the service. This method I'm invoking takes an int as a parameter. So naturally, I sent a String over and to my surprise, jax-ws converts the String to an int with zero as the value. Id rather throw an exception. I'm not exactly sure how to go about this. I do have a soap handler on my service which dumps soap messages to an error log. Any advice as to how to return an error when the value passed is non numeric? I could just change the argument to a string and manually check once my web method begins to execute but that doesn't seem like the correct way to do this.
11 years ago

Gregg Bolinger wrote:For what's it worth, I've been using grails since version 1.1 on Windows, Linux, and OSX and I've never ever run into this problem. Of course, I have ZERO classpaths set in my system. I always set classpaths specifically at the project level (or just let the IDE do it) rather than having them global.

Gregg, that's actually a very good point about defining classpaths at the project level. Because of this issue, I've decided that system classpaths are inherently evil.
11 years ago
Well, it wasn't really the axis jar itself, but the axis classpath. The axis classpath had me put xalan, xerces, and xml-apis jars on the windows class path. Those jars were in conflict with what grails needed. When I came across that link that told me to put those jars in the grails lib directory I knew then that grails wasn't getting the correct version of those jars. When I installed grails on another machine and it ran correctly, then I knew there was something on my windows class path that was causing the issue. I'm still learning grails. I love it so far. All the nightmare wiring I've had to do in the past with maven, spring, ibatis, is largely done for you right out of the box and that's simply amazing. I was hoping to use grails for web services but it doesn't look like it can do wsdl first development which is unfortunate. There may be a plugin that supports that, but I don't know yet. I'm still learning it. It only seems to do restful services and I favor restful "jax-ws style" operations. I'm rambling now. Later!
11 years ago

Kat Light wrote:Ive been having the same issue and I tried searching everywhere!!

Hope there's someone here who can help us

You're in luck. It's definitely a classpath issue and it's specific to your machine. In my case, the issue was I inherited an axis1 web service from my predecessor. Part of the setup instructions for axis one was setting up an axis classpath on windows. The setup instructions I found required that I put xml-apis.jar and xercesImpl.jar on the windows classpath. So to make a long story short, what was happening is that grails was compiling and needed one of those jars and the operating system handed grails the jar that was defined on the windowsclasspath. Somewhere down the line that was causing some sort of class collision. In short, grails was NOT getting the correct class it needed. I finally figured out that I didn't really need to put xalan, xerces, and xml-apis jars in the lib folder. So I took them out, removed the axis1 classpath from windows and the whole thing worked magically.

It is very likely you are facing something similar. Classpath issues can be a real pain to figure out. In my case, it was approx one year since I had setup Axis1. I had completely forgotten about doing that.

What tipped me off to it not being a grails issue is two things.
1. No one else seemed to have this issue.
2. I installed on another machine and it ran flawlessly.
11 years ago