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!!
Related
I have been trying to use GBGId3Global Web service (SOAP based) for KYC&AML using Java (Spring). But my app is throwing "Interface com.id3global.IGlobalCredentials is not visible from class loader" exception. IGlobalCredentials is the library interface provided from GBG. I put this lib in my classpath (very messy organization of code, they put over 700 class/interfaces in one package):
src/main/java/
/com/id3global
/my_app_package/sub_packages
I did search and found similar (but very limited) answers which I could not find sufficient answer. Hence, I decided to give it as a general question. In which cases, this exception is thrown and how to resolve it in the context of web applications
EDIT:
Sorry, I forgot to mention one important thing, I am behind corporate proxy. But the requested host is open. And this is the WSDL URL
EDIT-II: I was running the project from eclipse directly, but then tried from the command line:
java -jar project.jar
And it is working without problem, what might be the case for this behavior?
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.
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.
I got this error when trying to update an application to App Store:
2.5
The use of non-public APIs can lead to a poor user experience should
these APIs change in the future, and is therefore not permitted. The
following non-public APIs are included in your application:
Framework:
'/usr/lib/libicucore.A.dylib'
Non-public APIS:
: ubrk_getRuleStatus : ubrk_setUText : ucnv_getCanonicalName :
ucnv_reset : ucol_strcollIter
If you have defined methods in your source code with the same names as
the above-mentioned APIs, we suggest altering your method names so
that they no longer collide with Apple's private APIs to avoid your
application being flagged in future submissions.
Additionally, one or more of the above-mentioned APIs may reside in a
library included with your application. If you do not have access to
the library's source, you may be able to search the compiled binary
using "strings" or "otool" command line tools. The "strings" tool can
output a list of the methods that the library calls and "otool -ov"
will output the Objective-C class structures and their defined
methods. These techniques can help you narrow down where the
problematic code resides.
The problem stems from the fact that the application is built with jdk1.8.0_65. jdk embedded. More exactly the problem comes from libjfxwebkit.dylib library that is importing libicucore.A.dylib library. The problem is solved by deleting libjfxwebkit.dylib. Details here.
I have a scenario where I have code written against version 1 of a library but I want to ship version 2 of the library instead. The code has shipped and is therefore not changeable. I'm concerned that it might try to access classes or members of the library that existed in v1 but have been removed in v2.
I figured it would be possible to write a tool to do a simple check to see if the code will link against the newer version of the library. I appreciate that the code may still be very broken even if the code links. I am thinking about this from the other side - if the code won't link then I can be sure there is a problem.
As far as I can see, I need to run through the bytecode checking for references, method calls and field accesses to library classes then use reflection to check whether the class/member exists.
I have three-fold question:
(1) Does such a tool exist already?
(2) I have a niggling feeling it is much more complicated that I imagine and that I have missed something major - is that the case?
(3) Do you know of a handy library that would allow me to inspect the bytecode such that I can find the method calls, references etc.?
Thanks!
I think that Clirr - a binary compatibility checker - can help here:
Clirr is a tool that checks Java libraries for binary and source compatibility with older releases. Basically you give it two sets of jar files and Clirr dumps out a list of changes in the public api. The Clirr Ant task can be configured to break the build if it detects incompatible api changes. In a continuous integration process Clirr can automatically prevent accidental introduction of binary or source compatibility problems.
Changing the library in your IDE will result in all possible compile-time errors.
You don't need anything else, unless your code uses another library, which in turn uses the updated library.
Be especially wary of Spring configuration files. Class names are configured as text and don't show up as missing until runtime.
If you have access to the source code, you could just compile source against the new library. If it doesn't compile, you have definitely a problem. If it compiles you may still have a problem if the program uses reflection, some kind of IoC stuff like Spring etc.
If you have unit tests, then you may have a better change catch any linking errors.
If you have only have a .class file of the program, then I don't know any tools that would help besides decomplining class file to source and compiling source again against the new library, but that doesn't sound too healthy.
The checks you mentioned are done by the JVM/Java class loader, see e.g. Linking of Classes and Interfaces.
So "attempting to link" can be simply achieved by trying to run the application. Of course you could hoist the checks to run them yourself on your collection of .class/.jar files. I guess a bunch of 3rd party byte code manipulators like BCEL will also do similar checks for you.
I notice that you mention reflection in the tags. If you load classes/invoke methods through reflection, there's no way to analyse this in general.
Good luck!