Maven Using JAX-WS 2.1 Instead of JAX-WS 2.2

Asked 4/8, 2011 at 19:29 Answered 24/10, 2012 at 12:8

I am using Netbeans 7 with Maven 2.2.1 and jaxws-maven-plugin 1.12. Code is deployed on Glassfish 3.1 - or will be when I get it to compile :)

When I build the project, the wsimport runs as expected and generates the source files from the WSDL provided. The problem is that the build fails during the compile phase with the following three exceptions. From researching this, I see that these constructors were added from JAX-WS 2.1 to JAX-WS 2.2. My belief is that the wsimport is using JAX-WS 2.1 and the compile is using JAX-WS 2.2.

Can someone confirm my suspicion? Or, if I'm wrong, might you have an idea what may be causing this?

Thank you.

UPDATED/CLARIFICATION OF PROBLEM The Web service client extends javax.xml.ws.Service and the error is thrown when the client tries to call the super class constructor with three arguments. Since the super class doesn't have any constructor with three arguments, it fails.

javax.xml.ws.Service is found in JDK SE 1.6 and JAX-WS 2.1 as the wrong version.

javax.xml.ws.Service is found in JAX-WS 2.2 as the correct version.

The error occurs three times since it is in three overridden constructors but it's the same error so I've included it only once.

cannot find symbol
symbol  : constructor Service(java.net.URL,javax.xml.namespace.QName,javax.xml.ws.WebServiceFeature[])
location: class javax.xml.ws.Service


<plugin>
            <groupId>org.codehaus.mojo</groupId>
            <artifactId>jaxws-maven-plugin</artifactId>
            <version>1.12</version>
            <executions>
                <execution>
                    <goals>
                        <goal>wsimport</goal>
                    </goals>
                    <configuration>
                        <wsdlFiles>
                            <wsdlFile>*path to WSDL*</wsdlFile>
                        </wsdlFiles>
                        <wsdlLocation>*url to WSDL*</wsdlLocation>
                        <staleFile>${project.build.directory}/jaxws/stale/BudgetCheckingServiceService.stale</staleFile>
                    </configuration>
                    <id>wsimport-generate-BudgetCheckingServiceService</id>
                    <phase>generate-sources</phase>
                </execution>
            </executions>
            <dependencies>
                <dependency>
                    <groupId>com.sun.xml.ws</groupId>
                    <artifactId>jaxws-tools</artifactId>
                    <version>2.2.6-SNAPSHOT</version>                            
                </dependency>

                <dependency>
                    <groupId>javax.xml</groupId>
                    <artifactId>webservices-api</artifactId>
                    <version>1.4</version>
                </dependency>
            </dependencies>
            <configuration>                    
                <sourceDestDir>${project.build.directory}/generated-sources/jaxws-wsimport</sourceDestDir>
                <xnocompile>true</xnocompile>
                <verbose>true</verbose>
                <extension>true</extension>
                <catalog>${basedir}/src/jax-ws-catalog.xml</catalog>
            </configuration>
        </plugin>

Sagittal answered 4/8, 2011 at 19:29 Comment(0)

As you can see in the jaxws-maven-plugin-1.12's pom, it has the dependency jaxws-tools-2.1.7. Well, you have over-ridden it via the pom. But, this over-riding works as long as the over-rode version (2.2.6-SNAPSHOT) is api-compatible with the plugin's default version (2.1.7).

Clearly, based on your remarks, they are not api-compatible. So, as I see this won't work. Here's a reference to follow.

Run mvn install with -X flag to determine the exact version of the jaxws-tools is used by this plugin. Do a pastebin if you don't mind, then we can have a look too!

EDIT: One thing you can do is; upgrade the maven-jaxws-plugin's jaxws-tools dep to the needed version of yours. And, then fix the issues occur due to api-incompatibility (such as constructor problems.) Then send a patch to the upstream.

Shaynashayne answered 4/8, 2011 at 19:54 Comment(15)

Thank you so much for a quick answer! I'm literally out the door at this moment and cant get to this again until tomorrow morning. I'll do what you said first thing tomorrow and reply here. Once again, thank you very much. – Sagittal 4/8, 2011 at 20:16

Here is my pastebin for the debugging output it created. I wish I was a maven expert, but I am still learning how it does what it does. Thank you for helping me to interpret it. pastebin.com/FvxQXWyU – Sagittal 5/8, 2011 at 12:46

Seems the jaxws-m-p doesn't use incompatible api in 2.2.6. So, it shouldn't be a problem. Just pointing out. Correct the phrase "JAX-WS 2.1 to JAX-WS 2.1" in your question. – Shaynashayne 5/8, 2011 at 13:50

