How to resolve "Interface is not visible from class loader" in Java - java

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?

Related

JMSCS0002 from Spring JMS and IBM Websphere MQ

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.

Adding Common class for different blackberry application

I have written a common class which I want to use in separate Blackberry applications. This class is not in a separate project but just at a common location and I have linked the path of the common class in Java Build Path. I have added same common path to both of my BB applications and they builds and installs without any problem. When I run one application, it start running but when I run the other application, it gives error message "class xxx multiply defined" error and exits.
Any idea what is going wrong here. Thanks in advance
Regards,
Braj
BlackBerry doesn't work as other Java platforms. In BB Java, you can't have two classes with the same full qualified name, even if they live in different projects.
You'll have to rename one of them (either change the class name or the package name) for it to work.
In fact, the only platform where I have seen this restriction is BB. It is a real pain in the ass since you can't reuse a jar library in different projects without renaming it.
UPDATE:
This is the official article on the topic:
http://supportforums.blackberry.com/t5/Java-Development/Application-throws-quot-multiply-defined-quot-error-at-start-up/ta-p/501498
All applications in RIM OS run under one instance of Java Virtual Machine. And therefore it is allowed only one class with particular full qualified name. Adding another class with the same name will lead to failure upon running both of these classes.
There is a library thing, supported in RIM OS, but I do not recommend to use libraries in your project, unless it is very necessary.
It is because if you have several apps with the same library, but with different versions of libraries you may get the same error you reported in your question. And it is hard to manage libraries when you have many applications which use these libraries.
I recommend to copy source code of your library to the project you are working on. Copy via refactoring, to change all full qualified names of classes included in that library.
Thanks guys for replying. I have created a common library and put common code in that. Now I can use this library in different applications without any problem.
However, when I install my applications using BB desktop Manager, the library appears as part of first application but not in second application. I assume it is because, second application realizes that the library is already been included so doesn't need to include it again.

Java project with executable jars; running and retrieving data from them

At work, I use a Java application (I have located compiled/executable jars on the C-drive). I want to be able to grab some information from this application through code. The application itself probably does not store information, so it must communicate with legacy systems some way, I am not sure how, I have seen traces of a Servlet(?) Hence, I suspect the application also has built-in "encryption"(?)
I do not want to get involved in encryption and login procedures etc., so I am thinking I could just build a Java project around the current executable jars, and launch the application as I usually do (through the "main" entry point, "Start.jar", but then after execution call the functions that I want to (i.e. the application just runs as usual in the background)...
Would that be possible? Is there another way? Can one, for example, hook up to an already executed Java application and issue commands?
What I have tried so far
Downloaded Eclipse, and created a new project
Made Eclipse "reference" external jars (there was a wizard in Eclipse)
Created a new class in my new project, in which I launch the "main" entry point of the "main" executable jar (the structure of all the jars pops up with "IntelliSense"). I have also found out which argument I need to supply to the main procedure using JD-GUI (Java Decompiler)...
It seems that from inside the main procedure a call is made to another procedure, which resides in a different jar, in the debug window of Eclipse I just see an error, which made me doubt that my current approach is viable... Maybe the problem arises because the command is issued from a compiled jar? Could there be an issue with the "class path"? Does this at all seem like a solution? But then again, I have no experience with Java (mostly VBA and some C#).
You can start your JVM for the application with options, which enable remote debugging. Then you can connect the eclipse debugger to this JVM.
http://www.eclipsezone.com/eclipse/forums/t53459.html
Based on your question, I am going to guess that your application does not have a Java API you can code against. That would, of course, be the easiest way. So, if you have not checked, do that first.
Assuming you don't have an API to code against, I think your approach is correct. But it could be hard to do, since you are basically flying blind trying to figure out what the application is doing. Remote debugging might solve part of that problem.
There might be a slightly easier solution, if you are sure it is sending requests across the network. You can use a tool like Wireshark to see what it is creating. Then, you can have your application create requests that look like that and send them to that destination. This assumes of course that the requests aren't encrypted. In that case you are probably out of luck.

How can i debug code that invoked with java reflection?

I hava an application which deployed on J2EE application server , inside the application there is implementation of class loader loading jar files into the JVM, inside those jar files there are Test Cases which implements common interface, by java reflection i dynamically invoke (by name) those test cases, the problem is that is like a black box and if test case fails i need to work hard to find what went worng throw the application server logger , is there any way to debug the test cases code? or any suggestion at all? thank you sorry for the long story..
You should be able to use Java's remote debugging facility. I've done something similar before and I would simply set a breakpoint in the test that failed. This page describes how to set up remote debugging in eclipse. How you enable debugging depends on the app server you're using.
You can connect to a remote Java EE app server with IntelliJ and step through the code line by line.

Can i deny access to a jvm class by configuring java.policy file?

I wanted to add to my jdk6\jre\lib\security\java.policy file an interdiction to create some classes that are blacklisted by appengine. For example I want my local jvm to throw an exception when the application tries to instantiate javax.naming.NamingException.
It is possible?
I will try to explain my specific problem here. Google offers an service (GAE-google app engine) that has some limitations on what classes can be used. For example doesn't instantiate JNDI classes that are in javax.naming package. They also offer an testing server that can be used to tests this application on my machine, but this server allows such classes and can exacute the code. You find out that you used a blacklisted class only after you upload your application to google. I was thinking if such class blacklist enforcement couldn't be done on the development jvm. Else i'm thinking that this would be easy they might already provide such a policy file.
You could write a small loader application that creates a new, custom classloader. Your application classes could then be loaded using this classloader.
In the custom classloader, you can then throw ClassNotFoundException when your application tries to access a class that you want to blacklist.
You will need to overload the load() method. This method will be responsible for throwing the exception on your blacklisted classes ordelegating to the parent Classloader if the class is allowed. A sample implementation:
public Class loadClass(String name) throws ClassNotFoundException {
if(name.equals("javax.lang.ClassIDontLike")){
throw new ClassNotFoundException("I'm sorry, Dave. I'm afraid I can't do that.");
}
return super.loadClass(name, false);
}
(Of course, a real implementation can be way more sophisticated than this)
Because the classes of your application are loaded through this Classloader, and you are only delegating the loadClass() invokations to the parent classloader when you want to, you can blacklist any classes that you need.
I am pretty sure that this is the method that Google uses to blacklist classes in their server. They load every app in a specific Classloader. This is also similar to the way that Tomcat isolates the different Web Applications.
Wouldn't you rather get compilation errors than runtime errors while testing your program? You could configure your IDE or compiler to warn you when an undesired class is instantiated. I know AspectJ has some nice features for this: You can define compilation warnings/errors on join points and get feedback in e.g. Eclipse. To use this in Eclipse, you simply install the AspectJ plugin and write a suitable aspect. To get the errors while compiling from a command line or script, you would actually have to use the AspectJ compiler, but I doubt that you would need that.
The Java documentation lists all possible policy permissions here:
http://java.sun.com/javase/6/docs/technotes/guides/security/permissions.html
Class creation / loading is not mentioned, so I believe you cannot enforce this using a policy.
At any rate, why do you want to throw an exception when an exception class is loaded? Maybe you could explain your problem, then someone might be able to propose a solution.
Edit:
One way to prevent loading of certain classes would be to remove them from the JRE installation. Most system classes are contained in rt.jar in your JDK/JRE installation. You should be able to modify it with any ZIP-tool.
Just create a special installation of your JRE, and modify its rt.jar. That is an ugly hack, but should be OK for testing purposes...

Categories