I have a WSDL and have generated code using wsimport. I have written code to the access the web service & trying to test it. It works on Tomcat, but on JBOSS 5.1 GA, it gives following error:
org.jboss.ws.metadata.wsdl.WSDLException_ Invalid default namespace_ null
I have spent 3 days figuring out the problem with no luck. One os the solutions that I tried involved jaxws-rt files & working with the jboss endorsed directory, but I am not sure which jars that need to be replaced, so I am still stuck.
Any help would be very appreciated.
I guess you already fixed this issue, but just in case someone is interested.
I had the same problem deploying a USSD gateway with Mobicents Jain Slee, that runs on top of a JBoss AS 5.1.0 GA. The gateway has to connect to a server via SOAP, so I chose JAX-WS and generated the source code from a WSDL with wsimport.
By the way, I used a similar procedure to this one to create a child Maven project and generate the java files for JAX-WS.
Failed deploy with dependencies embedded on .war file
My first approach was to include all the dependencies in the .war file that is deployed in JBoss.
I think this is achieved by default in Maven, and mvn install will do it.
In the long run, this approach failed, but at least I needed to know the list of jar files that were included in the .war file, to copy them later in a JBoss directory.
I made a lot of troubleshooting with this approach, and had many different log errors, though the main one was this:
java.util.ServiceConfigurationError: javax.xml.ws.spi.Provider: Provider org.jboss.ws.core.jaxws.spi.ProviderImpl not a subtype
That can be found in this other StackOverflow question.
Deploy without dependencies
Maven tweak
So insted, I added <scope>provided</scope> to the JAX-WS dependencies. Something like:
<dependency>
<groupId>com.sun.xml.ws</groupId>
<artifactId>jaxws-rt</artifactId>
<version>2.2</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>com.sun.istack</groupId>
<artifactId>istack-commons-runtime</artifactId>
<version>2.2</version>
<scope>provided</scope>
</dependency>
This produced a much lighter .war file.
Copy & remove jars in JBoss AS
Now, after deploying the .war file, when my SOAP client tries to connect to the Web Service, it throws the exception mentioned in the question:
org.jboss.ws.metadata.wsdl.WSDLException: Invalid default namespace: null
at org.jboss.ws.tools.wsdl.WSDLDefinitionsFactory.parse(WSDLDefinitionsFactory.java:134)
at org.jboss.ws.metadata.umdm.ServiceMetaData.getWsdlDefinitions(ServiceMetaData.java:293)
at org.jboss.ws.metadata.builder.jaxws.JAXWSClientMetaDataBuilder.buildMetaData(JAXWSClientMetaDataBuilder.java:84)
at org.jboss.ws.core.jaxws.spi.ServiceDelegateImpl.<init>(ServiceDelegateImpl.java:138)
at org.jboss.ws.core.jaxws.spi.ProviderImpl.createServiceDelegate(ProviderImpl.java:63)
at javax.xml.ws.Service.<init>(Service.java:79)
at org.ortelius.UssdServiceImplementation.<init>(UssdServiceImplementation.java:42)
at org.ortelius.OrteliusClient.sendUssdRequestToWs(OrteliusClient.java:28)
It seems that javax.xml.ws.Service calls org.jboss.ws.core.jaxws.spi.ProviderImpl, but it should be calling com.sun.xml.ws.spi.ProviderImpl, so it seems there is a conflict with jar dependencies.
To avoid this problem, it was necessary to:
Move or delete all JBoss jar files found in $JBOSS_HOME/lib/endorsed/ directory.
Copy the jars bundled in my initial .war file (the one of the failed deploy) to $JBOSS_HOME/lib/endorsed/ directory.
all the jars bundled in my .war file.
That basically made it.
Final notes
I have to confess that to find this out was a real pain, and it took me about four days to get this up & running.
I made a lot of troubleshooting with the jar dependencies, checking JBoss logs, remote debugging, comparing Java packages & classes versions, searching for jars online and reading many articles from JBoss manuals, blogs, StackOverflow, JavaRanch, etc...
The SOAP client was really simple, but the deployment in JBoss was pretty problematic.
My solution is not very orthodox, since it depends greatly on the jar files dependencies.
So I'm not sure if it will work for everyone.
Regards.
Related
I recently started learning more about JBoss Application sever. After installation I was looking inside all directories created by JBoss installation. (I'm using JBoss AS version - jboss-5.0.1.GA)
I referred documentation available at this link
It says 'client' directory contains Jar files needed by remote clients.
client: The JARs that are required for clients that run outside of JBoss are located in the client directory.
When I looked inside 'client' directory after installation, it contains 90 jar files overall. Does that mean If I create a remote ejb client I would need to include all the 90 jars in my remote application classpath?
With JBoss AS 5.x things got complicated.
Placing all of the client jar files on classpath will certainly work.
In JBoss 4.x there was an option to use jbossall-client.jar which integrated other numerous client libs into single file. If you'll look into same named jar in JBoss 5.x you'll find out that it's reduced to manifest referencing other jars. Placing this single jar in your classpath will work as long as all of the jars referenced by manifest are present in the same directory.
If accessing remote EJB is all you need then only a subset of jars is required, unfortunatelly it's hard to tell which ones is it.
Following this coderanch link (I've found it here on SO) you'll find such subset prepared for JBoss 5.1.0.GA.
Be warned though, list of jars published on coderanch has abbreviated names, some misquotations and at least two jars are not present in server version 5.0.1. If reducing number of dependencies is your priority, use this list wisely and enhance/extend it by trials and errors.
I am developing a Java EE 6 bottom-up JAX-WS to expose an EJB3.1 stateless session bean. The web service in a WAR is failing to install on deployment because it references an external jar (or shared library) which one can assume is not loaded yet.
The common suggestion is to include the jars in the /lib folder, which does fix the issue, however the jars need to remain in this external shared library location and NOT in the ear file, because they amount to 30MB.
What are some techniques to get around this issue in a Websphere (WAS v.8) environment or any server environment.
Some suggestions I have found include:
1. define classpath in META-INF file.
2. define the resources in deployment.xml
3. alter class loading order
4. (from ibm) In the case where the jars are part of a Shared Library configured on WebSphere Application Server, then a User Library must be used to configure the project for development before generating the WebService.
However, I have been unsuccessful to find any help online in these areas. Is there another technique or does anyone know anything about accomplishing this? Thanks in advance.
EDIT: If I specify the libraries in the META-INF using class-path, they are loaded before extensions, shared libraries..etc, but they are still loaded after the WAR which is not good. Again, this isn't a runtime issue because the web services are created at deployment on the fly.
I submitted a ticket to IBM. The libraries referenced by the web service are needed during deployment and must be bundled into the Ear in some fashion. I threw them in the web-inf/lib folder. However, if the referenced libraries then depend on additional libraries, these can be placed in the Shared Libraries. Seems odd to me too, but let's all just admit "shared libraries" are a hack anyways.
If you still have issues, just make sure your class loading is set to parent_last.
What libraries are required to run a Web Service Client that has been generated from Axis 2 on JBoss. So far I have not found anything in my searches.
I assume that the following error:
org.jboss.xb.binding.JBossXBRuntimeException: Failed to create a new SAX parser
Is due to the fact that I have place every jar file from Axis lib folder into my projects
My Solution
Did it the hard way - added and subtracted jars from my lib directory until I got it to deploy and run with no exceptions
Is what you have pasted the root cause of the stack trace? In case it is not, the problem is that probably your app is deployed with xerces related jar files in it (ex: xercesImpl-x.x.x.jar). JBoss is shipped with the xerces jars in its JBOSS_HOME/lib/endorsed folder. If the same classes are deployed with your web app this may result in class loading issues.
You can try to remove the xerces libs from your app and then test the web service client again.
Cheers!
We've been using WAS 6.1 so far to deploy our web apps. Now we need to migrate to an economics-savvy Tomcat + OpenEJB solution. The OpenEJB 3.1.2 container is plugged into Tomcat 6.18, no standalone OpenEJB server here.
So here I am, trying to deploy my EJB 2.1 objects into OpenEJB...
My problem is that the EJBs code requires external .jar libraries, and I don't know where to put them so that they are actually taken into account into the container's classpath. It works fine into catalina.home/lib, so it does into openejb.home/lib. But still I'd rather find out a way to package the EJBs so that they are easy deployed with their linked .jar dropped right into place to be used by the OpenEJB container.
It can include building up an .ear or a .jar with the right descriptor files... Any solution that works is good enough for me.
Can possibly anyone help?
Ear Approach
You can just drop it into the Tomcat webapps/ directory and it will be picked up.
Example ear (valid):
myapplication.ear
lib/
lib/libraryOne.jar
lib/libraryTwo.jar
redEjbs.jar
blueEjbs.jar
Common mistake (invalid):
myapplication.ear
libraryOne.jar (err. not a javaee module)
libraryTwo.jar (err. not a javaee module)
redEjbs.jar
blueEjbs.jar
Only Java EE modules are allowed at the root. These are EJB jars, .war files, Connector .rar files and Application Client jars. Prior to Java EE 5, libraries had to be explicitly listed in an application.xml file. Java EE 5 and forward they can be added to a lib/ directory and be understood to be just plain jars as opposed to a Java EE module.
Collapsed EAR approach
In OpenEJB/Tomcat you can put all your libraries into the war file and be free of the ear concept. This is now part of Java EE 6.
mywebapp.war
WEB-INF/lib/libraryOne.jar
WEB-INF/lib/libraryTwo.jar
WEB-INF/lib/redEjbs.jar
WEB-INF/lib/blueEjbs.jar
Common mistake, including specs:
mywebapp.war
WEB-INF/lib/javax.ejb.jar (err. clashes with the related system library)
WEB-INF/lib/libraryOne.jar
WEB-INF/lib/libraryTwo.jar
WEB-INF/lib/redEjbs.jar
WEB-INF/lib/blueEjbs.jar
Doesn't sound like that is the issue, but adding for completeness.
Common mistake, broken dependencies:
tomcat/lib/libraryTwo.jar
mywebapp.war
WEB-INF/lib/libraryOne.jar
WEB-INF/lib/redEjbs.jar
WEB-INF/lib/blueEjbs.jar
The above is not invalid from a spec perspective and is impossible for the server to detect, but still can lead to apps not loading correctly. If libraryTwo.jar needs classes in libraryOne.jar then this app will never work as the Tomcat "lib" classloader cannot see classes from the "webapp" classloader, so classes from libraryTwo.jar will never successfully load. Unfortunately, the vm will almost never say the actual class that was missing and instead will report the first class in the chain of events that lead to needing a class that was missing. This is almost always a bean or servlet class.
Thanks David.
I tried all of the above, but still no luck.
The Collapsed EAR approach wouldn't work for me I guess, as I far as I know Tomcat 6.0.18 doesn't comply to the J2EE 6 specs. Maybe I'm wrong , but I tried and it didn't work anyway. So back to the standard EAR approach.
My EAR is organized exactly as described in your very first example. One Ejb jar, two library jars in /lib, and that's it. Tomcat still can't instanciate my EJB because the EJB class relates to an unreachable class from Library Jar Two.
I simplified my application.xml file so that it only declares one single EJB:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE ...>
<application>
<display-name>ProxyaEAR</display-name>
<module id="EjbModule">
<ejb>ProxyaEJB.jar</ejb>
</module>
</application>
Any other thoughts??
I did ear deployment in weblogic 10.It conatins war, ejb jar, APP-INF, META-INF. Now When I am calling the service from war, I am getting classnot found exception.When I deploy the war file , without using ear file this service works absoulutely fine.
How to resolve this problem. How classloader will check for jars
It's impossible to solve your problem without more details but as you asked for documentation on how classloaders work in WebLogic, you will find information in Understanding WebLogic Server Application Classloading. Also have a look at Understanding J2EE Application Server Class Loading Architectures on TheServerSide.com (quite old but still perfectly valid).
In your particular case, I'd like to know if you are using Manifest Class-Path entries. More details on how your EAR is structure exactly would be also welcome. Please update your question accordingly.