Error is same when ran outside netbeans too? Run it via command line. With your update about jdk, netbeans may probably interfering here. And, just to be clear you need 2.2 version, right? – Shaynashayne 5/8, 2011 at 14:0

Yes, the same error occurs when I run outside of Netbeans. In fact, the pastebins where done via command line mvn -X install. I've reverted back to using JAX-WS 2.1 only to see what happens. It compiles and runs correctly except that I get a run time error occasionally. javax.xml.parsers.FactoryConfigurationError: Provider org.apache.xerces.jaxp.SAXParserFactoryImpl not found I'm 95% sure this is related to JAX-WS because it only happens when I touch WS code. It was this error that started me on the path JAX-WS 2.2 which ultimately led me to my original post. Does this make sense? – Sagittal 5/8, 2011 at 14:10

I found this post that documents a problem running JAX-WS 2.1 on JSE6 - which a problem that I am having with the SAXParserFactoryImpl not found. metro.java.net/guide/Using_JAX_WS_2_1_with_JavaSE6.html - very strange. – Sagittal 5/8, 2011 at 14:12

Alright, so that's what caused this. One probable solution you can do is; shade the packages jaxws-api.jar and jaxb-api.jar, and package them in your jar. maven-shade-plugin does this nice and clear. Read about it, and make sure that's what you need. With this, this error will be gone. But, the said jars will be added to your packaged jar, so the file-size will be higher! If you find this useful, let me know. I'll add it to the answer. – Shaynashayne 5/8, 2011 at 14:35

Very interesting. I'll read up on the shade plugin right now. Thank you and I'll let you know what comes of it. You're quite helpful! – Sagittal 5/8, 2011 at 14:40

I sort of feel a little dumb right now. I'm not sure how to go about this. I'm deploying the app as a war file on Glassfish 3 running Java 6 so I don't have a jar file. Would you be able to explain how I should approach using the shade plugin please? I can provide a paste of my new pom - which I've reverted back to JAX-WS 2.1 since at least it compiles. However, the problem it seems, is related to JAX-WS 2.1 or higher running on Java 6 where class conflicts occur at runtime. As such, the shade plugin should be exactly what I need but I can't figure out how to start :) – Sagittal 5/8, 2011 at 14:55

This is getting heavy. ;) I think you should look for another approach for your original issue with org.apache.xerces.jaxp.SAXParserFactoryImpl. This class is in xercesImpl. May be you should consider using the correct version of it OR change your source to match the API provided by the xercesImpl version used. – Shaynashayne 5/8, 2011 at 15:11

I added the shade plugin to my pom and it added all the jars' class files to my war (increased the size by double) but the javax.xml.parsers.FactoryConfigurationError: Provider org.apache.xerces.jaxp.SAXParserFactoryImpl not found error was triggered again. The odd part is that the error is thrown after I run the code a second time. The first time around, the web service is consumed just fine. – Sagittal 5/8, 2011 at 15:22

You are correct. I think a different approach is worth it. I do not have xercesImpl in my project. I can add it but it seems like Glassfish would have it already? If I do add it, how can I be sure that it will take precedence over any other classes? Until you tell me otherwise, I'm going to add it the war directly using the shade plugin. I feel like I'm just guessing here :) I may have to ship some beer to Sri Lanka for all this! – Sagittal 5/8, 2011 at 15:29

I'm not sure whether SAXParserFactoryImpl issue occurs because of JAXWS-2.1. Trace back to see where this SAXPar... not found issue comes from, and be certain that your conclusions about the issue is correct. If you can do the shading, that should fix the issue IMO. I hope you've done the shadings right. The dir hierarchy in the war should show this according to the relocation rule you have applied. – Shaynashayne 5/8, 2011 at 16:24

Well, it appears to be working now but there are still questions I have about it. I am shading ALL jars including the xercesImpl, which is overkill. You are most likely correct about the Parser not found issue not being part of the JAXWS problem. It did only surface when the WS code was touched so I may have jumped to the wrong conclusion. Now that the system is functioning, I'll start working on ensuring it's build as lean as possible. So, I'll consider this answered and I thank you very much for all your help! – Sagittal 5/8, 2011 at 17:20

No problem. Glad you solved the issue. Thanks to you as well for accepting the answer. I'll edit it further so that other users don't have to go through all these comments. Regarding shading the xercelImpl; did you tried only adding it only as a dependency without shading? – Shaynashayne 5/8, 2011 at 17:29

I had a similar problem and it was solved by putting the file webservices-api.jar in my %JDK_HOME%/jre/lib/endorsed folder.

Starve answered 24/10, 2012 at 12:8 Comment(0)

Recommended topics

Hot tags