I'm running into a problem with CXF (2.7.18) all of a sudden. I'm running under Tomcat 8.0.28 and JDK 1.8.0_66.
The issue is that recently we started seeing problems where it would not accept service calls with appropriate headers. The rub is that it works on some systems but not others.
The failure presents as follows:
Unmarshalling Error: unexpected element (uri:"http://www.namedomain.com", local:"loginRequest"). Expected elements are <{https://www.namedomain.com}loginRequest>
Please note that the unexpected element is the correctly namespaced element. The "Expected" elements are incorrect - CXF or something else in the pipeline is remapping the namespace URI to 'https'
Any clue what might be causing this and how to correct it?
I was able to determine the problem. This is an oddity that never surfaced in our prior testing.
Here is the general summary. The application in question utilizing this WSDL generates the binding from the definition and places it in package 'com.foo'.
The application is also dependent on another WSDL endpoint but that module was built separately but had a colliding package name 'com.foo'.
In our prior testing, this never surfaced.
At some point, while migrating to Java 8 & Tomcat 8, this problem surfaced intermittently on certain boxes but not others. Something about the VM image we are using influences the load order. That is not to say that we are dependent on load order, but we just never saw the collision.
Both the external library and the application library had a package-info.java that had conflicting namespace definitions for the XmlSchema annotation. The load order "changed" at some point under Java 8 / Tomcat 8 making the collision evident. The first package-info loaded is cached causing the error.
The solution is to alter the application's generation of the WSDL binding code to put it in another package and avoid the collision.
Related
I'm using the Websphere Application Server 8.5.5.6 and 8.5.5.8 and from time to time run into problems when some jar or the other in my application conflicts with one that is already present on the WAS. It's easy to fix of course, simply mark the dependency as "provided" in maven and there you go, but since IBM seemingly choose to write the AS with the most obscure error messages possible it takes ages to find something like that out.
My question which google hasn't been able to answer so far:
Is there a complete list somewhere which libraries in which versions are provided with Websphere?
Assuming you're referring primarily to Open Source packages, the official list is here: https://www.ibm.com/support/knowledgecenter/en/SSAW57_8.5.5/com.ibm.websphere.nd.multiplatform.doc/ae/opensourcesoftwareapis.html
Beyond that, most of the stuff visible to apps should be Java EE/SE APIs, which I assume you were already expecting, and IBM-specific implementations (things in com.ibm.* packages), which are hopefully at low risk of collision.
At least if you are on Windows: take Process Monitor (not Process Explorer), and fire it up filtering on Path contains .jar. Then start WebSphere. At some point it will starting loading jars from various directories. Process Monitor will show you which are those jars, and where they are being loaded from.
This should provide you with first hand information without reading IBM documents.
Besides, probably you are aware of that, but in any case: you should be careful with marking a dependency as "provided", since the version of the library used by your application might differ from the version used by WebSphere.
I've seen a question or two on Stack overflow regarding this error but I'm still unable to solve it, so I thought I would pose my own question.
Here's my issue:
I'm using Spring and Spring's JMSTemplate to do some messaging and queue work. I'm trying to read from a queue. I'm not 100% positive if my logic is correct in my code, but anytime I try to run my app I am greeted with this exception (I've included only the last section):
Caused by: com.ibm.msg.client.commonservices.CSIException: JMSCS0002
at com.ibm.msg.client.commonservices.workqueue.PIWorkQueueManager.enqueueItem(PIWorkQueueManager.java:67)
at com.ibm.msg.client.commonservices.workqueue.WorkQueueManager.enqueue(WorkQueueManager.java:225)
at com.ibm.msg.client.commonservices.workqueue.WorkQueueManager.enqueue(WorkQueueManager.java:194)
at com.ibm.msg.client.wmq.common.internal.WMQThreadPool.enqueue(WMQThreadPool.java:91)
Now I'm fairly certain this has nothing to do with my code because no matter how much I change my logic, if I try calling any of the methods made available by JMSTemplate, I receive this exception. After doing some research (based on the other stack overflow answers) I assume it has something to do with the way my classpath is setup. Here is a link to those questions:
One and Two
In addition to this, here's some info I found on IBM's site:
To compile and run WebSphere MQ classes for JMS applications, use the
CLASSPATH setting for your platform as shown in Table 1.
CLASSPATH=MQ_INSTALLATION_PATH\java\lib\com.ibm.mqjms.jar;
MQ_INSTALLATION_PATH\tools\jms;
I have tried this however and It still seems to be failing me. Here's what I have added in my .bat file for my application that I run:
c:\java\jre6\bin\javaw -cp "C:\ussco\wmsflgint\mqs\mqjms-7.5.0.0.jar; C:\ussco\wmsflgint\mqs\mq-7.5.0.0.jar; C:\ussco\wmsflgint\mqs\headers-1.4.2.jar; C:\ussco\wmsflgint\mqs\jmqi-7.5.0.0.jar;" -Xmx256M .... (there's more on the end but I don't feel it's relevant)
Am I not adding this correctly?
Thanks
I've just ran into the same issue with queue listeners. The solution was to place a file compinfo.properties under the directory src/main/resources/META-INF of the Spring project. The file should set values for two properties:
CompList: comp1
comp1_CompClass: com.ibm.msg.client.commonservices.j2se.J2SEComponent
Or you can change the property (comp1_CompClass) value right in the jar com.ibm.msg.client.commonservices.j2se.jar. It has the same effect though I doubt it's legal due to copyright.
Hope it would be helpful and save a couple of hours for someone.
The problem here is that you have been copying and renaming IBM MQ jar files and, as a result, do not have the full set on the Java class path at runtime. This can lead to all kinds problems and unexpected exceptions, such as the one you are experiencing.
Please note that copying MQ jar files, renaming them and/or bundling them into applications is not permitted by IBM Support and invalidates the MQ terms and conditions. (The rules are subtlety different for bundling into apps for the V8 and V9 redistributable client and allclient; but your not using that here).
If you perform a proper install of the MQ client onto your system (which you should do) and then use the instructions that you have already found in the Knowledge Center to reference the com.ibm.mq.jar file for classes for Java applications or the com.ibm.mqjms.jar for classes for JMS applications on the Java class path, your problem will be resolved.
This is a very nasty bug. Here's what's happening: When I run client to server tests, my tests all work. When I query a linux server with the same source code, it fails.
It only occurs on linux (perhaps macs, I haven't checked). I'm on Windows 7 and can't reproduce this. But, this may be an red herring. Another difference is that I'm running off of an exploded ear and the failing servers are running off of a packaged ear. If this is the culprit, it probably is a classpath issue.
This has to do with the server. If I change my client code to call a linux server, it will fail. To me that rules out the client's responsibility.
I've set a break point on the servers to compare the input and to my surprise the content of the entity looks very different. My working server makes the object look like this:
When I set the breakpoint on the linux server, it looks like this:
Notice how the second one is full of strings with the value of "null" and empty objects. What could be causing this? I'm using Jersey 1.x and Jackson 2.0 and JAXB. But this is a huge project that may have older versions of those jars in the classpath. I'm not even sure where to suspect this error could be coming from.
I've discovered the cause of this was in fact a classpath issue. I was using a different install of glassfish compared to everyone else. Everyone else's glassfish had extra libs under "glassfish/lib":
jackson-asl-0.9.4.jar
jersey-bundle-1.0.3.1.jar
jsr311-api-1.0.jar
Once I removed these 3 libs, my code worked consistently everywhere. I removed all 3 at once, so I'm not sure if they are all necessary to remove. But at least one of these jars was responsible.
1).I generated Web Service Client from WSDL (use Axis2 1.5 carnel, wsdl2java,Tomcat 7.0);
2). Accessing a JAX-WS web service from Android use KSoap2-android library (I tested this lib on service http://www.webservicex.net/ConvertWeight.asmx and it works ok). But work with http://xxx.svc?wsdl I can't connect to the service. When I generated the Web Service Client from Android Progect I get this error : "IWAB0399E Error in generating Java from WSDL: java.io.IOException: Emitter failure. There is an undefined binding (BasicHttpBinding_ICustomerService) in the WSDL document. Hint: make sure is fully qualified."
3). From Web Service Client I make service.jar, which used on Android Progect how lib, but not working.
4). When I used ksoap2 I get this error:
[2012-06-26 17:25:33 - TranscribeMe_2.2] Dx 1 error; aborting [2012-06-26 17:25:33 - TranscribeMe_2.2] Conversion to Dalvik format failed with error 1 [2012-06-26 17:26:32 - TMP] Dx warning: Ignoring InnerClasses attribute for an anonymous inner class (org.ksoap2.transport.KeepAliveHttpsTransportSE$1) that doesn't come with an associated EnclosingMethod attribute. This class was probably produced by a compiler that did not target the modern .class file format. The recommended solution is to recompile the class from source, using an up-to-date compiler and without specifying any "-target" type options. The consequence of ignoring this warning is that reflective operations on this class will incorrectly indicate that it is not an inner class. [2012-06-26 17:26:33 - TMP] Dx trouble processing "javax/xml/ws/Dispatch.class":
Ill-advised or mistaken usage of a core class (java.* or javax.*) when not building a core library.
This is often due to inadvertently including a core library file in your application's project, when using an IDE (such as Eclipse). If you are sure you're not intentionally defining a core class, then this is the most likely explanation of what's going on.
However, you might actually be trying to define a class in a core namespace, the source of which you may have taken, for example, from a non-Android virtual machine project. This will most assuredly not work. At a minimum, it jeopardizes the compatibility of your app with future versions of the platform. It is also often of questionable legality.
If you really intend to build a core library -- which is only appropriate as part of creating a full virtual machine distribution, as opposed to compiling an application -- then use the "--core-library" option to suppress this error message.
If you go ahead and use "--core-library" but are in fact building an application, then be forewarned that your application will still fail to build or run, at some point. Please be prepared for angry customers who find, for example, that your application ceases to function once they upgrade their operating system. You will be to blame for this problem.
If you are legitimately using some code that happens to be in a core package, then the easiest safe alternative you have is to repackage that code. That is, move the classes in question into your own package namespace. This means that they will never be in conflict with core system classes. JarJar is a tool that may help you in this endeavor. If you find that you cannot do this, then that is an indication that the path you are on will ultimately lead to pain, suffering, grief, and lamentation.
[2012-06-26 17:26:33 - TMP] Dx 1 error; aborting [2012-06-26 17:26:33 - TMP] Conversion to Dalvik format failed with error 1
Please, help me...
IF you will search StackOverFlow for Axis and WCF/WSDL issues you will find a lot without any answer or suggestion so there is not a lot you would be able to
About your following error:
There is an undefined binding (BasicHttpBinding_ICustomerService) in the WSDL document.
Hint: make sure is fully qualified."
I can say that the problem probably related with how you ICustomerService bindings are defined. As you have chosen BasicHttpBinding, please make sure all the parameters are correct . If you check your Axis generated WSDL, you will be able to verify it easily.
Also in some cases you might hit namespace issues and which could cause Axis WSDL to genatate service.svc?wsdl=wsdl0 and service.svc?wsdl=wsdl1. If that is the case, you can resolve namespace issues by adding namespace attribute for your each data contract along with message header, body and added bindingnamespace attribute in web service end point.
My first suggestion will be to create a simple C# client application and connect to your Windows Azure WCF service to and verify you could connect using BasicHttpBindings without any problem and then use Java app to do the same. If you see the problem, compare the network traffic between two to see the different which might help you to figure out the root cause and for very specific problem ask questions at SO and you will get proper help. Good Luck!!
Question 1: (Solved)
I'm facing an issue with class loader in Weblogic.
I've a Web application which executes the following code.
AccessController.doPrivileged()
This is handled by another classloader.
When the above code gets executed, Class Not Found exception occurred for a project specific class(for example Sample.class) which exist in web project.
How can I solve this issue?
Solution:
Weblogic 10.3.1.0 is using com.bea.core.apache.commons.net_1.0.0.0_1-4-1.jar... I want to use commons-net-2.0.jar from my code
Question 2:
After getting solution as I mentioned earlier, now its throwing ClassCastException as follows.
java.lang.ClassCastException: org.apache.xerces.jaxp.SAXParserFactoryImpl cannot be cast to javax.xml.parsers.SAXParserFactory
at javax.xml.parsers.SAXParserFactory.newInstance(SAXParserFactory.java:128)
To answer your second question:
the most probable thing is that you already have an implementation of the SAX somewhere (which is located upper in the classpath).
For example JSF requires one implementation of SAX parser (WL admin console webapp uses JSF, so chances are SAX is already imported).
There should be only one implementation, otherwise you could experience strange behavior and strange exceptions. Delete the second implementation from the lib folder of the application.