I'm having this exception when I try to consume a WebService from my application. I've been googling this error but all I see is about OutOfMemoryErrror.
I have Wildfly 8.1.0.Final and jaxws-api version 2.2.9 as dependency in my pom.xml. I'm using axis 1.4 for another legacy module of my application too. I've read in another stackoverflow post that I can't use both (Axis and CXF) in the same project (or .war finally) but I can't find any other reference about this fact.
I tried disabling webservices extensions in my standalone.xml with no success at all. Also adding jbossws-cxf-client 5.0.0.Final in my pom.xml with the same result.
Tomorrow I'll try to generate an Axis 1.4 client and see if this solves my problem.
Thanks in advance for any comment.
21:06:54,634 ERROR [....controller.BaseController] (default task-17) Manejando una excepción no tratada: javax.xml.ws.soap.SOAPFaultException: unable to create new native thread
at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:157)
at com.sun.proxy.$Proxy100.evaluateTransaction(Unknown Source)
at ...services.RiskServicesImpl.consultarRiesgoTx(RiskServicesImpl.java:191) [classes:]
Finally we realized that this SOAPFaultException was not thrown from my Wildfly but from the server we wanted to connect to, wich ran out of memory. Using another tool to query de web service was enough to see this.
Tim Biegeleisen: thanks for reading this desperate post :)
Related
I've developed a Jersey API which returns either XML or JSON (depending on the request header). When deployed on my Windows 2012 server (Tomcat), it works no problem.
When I deploy (after compiling it on Ubuntu) to an Ubuntu machine in AWS (Glassfish), I get the following errors when I request JSON:
The server encountered an internal error that prevented it from fulfilling this request.
exception javax.servlet.ServletException: org.glassfish.jersey.server.ContainerException: java.lang.NoClassDefFoundError: Could not initialize class org.eclipse.persistence.jaxb.BeanValidationHelper
root cause org.glassfish.jersey.server.ContainerException: java.lang.NoClassDefFoundError: Could not initialize class org.eclipse.persistence.jaxb.BeanValidationHelper
root cause java.lang.NoClassDefFoundError: Could not initialize class org.eclipse.persistence.jaxb.BeanValidationHelper
No errors when I request XML.
I was originally using moxy for JSON serialization, but then started using Jackson.
Any ideas why it would work on one server and not another?
Thanks
Finally got this working. First, use Tomcat, not Glassfish.
Then, add a new dependency:
<dependency>
<groupId>org.glassfish.jersey.inject</groupId>
<artifactId>jersey-hk2</artifactId>
</dependency>
I also upgraded Jersey version to 2.26, but I don't think that made the difference. Just adding that for completeness (as it did happen).
I don't understand the reason it works. I always thought Java ran the same on Windows and Linux. But hey, I'm just a dumb .NET guy.
Hope this helps others who find themselves in a pit of helplessness on this issue as I did.
I am using Eclipse Luna (versions 4.4.2) and Glassfish 4 to build a REST web-app using JAX-RS.
All POST and PUT operations, which were previously working fine, are now throwing this error on the webserver:
Warning: StandardWrapperValve[Jersey Web Application]: Servlet.service() for servlet Jersey Web Application threw exception
java.lang.ClassNotFoundException: javax.xml.parsers.ParserConfigurationException not found by org.eclipse.persistence.moxy
I have found out (in the comments here: https://java.net/jira/browse/JERSEY-2888) that it has been fixed in EclipseLink 2.6.1 and Jersey 2.19.
I have updated to Jersey 2.22.1.
Eclipselink 2.6.1 has been released on Oct 15th 2015, as you can see here: http://www.eclipse.org/eclipselink/releases/
However, as you can see here, it doesn't seem to have been incorporated into eclipse for "help -> update software": http://download.eclipse.org/rt/eclipselink/updates/
Does anybody know how to get 2.6.1 working with Eclipse? At the moment, it is preventing me from completing my application, and this problem I've had for 4 weeks.
Or is there another way to fix it?
All help much appreciated...
File a bug report at https://bugs.eclipse.org/bugs/enter_bug.cgi?product=EclipseLink indicating that it's neither in the main repository nor downloadable as a P2 repository on its own.
So I have a simple ejb (#stateless) deployed on a glassfish 3.1 server.
I want to call it from a standalone application.
It's working great if I add the gf-client.jar into my run configuration.
But how can I do if I do not have that file (the server is in another machine) ?
I tried using
<dependency>
<groupId>org.glassfish.common</groupId>
<artifactId>glassfish-naming</artifactId>
<version>LATEST</version>
</dependency>
But I have
Exception in thread "main" javax.naming.NameNotFoundException: java:global
at com.sun.enterprise.naming.impl.TransientContext.resolveContext(TransientContext.java:252)
at com.sun.enterprise.naming.impl.TransientContext.lookup(TransientContext.java:171)
at com.sun.enterprise.naming.impl.SerialContextProviderImpl.lookup(SerialContextProviderImpl.java:58)
at com.sun.enterprise.naming.impl.LocalSerialContextProviderImpl.lookup(LocalSerialContextProviderImpl.java:95)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:233)
at javax.naming.InitialContext.lookup(Unknown Source)
at be.java.tuto.Application.main(Application.java:17)
Thanks.
EDIT:
I just needed to invoke an EJB deployed on GF from my Tomcat server and resurrected my dependencies. And because I dont want to keep them back for myself :)...
My IDE is Eclipse so I created an User Library containing all the files shown above.
Hope this solves your problem!
I was facing the same problem. For just wanting to invoke a GF session-Bean method I had to add the complete gf-client.jar to my clients classpath.
My problem was that this library is referencing almost the whole GF-libray-folder and even after a clean-up there were >15 referenced jars left which I had to add to my clients classpath.
For me I did't want this overhead so I decided to call the remote method via JAX-WS webservice.
The advantage of using webservises is that it is very easy to add webservice capability to an already existing session-bean by annotating the bean-class with #WebService.
After publishing the bean to the appserver you're able to view your deployed endpoint and getting the WSDL. With this you can generate your webservice-stubs automatically by using the wsimport-tool shipped with your JDK and use this generated files in yor client to invoke the remote method.
See example here.
Once created those files are portable and can be used in any client.
So if your willing to change the way your client calls the remote method this would be a portable, lightweight (except of a bit more http overhead) and easy to implement alternative.
P.S.
You don't lose the ability of invoking your method via EJB-call.
Hope this helped, have Fun!
I'm trying to deploy an application and I've got a webservice that is unavailable. By contacting the team responsible for the webservice, they're asking me if I'm using Axis or SpringWS to access their webservice (apparently in my case there's no other option). Can this be determined from the following (partial) stack trace ?
Here's the Tomcat log I got:
INFO main # jaxws.PlatosJaxWsPortProxyFactoryBean - Retrieve of the wsdl informations.
Retrieving document at 'http://www.xxxxxxxxxxxxxxxx?wsdl'.
ERROR main # utilities.WSDLAnalyzer - javax.wsdl.WSDLException: WSDLException: faultCode=OTHER_ERROR: Unable to resolve imported document at 'http://www.xxxxxxxxxxxx?wsdl'.: java.io.IOException: Server returned HTTP response code: 503 for URL: http://www.xxxxxxxxxx?wsdl
Neither, judging by the info you posted you are using GlassFish Metro.
You're using some implementation of the JAX-WS API, but the error doesn't indicate which one.
Most likely it's the JAX-WS implementation that ships internally to Java6, but it could also be something like Apache CXF or Metro. What's on your application's classpath?
Are these two the only options?
Google says it might be something called Petals Service Engine.
You should contact the ISMS-ALSA department of your company. And, by the way, you're not supposed to use Axis, nor Glassfish Metro!
p.s.: the best answer should rather be assigned to skaffman.
I'm running jboss-4.2.1.GA to generate WS requests.
I have created the WS client with the help of JWSDP-2.0/JAXRPC. I have deployed the client to Jboss and I am now trying to send requests.
When I try to initialise the client service: javax.xml.rpc.Service service = servicefactory.createService(new URL(wsdlURL), serviceQN), Jboss starts to complain.
The error that Jboss generates is:
ERROR [JBossXSErrorHandler]
JBossWS_targetnamespace1.com7796329154971783225.xsd[domain:http://www.w3.org/TR/xml-schema-1]::[key=src-resolve.4.2]::Message=src-resolve.4.2:
Error resolving component
'tns2:SimpleSerialiser'. It was
detected that 'tns2:SimpleSerialiser'
is in namespace
'http://targetnamespace2.com', but
components from this namespace are not
referenceable from schema document
'file:/home/jbossPath/jboss-4.2.1.GA/server/default/tmp/jbossws/JBossWS_targetnamespace1.com7796329154971783225.xsd'.
If this is the incorrect namespace,
perhaps the prefix of
'tns2:SimpleSerialiser' needs to be
changed. If this is the correct
namespace, then an appropriate
'import' tag should be added to
'file:/home/jbossPath/mobaq/jboss-4.2.1.GA/server/default/tmp/jbossws/JBossWS_targetnamespace1.com7796329154971783225.xsd'.
Followed by a warning:
WARN [WSDL11Reader] Encoding style
'http://schemas.xmlsoap.org/soap/encoding/'
not supported for:
{urn:namespace}doTask
Finally, the following error is displayed:
ERROR [STDERR]
org.jboss.ws.WSException: Cannot
obtain java type mapping for:
{urn:namespace}ArrayOf_tns2_TagType
ERROR [STDERR] at
org.jboss.ws.metadata.builder.jaxrpc.JAXRPCMetaDataBuilder.buildInputParameter(JAXRPCMetaDataBuilder.java:266)
...
...
I know that a similar error has been posted in community.jboss.org in the past but for a different task. I am not sure if the patch provided will solve my issue and I don't know how to implement the patch provided.
In addition to this, I have found someone having similar issues: JAX-RPC in JBoss 4.2.3 but the suggested solution does not work for me.
I also know that JbossWS does not support RPC/Encoded but I use jboss for my solution.
Is there a way for me to get around this issue, can I not get Jboss to create the client service to send requests? I'm not sure requesting a RPC/Literal WSDL file is a possibility so that's why I am asking.
Any suggestions will be greatly appreciated.
http://schemas.xmlsoap.org/soap/encoding/ is a legacy style used by very old web service stacks (it's so bad, even Microsoft recommend against it). It was seriously flawed, and so was excluded from the WS-I interoperability spec, which most modern Java web service stacks implement.
The only java stack that I know of that handles these old encoding is Axis 1, which is itself seriously flawed, but may be your only option. You should be able to run Axis as a client from inside JBoss.
I finally solved the issue by implementing the solution suggested from JAX-RPC in JBoss 4.2.3 post:
To jump to the chase, I simply put the following JARs from Axis 1.4 in my EAR's lib directory:
axis.jar, axit-ant.jar, commons-discovery-0.2.jar, jaxrpc.jar, saaj.jar, wsdl4j-1.5.1.jar
What I was doing was putting the above jars with my own WS Client jar file and that's why it didn't work. The solution was there, in front of me in black and white and I didn't implement it properly. That's the problem when looking too closely to an issue for too long.
I am a numpty.