I'm getting an exception being thrown when I try and list my Axis-powered web services, when I try and access the WSDL for any service and when I try and use the service in question:
Servlet.service() for servlet AxisServlet threw exception
java.lang.NoClassDefFoundError: com.example.MyAwesomeServiceSoapBindingImpl
Now, I know that class is available in a jar in the Axis web service's WEB-INF/lib directory, and I have reloaded Axis since I put it there.
Any ideas, anyone?
[tomcat 5.5.x, Apache Axis version: 1.4 Built on Apr 22, 2006 (06:55:48 PDT)]
The object that MyAwesomeServiceSoapBindingImpl wraps isn't instantiating property.
I'm guessing that underlying problem is masked by this (apparently totally unrelated at first glance) type of problem because of the way Axis initialises its services...
Once I fixed the underlying problem everything kicked back into life.
Related
I've got issue with Microsoft Dynamics NAV instance.
We're restarting Windows server each night (I know that we probably shouldn't do it, but this is a separated topic and not the point of this question).
After windows server starts, SQL and Dynamics Nav instances are starting. Sometimes (1-2 times per month) Dynamics NAV instance is marked as 'Running', but actually doesn't respond (Web services are not working, RTC client cannot connect to this instance etc.). We have to restart Dynamics Nav instance manually once again in order to get it working correctly.
Did anyone have similar problems? We were looking into Windows Logs, but couldn't find anything interesting..
We also wonder if we shouldn't manage start of the services (SQL server, Dynamics Nav instances etc.) manually somehow instead of depending on the automatic start of everything after windows restart.
Update:
There is actually one error in the Windows Event Log which occures ONLY in days when Dynamics Nav instance is not started corretly:
Server instance: XXXX
Tenant ID:
User:
Type: System.AggregateException
Message: A Task's exception(s) were not observed either by Waiting on
the Task or accessing its Exception property. As a result, the
unobserved exception was rethrown by the finalizer thread.
HResult: -2146233088
Type: System.BadImageFormatException
Message: An attempt was made to load a program with an incorrect
format. (Exception from HRESULT: 0x8007000B)
StackTrace:
at Microsoft.Dynamics.Nav.Runtime.NavLicense.NativeMethods.UnpackLicense(Byte[]
license, Int32 licenseSize, StringBuilder header, Int32 headerSize)
at Microsoft.Dynamics.Nav.Runtime.NavLicense.Create(Byte[] license, LicenseExpiredHandler licenseExpiredHandler)
at Microsoft.Dynamics.Nav.Runtime.NavDatabaseSecurityAndLicense.get_License()
at Microsoft.Dynamics.Nav.Runtime.WindowsLanguageDataProvider.IsAvailableLanguage(Int32
languageId)
at Microsoft.Dynamics.Nav.Runtime.NavEnvironment.FindSupportedLanguage(Int32
languageId, Int32 defaultLanguageId)
at Microsoft.Dynamics.Nav.Runtime.NavSession.Open(Boolean useUserPersonalization, Byte[] licenseToUse, Boolean
allowAppsDisabledMode)
at Microsoft.Dynamics.Nav.Runtime.NavTaskSchedulerHelpers.RunAsSystemSession(NavTenant
tenant, Action`1 action)
at Microsoft.Dynamics.Nav.Runtime.NavTaskScheduler.TaskRunInfo.InternalRun()
at Microsoft.Dynamics.Nav.Runtime.NavTaskFactory.<>c__DisplayClass1_0.<RunTask>b__0()
at System.Threading.Tasks.Task.InnerInvoke()
at System.Threading.Tasks.Task.Execute()
Source: Microsoft.Dynamics.Nav.Ncl
HResult: -2147024885
I'd suggest Delayed Start to help alleviate missing dependencies such as certificates OCSP validation without internet, etc. There should be Windows Logs saying the The service has completed configuration and is ready.
Service Auto-restart actions might help catch unexpected errors, but as it's Running I'm not sure it'll exactly apply to your situation.
The service tier should not be restarted nightly, as you've pointed out :). It might be easier to solve that issue, but I can't suggest anything without more information.
Also, which version of Dynamics NAV/Business Central?
When trying to integrate RTC plain jars into a customized WebSphere server application, exception occurred at below code line.
this.teamRepository = TeamPlatform.getTeamRepositoryService().getTeamRepository(this.repositoryURI);
Exception:
[12/2/15 16:04:19:883 SGT] 000000a4 BusinessExcep E CNTR0020E: EJB
threw an unexpected (non-declared) exception during invocation of
method "createTestAutoDefect" on bean
"BeanId(RTCWebClientEAR#RTCWebClient.war#RTCWorkItemHandler, null)".
Exception data: java.lang.NoClassDefFoundError:
com.ibm.team.repository.client.internal.ContributorManager
(initialization failure) at
java.lang.J9VMInternals.initialize(J9VMInternals.java:177) at
com.ibm.team.repository.client.internal.TeamRepository.<init>(TeamRepository.java:427)
at
com.ibm.team.repository.client.internal.TeamRepositoryService.createSharedTeamRepository(TeamRepositoryService.java:526)
at
com.ibm.team.repository.client.internal.TeamRepositoryService.getTeamRepository(TeamRepositoryService.java:113)
at
com.ibm.team.repository.client.internal.TeamRepositoryService.getTeamRepository(TeamRepositoryService.java:132)
...
Caused by: java.lang.IllegalArgumentException: The type name
Contributor and the namespace URI com.ibm.team.repository do not
resolve to an IItemType. at
com.ibm.team.repository.common.internal.querypath.AbstractQueryPathModel$Implementation.getItemType(AbstractQueryPathModel.java:192)
at
com.ibm.team.repository.common.query.IQuery$Factory.newInstance(IQuery.java:93)
at
com.ibm.team.repository.client.internal.ContributorManager.createAllContributorsQuery(ContributorManager.java:72)
at
com.ibm.team.repository.client.internal.ContributorManager.<clinit>(ContributorManager.java:60)
at java.lang.J9VMInternals.initializeImpl(Native Method) at
java.lang.J9VMInternals.initialize(J9VMInternals.java:237) at
com.ibm.team.repository.client.internal.TeamRepository.<init>(TeamRepository.java:427)
at
com.ibm.team.repository.client.internal.TeamRepositoryService.createSharedTeamRepository(TeamRepositoryService.java:526)
at
com.ibm.team.repository.client.internal.TeamRepositoryService.getTeamRepository(TeamRepositoryService.java:113)
at
com.ibm.team.repository.client.internal.TeamRepositoryService.getTeamRepository(TeamRepositoryService.java:132)
It seems classes in the RTC plain jars are not properly loaded.
Those jars were put into the library folder of the EAR that hosts the web project that implements RTC functions.
Resolved the issue by tweaking WebSphere's class loading behavior as below:
In the RAD (eclipase core) IDE, right Click on the EAR that contains the web project for RTC client
-> Java EE
-> Open WebSphere Application Server Deployment, go to Application section and make Classloader mode: PARENT_LAST and WAR classloader policy: APPLICATION
Found this solution via: https://jazz.net/forum/questions/75680/cant-connect-to-jazz-server-in-was-70?page=1&focusedAnswerId=75682#75682
The cause could most likely be because of missing plugin configurations in eclipse classes, resulting from class loading behavior.
WebSphere is implemented through OSGI technology like eclipse, hence the eclipse platform classes by default are loaded from WebSphere, not the RTC client libraries (plain RTC jar files) included in the EAR application.
Hence a possible solution would be to reverse the class loading policy.
Looking at this thread and this one, it seems to be:
an issue when using a non-executable jar file
or, as in here, a symptom of not having all required jar files on the classpath
I need to migrate a web service application from Tomcat 6 (using JDK 1.5) to Tomcat 7 (using JDK 1.6) (actually testing on 7.0.27). The JAX-WS framework is Metro 2.1.
I'm using two ServletContextListeners:
"WebAppListener" : to initialize the application (configuration, setup of database connections...).
"com.sun.xml.ws.transport.http.servlet.WSServletContextListener": the Metro listener that creates the web services.
The order is important, because I need my web app fully initialized before the #PostConstruct method is called on my web service.
In Tomcat 6, this works marvelously:
INFO: Starting Servlet Engine: Apache Tomcat/6.0.36
mars 16, 2013 5:13:13 PM org.apache.catalina.startup.HostConfig deployWAR
INFO: Deploying web application archive WSWebApp.war
************************ IN WebAppListener.contextInitialized ***********************
************************ IN WSMyWebService.postConstruct ****************************
Exactly the same war however in Tomcat 7:
mars 16, 2013 6:45:24 PM org.apache.catalina.startup.HostConfig deployWAR
INFO: Deploying web application archive C:\home\tomcat\webapps\WSWebApp.war
************************ IN WSMyWebService.postConstruct ****************************
************************ IN WebAppListener.contextInitialized ***********************
I thought that the order in which the listener's are called is the order in which they appear in the web.xml?
Why this order has been changed in Tomcat 7? But more importantly: What do I need to do to get the "Tomcat6" order back?
Thanks.
The answer lies in a difference between Servlet spec 2.5 and Servlet spec 3.0.
In Servlet spec 2.5, the order in which listeners are called is defined by the order of their declaration in the deployment descriptor (web.xml):
SRV.10.3.3 Listener Registration.
The Web container creates an
instance of each listener class and registers it for event
notifications prior to the processing of the first request by the
application. The Web container registers the listener instances
according to the interfaces they implement and the order in which
they appear in the deployment descriptor. During Web application
execution, listeners are invoked in the order of their registration.
In Servlet spec 3.0, the order in which listeners are called is defined by the element <absolute-ordering> in the deployment descriptor (web.xml):
8.2.3 Assembling the descriptor from web.xml, webfragment.xml and annotations. ... c. Prior to this release of the specification,
context listeners were invoked in random order.
This is wrong IMHO, as stated above in the version 2.5 spec. :-)
As of Servlet 3.0,
the listeners are invoked in the order in which they are declared in
the web.xml as specified below: i. Implementations of
javax.servlet.ServletContextListener are invoked at their
contextInitialized method in the order in which they have been
declared, and at their contextDestroyed method in reverse order.
This doesn't work at all like you'd expect and is the source of my trouble, confusion and a lost weekend. ;-)
It's NOT the same ordering as before (2.5 spec)!
But there is more... (the AHA moment is near!)
8.2.2 Ordering of web.xml and web-fragment.xml
Since the specification allows the application configuration resources
to be composed of multiple configuration files (web.xml and
web-fragment.xml), discovered and loaded from several different
places in the application, the question of ordering must be
addressed.
...
Two cases must be considered to allow application configuration
resources to express their ordering preferences.
1. Absolute ordering: an <absolute-ordering> element in the web.xml. a. In this case, ordering preferences that would have been handled by
case 2 below must be ignored.
2. Relative ordering: an <ordering> element within the web-fragment.xml. a. A web-fragment.xml may have an <ordering>
element. If so, this element must contain zero or one <before>
element and zero or one <after> element. The meaning of these elements
is explained below.
So, in my case, I had two options:
Stick with version 2.5 : This works well on Tomcat 6 and 7, but is only moving problems to the future.
Migrate to version 3.0 of the spec and adjust my deployment descriptor accordingly:
Update the version and schema in the web-app element, of course:
<web-app xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"
version="3.0">
Adding a <absolute-ordering> element that defines the order in which the listeners should be processed:
<absolute-ordering> <name>bootstrap</name><name>ws</name><others/></absolute-ordering>
<listener id="bootstrap">
<listener-class>lu.estiedi.ws.WebAppBootstrap</listener-class>
</listener>
<listener id="ws">
<listener-class>com.sun.xml.ws.transport.http.servlet.WSServletContextListener</listener-class>
</listener>
Note the <others/> element : if it's not present, then the listeners that are not named will not be processed.
EDIT:
This doesn't actually solve the problem.
It went away yesterday at home, but this morning at work the solution didn't work. :-(
It looks like Metro is using a service provider ServletContainerInitializer, which are called before the Listeners.
If this is the way it's supposed to work, then the PosConstruct method is always called before the contextInitialized on Listeners.
Where do we initialise our application then, before the web services are created?
It is not about order of Listeners, it is about a new feature of servlets spec 3.0 and the fact that you are probably using a JAX-WS implementatios like METRO, I suppose.
In servlets spec 3.0 (chapter 8.2.4) there is a way to add 3rd party plugins or APIs to containers (Tomcat in this case), for example JAX-WS, JAX-RS, JSF, etc. implementations. It is also known ad SCI (javax.servlet.ServletContainerInitializer).
In short, METRO JAX-WS jars use this way so it is not mandatory to add listener (com.sun.xml.ws.transport.http.servlet.WSServletContextListener) and servlet configuration in your web.xml descriptor file. It uses sun-jaxws.xml file to list ws endpoints and instantiate ws classes before deployment of web application and execution, for example, of methods contextInitialized of listeners.
To avoid this, just follow instructions for avoiding SCI mechanism in Tomcat: How do I make Tomcat startup faster?
There exists an attribute on Context element, containerSciFilter. It can be used to disable container-provided features that are plugged into Tomcat via SCI API: WebSocket support (in Tomcat 7 and later), JSP support (in Tomcat 8 and later).
The class names to filter can be detected by looking into META-INF/services/javax.servlet.ServletContainerInitializer files in Tomcat JARs. For WebSocket support the name is org.apache.tomcat.websocket.server.WsSci, for JSP support the name is org.apache.jasper.servlet.JasperInitializer.
It worked for me with JAX-WS and it just uses web.xml config to deploy web services.
Running Netbeans 6.5.1 with OpenESB (Glassfish-full-installer-windows2.1).
I'm using this tutorial (http://www.youtube.com/watch?v=a76RxkzB4Bg) as reference to orchestrate web services by calling a local WSDL that invokes an external WSDL (http://www.webservicex.net/CreditCard.asmx?WSDL). I have my BPEL ready
and my Composite Application created, it automatically binds a SOAP call from my local WSDL to the BPEL (Consumer to Producer), I had to drag and drop another SOAP object and configure it with the same interface as my local WSDL to receive the output from the invoke action (is that correct?).
When I run my test case selecting the operation from my local WSDL, I get the following SoapResponse:
<SOAP-ENV:Fault>
<faultcode xmlns="">SOAP-ENV:Server</faultcode>
<faultstring xmlns="">BPCOR-6135: A fault was not handled in the process scope; Fault Name is {http://www.sun.com/wsbpel/2.0/process/executable/SUNExtension/ErrorHandling}systemFault; Fault Data is &a....Sending errors for the pending requests in the process scope before terminating the process instance</faultstring>
<faultactor xmlns="">sun-bpel-engine</faultactor>
<detail xmlns="">
<detailText>BPCOR-6135: A fault was not handled in the process scope; Fault Name is {http://www.sun.com/wsbpel/2.0/process/executable/SUNExtension/ErrorHandling}systemFault; Fault Data is &a... Sending errors for the pending requests in the process scope before terminating the process instance
Caused by: BPCOR-6131: An Error status was received while doing an invoke (partnerLink=externalBPELImplementation, portType={http://www.webservicex.net}CCCheckerSoap, operation=ValidateCardNumber)
BPCOR-6129: Line Number is 37
BPCOR-6130: Activity Name is Invoke1
Caused by: HTTP Status-Code 404: Not Found - Not Found</detailText>
</detail>
I've created a separated project to test the external WSDL and it is validating credit card numbers as expected, there's something wrong with my BPEL or my Composite Application.
If I create another test case and select the local port that is created when I drag and drop the Soap object into the Comp. App. Design interface, I get a different error:
Dec 24, 2012 12:54:11 AM com.sun.xml.messaging.saaj.client.p2p.HttpSOAPConnection call
SEVERE: SAAJ0006: Bad URL (endPoint instance of String)
java.net.MalformedURLException: no protocol:
any ideas?
Your process seams to be correct (at the first look).
It looks like your process can't find the service you ask:
BPCOR-6130: Activity Name is Invoke1 - Caused by: HTTP Status-Code 404: Not Found - Not Found
Is your "soap adress" in the wsdl you imported correct ?
Have you try to overload the url in the bpel mapping ? (Properties -> SOAP HTTP BC -> Outbound -> UR)
There is also something strnage in your CASA: If you are trying to consume "localCreditCard_WSDLPort" and expose in OpenESB "casaPort1", the SOAP Binding are inversed. The arrow should start from casaPort1 and finish at localCreditCard_WSDLPort.
I hope this could help you,
Simon
According to #brasseld from www.open-esb.net
In fact, you've made two mistake :
The first one, for your unit test, you have to use the good WSDL which come from the BPEL because you've created a concrete SOAP WSDL
(CreditCard_WSDL.wsdl).
Then, when you create a new port in your composite application for your plnk externalServiceCard_WSDL, you have to set the soap address
location by right-click > properties. By default, this one is set to
localhost:${HttpDefaultPort}/compositeapp/casaportX?wsdl that's why
you encounter your errors (404 or bad url error).
Based on his suggestions, I've decided to document the development process step-by-step, here's the result:
http://www.youtube.com/watch?v=-1W1xR3-iJQ
Hope someone can help me. My problem is that I can’t seem to call any web services from Oracle (Oracle Database 10g Enterprise Edition Release 10.1.0.5.0.)
The web service I was originally working on can be invoked from a browser interface, but when invoked from Oracle I get the following error message:
Fel pσ rad 1:
ORA-29532: Java-anrop avslutades av ouppfσngat Java-undantag:
java.rmi.RemoteException: java.rmi.RemoteException: ; nested exception is:
dynamic invocation error: javax.xml.soap.SOAPException: Error parsing envelope
ORA-06512: vid “SYS.UTL_DBWS”, rad 404
ORA-06512: vid “SYS.UTL_DBWS”, rad 401
ORA-06512: vid “PRODPACK.HELLOWORLD”, rad 163
The first couple of lines are in Swedish, and are telling me politely that my code has caused an uncaught java exception.
I have tried to google this but have not been able to find anything that can help me.
I tried to call an example web service that I found in this article:
http://www.oracle-base.com/articles/10g/utl_dbws10g.php
But I get the same error.
Does anyone know what may be causing this?
I had a similar problem with utl_dbws and it turned out that we had a 'partial' install of java on our 10g instance. Our dba had to finish the installation and then everything worked.
However, even after that I switched to using UTL_HTTP (and another link)and found it easier (esp. since there seems to be more documentation around it and I had to go through a proxy)