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.
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 am Getting this error when trying to run spring batch to load the list of executions.
java.lang.IllegalAccessError: tried to access method
org.springframework.batch.core.repository.dao.JdbcJobExecutionDao.getJobParameters(Ljava/lang/Long;)Lorg/springframework/batch/core/JobParameters;
from class
org.springframework.batch.admin.service.JdbcSearchableJobExecutionDao
After doing some analysis, I found that JdbcJobExecutionDao is part of Spring-batch and has the implementation of getJobParameters() as protected method while, JdbcSearchableJobExecutionDao is part of spring-batch-admin which has extended the JdbcJobExecutionDao.
So as per the Oracle documentation, it says that IllegalAccessError is -
Thrown if an application attempts to access or modify a field or to
call a method that it does not have access to.
Normally, this error is caught by the compiler; this error can only
occur at run time if the definition of a class has incompatibly
changed.
I don't understand, I don't have control over these jars/classes. Am I doing something wrong while using them? or is there a problem with the versions I am using for both jars.
spring-batch - version 2.2.0.RELEASE
spring-batch-admin - version 1.3.0.BUILD-SNAPSHOT(Tried with 1.3.0.RELEASE also)
Refered to sites -
java.lang.IllegalAccessError: tried to access method
https://github.com/spring-projects/spring-batch/blob/master/spring-batch-core/src/main/java/org/springframework/batch/core/repository/dao/JdbcJobExecutionDao.java
https://github.com/spring-projects/spring-batch-admin/blob/master/spring-batch-admin-manager/src/main/java/org/springframework/batch/admin/service/JdbcSearchableJobExecutionDao.java
So, I fixed this by using proper versions. It was a version mismatch problem between spring-batch & spring-batch-admin. I referred to this spring docs site and tried the recommended versions and it worked!
http://docs.spring.io/spring-batch-admin/spring-batch-admin-manager/dependencies.html
So, now I am using
2.2.7.RELEASE(Spring-Batch)
with
1.3.1.RELEASE(Spring-Batch-Admin)
and I am not getting the java.lang.IllegalAccessError anymore. Need to check if any other functionalities have been disturbed because this is a very old project.
Hope this helps someone facing similar problem.
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 am new to Android development. I'm working on an project which involves using stubs for web services. When I try to use it, I get the following error:
I've been stuck here for a week, so some help would be highly appreciated.
It seems that there is some packaging or deployment issues with the included libraries that you use in you project. This error is thrown when the Java Virtual Machine or a ClassLoader instace try to load the definition of the a class but cannot find it anywhere. In most cases, this occurs when something is messed up in your project configurations but i cannot tell what from the information provided. A solution would be to configure your project from the scratch since most of the times this is easier than finding what causes the problem. Also in case you had an older version of ADT (<17) the answer of this SO question might be usefull. Finally, if you are importing any javax libararies(or libraries that have javax components in them), this maybe the source of your problem since Adroid does not support the javax library.