I'm getting the following error when I start up a Java server process (WildFly application server):
Caused by: java.net.UnknownHostException: proxy01.phx2.fedoraproject.org: Name or service not known
at java.net.Inet4AddressImpl.lookupAllHostAddr(Native Method)
at java.net.InetAddress$2.lookupAllHostAddr(InetAddress.java:929)
at java.net.InetAddress.getAddressesFromNameService(InetAddress.java:1324)
at java.net.InetAddress.getLocalHost(InetAddress.java:1501)
The server is not harmed by this error, but it bothers me to have this error in the logs. It is something related with my environment. Indeed, the problem happens no matter which version of the server and on any location of my file system.
I have checked in /etc/hosts and /etc/resolv.conf but I really don't have idea where the "proxy01.phx2.fedoraproject.org" comes from.
Any idea?
Thanks
I am getting the below error while trying to extract the MQHeaders using MQHeaderIterator from MQMessage object . I am using the below line of code and getting the below Exception. Added below jar in classpath also but still it showing error.
Libraries used:
com.ibm.mq.jar
com.ibm.mq.headers.jar
com.ibm.mq.commonservices.jar
com.ibm.mq.jmqi.jar
com.ibm.mq.pcf.jar
Code:
//Giving error in this line
MQHeaderIterator it = new MQHeaderIterator(theMessage);
Its throwing Exception as below.
Exception in thread "main" java.lang.NoClassDefFoundError: com/ibm/mq/internal/MQCommonServices
at com.ibm.mq.headers.MQHeaderIterator.<init>(MQHeaderIterator.java:112)
at com.test.mq.util.MQClass.main(MQClass.java:69)
Caused by: java.lang.ClassNotFoundException: com.ibm.mq.internal.MQCommonServices
at java.net.URLClassLoader$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
... 2 more
Please suggest the possible reason for this error mostly ClassNot Found error occurs when some jar file is missing. Am i missing something here?
Short answer, point the classpath to the java/lib directory of the original IBM MQ install location which contains ALL required jar files.
More detail:
IBM does not support copying jar files to different locations until v8 in which case they have added support for relocation but have combined everything needed into two jar files com.ibm.mq.allclient.jar and com.ibm.mq.traceControl.jar which can be relocated from a full MQ Server or MQ Client install to another location in your enterprise.
For more details see the section "Starting with MQ 8.0, you can use Relocatable JAR Files" on IBMs Technote "Starting with MQ 8.0, you can use Relocatable JAR Files".
WebSphere MQ 8.0.0 > IBM MQ > Developing applications > Developing
object-oriented applications with IBM MQ > Using IBM MQ classes for
Java > Installation and configuration of IBM MQ classes for Java >
What is installed for IBM MQ classes for Java
Relocatable JAR files
Within an enterprise, the following files can be moved to systems
that need to run IBM MQ classes for Java applications:
com.ibm.mq.allclient.jar
com.ibm.mq.traceControl.jar
The file com.ibm.mq.allclient.jar contains the IBM MQ classes for
JMS, the IBM MQ classes for Java, and the PCF and Headers Classes. If
you move this file to a new location, make sure that you take steps to
keep this new location maintained with new IBM MQ Fix Packs. Also,
make sure that the use of this file is made known to IBM Support if
you are getting an interim fix.
To determine the version of the file com.ibm.mq.allclient.jar, use
the command: java -jar com.ibm.mq.allclient.jar
Note that all MQ versions 7.1 and earlier are end of service from IBM. IBM MQ v7.5 has an end of service date of April 30th 2018.
I would recommend you move to v8.0 or v9.0 which have not had end of service dates announced yet. Newer MQ client versions can connect to older MQ queue managers. You can download a java only install of MQ 8.0 or MQ 9.0 jar files at the links below:
IBM MQ v8.0 Client
IBM MQ v9.0 Client
I have webservices deployed on WAS that use Clearquest jars to connect to Clearquest. At runtime, I get the following errors.
java.lang.Exception: Cannot parse the output since it has an error. Error = ReasonCode = conflictCRVAP0049E (internal-error): Cannot instantiate protocol provider: cqjnilinuxproxy (Not found in java.library.path)
...java.lang.reflect.InvocationTargetException:
at com.ibm.rational.stp.cs.internal.util.StpExceptionImpl.realException(StpExceptionImpl.java:493)
at com.ibm.rational.stp.cs.internal.util.StpExceptionImpl.<init>(StpExceptionImpl.java:572)
Caused by: java.lang.reflect.InvocationTargetException
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:56)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:39)
at java.lang.reflect.Constructor.newInstance(Constructor.java:527)
at com.ibm.rational.stp.client.internal.core.ProtocolSubprovider.setProtocolProvider(ProtocolSubprovider.java:614)
... 57 more
Caused by: java.lang.UnsatisfiedLinkError: cqjnilinuxproxy (Not found in java.library.path)
at java.lang.ClassLoader.loadLibraryWithPath(ClassLoader.java:1090)
at java.lang.ClassLoader.loadLibraryWithClassLoader(ClassLoader.java:1054)
at java.lang.System.loadLibrary(System.java:510)
at com.rational.clearquest.cqjni.CQJNIBaseObj.<clinit>(Unknown Source)
at java.lang.J9VMInternals.initializeImpl(Native Method)
at java.lang.J9VMInternals.initialize(J9VMInternals.java:235)
at java.lang.J9VMInternals.initialize(J9VMInternals.java:202)
at com.ibm.rational.stp.client.internal.cqjni.CqJniProtocol.<init>(CqJniProtocol.java:2343)
... 62 more
I followed the technote https://www-304.ibm.com/support/docview.wss?uid=swg21515079 - "An exception occurs on 64-bit WebSphere servers when running reports from ClearQuest data sources that require the Java Native Interface (JNI).
As suggested, WAS 32-bit was installed instead on 64 bit. But the error still occurs. Can you please let me know where this library is or what is going wrong?
Thanks,
Aarthi
The ClearQuest libraries and jars need to be placed on the path so WebSphere can pick them up. Did you source cq_setup.csh prior to starting the WebSphere profile? You would need to source cq_setup.csh and then start the profile in the same shell.
I am trying to deploy an application that was developed in MyEclipse using Tomcat (originally 5.5 but works with 7) to our demo server (Sun Java Web Server 7). Unfortunately all of the people that had designed the application have left the company. So, here is what I know:
1) The application works as-is in MyEclipse on Tomcat
2) The application was successfully deployed to Sun Java Web Server in the past (presumably with the same build)
3) I can connect to the database from the server with sqldeveloper
4) The application uses: Java EE 5 and Spring framework
Application settings:
driver: oracle.jdbc.driver.OracleDriver
url jdbc:oracle:thin#xx.xx.x.xx:service
Here is the only error I am getting. I get a lot of warnings before and after though:
warning: CORE3283: stderr: com.mchange.v2.async.ThreadPoolAsynchronousRunner$PoolThread.run(ThreadPoolAsynchronousRunner.java:547)
failure:
for host xx.xx.x.xxx trying to GET /application/login.jsp, service-j2ee reports: com.mchange.v2.resourcepool.CannotAcquireResourceException: A ResourcePool could not acquire a resource from its primary factory or source. at
com.mchange.v2.resourcepool.BasicResourcePool.awaitAvailable(BasicResourcePool.java:1319) at
com.mchange.v2.resourcepool.BasicResourcePool.prelimCheckoutResource(BasicResourcePool.java:557) at
com.mchange.v2.resourcepool.BasicResourcePool.checkoutResource(BasicResourcePool.java:477) at
com.mchange.v2.c3p0.impl.C3P0PooledConnectionPool.checkoutPooledConnection(C3P0PooledConnectionPool.java:525) at
com.mchange.v2.c3p0.impl.AbstractPoolBackedDataSource.getConnection(AbstractPoolBackedDataSource.java:128) at
org.springframework.jdbc.datasource.DataSourceUtils.doGetConnection(DataSourceUtils.java:113) at
org.springframework.jdbc.datasource.DataSourceUtils.getConnection(DataSourceUtils.java:79) at
org.springframework.jdbc.core.JdbcTemplate.execute(JdbcTemplate.java:379) at
org.springframework.jdbc.core.JdbcTemplate.query(JdbcTemplate.java:455) at
org.springframework.jdbc.core.JdbcTemplate.query(JdbcTemplate.java:463) at
org.springframework.jdbc.core.simple.SimpleJdbcTemplate.query(SimpleJdbcTemplate.java:187) at
gov.nyc.oer.dao.SiteConfigDao.getSiteConfig(Unknown Source) at
gov.nyc.oer.manager.SiteConfigManager.getSiteConfig(Unknown Source) at
gov.nyc.oer.manager.SiteConfigManager.afterPropertiesSet(Unknown Source) at
gov.nyc.oer.manager.SiteConfigManager.getValue(Unknown Source) at
org.apache.jsp.login_jsp._jspService(login_jsp.java:67) at
org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:80) at
javax.servlet.http.HttpServlet.service(HttpServlet.java:917) at
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:373) at
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:457) at
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:351) at
javax.servlet.http.HttpServlet.service(HttpServlet.java:917) at
org.apache.catalina.core.ApplicationFilterChain.servletService(ApplicationFilterChain.java:398) at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:304) at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:185) at
org.springframework.security.util.FilterChainProxy.doFilter(FilterChainProxy.java:169) at
org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate(DelegatingFilterProxy.java:183) at
org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilterProxy.java:138) at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:217) at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:185) at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:275) at
org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:255) at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:188) at
org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:586) at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:556) at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:187) at
org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:586) at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:556) at
com.sun.webserver.connector.nsapi.NSAPIProcessor.service(NSAPIProcessor.java:160)
Server Configuration:
Java: Enabled
Java Home: ${WS_JDK_HOME}
Ignore Environment Class Path: Enabled
Class Path Prefix: None
Server Class Path:
${WS_INSTALL_ROOT}/lib/webserv-rt.jar
${WS_INSTALL_ROOT}/lib/pwc.jar
${WS_INSTALL_ROOT}/lib/ant.jar
${java.home}/lib/tools.jar
${WS_INSTALL_ROOT}/lib/ktsearch.jar
${WS_INSTALL_ROOT}/lib/webserv-jstl.jar
${WS_INSTALL_ROOT}/lib/jsf-impl.jar
${WS_INSTALL_ROOT}/lib/jsf-api.jar
${WS_INSTALL_ROOT}/lib/webserv-jwsdp.jar
${WS_INSTALL_ROOT}/lib/container-auth.jar
${WS_INSTALL_ROOT}/lib/mail.jar
${WS_INSTALL_ROOT}/lib/activation.jar
Class Path Suffix: ${WS_INSTALL_ROOT}/lib/ojdbc14.jar
JVM Options:
-Djava.security.auth.login.config=login.conf
-Xms128m -Xmx256m
-Djdbc.drivers=oracle.jdbc.driver.OracleDriver
Looks like your database connection is not defined on your sun java web server 7. On this website you can find out how to define it.
I've got a Java web application (using Spring), deployed with Jetty. If I try to run it on a Windows machine everything works as expected, but if I try to run the same code on my Linux machine, it fails like this:
[normal startup output]
11:16:39.657 INFO [main] org.mortbay.jetty.servlet.ServletHandler$Context.log>(ServletHandler.java:1145) >16> Set web app root system property: 'webapp.root' = [/path/to/working/dir]
java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.mortbay.start.Main.invokeMain(Main.java:151)
at org.mortbay.start.Main.start(Main.java:476)
at org.mortbay.start.Main.main(Main.java:94)
Caused by: java.lang.ExceptionInInitializerError
at org.springframework.web.util.Log4jWebConfigurer.initLogging(Log4jWebConfigurer.java:129)
at org.springframework.web.util.Log4jConfigListener.contextInitialized(Log4jConfigListener.java:51)
at org.mortbay.jetty.servlet.WebApplicationContext.doStart(WebApplicationContext.java:495)
at org.mortbay.util.Container.start(Container.java:72)
at org.mortbay.http.HttpServer.doStart(HttpServer.java:708)
at org.mortbay.util.Container.start(Container.java:72)
at org.mortbay.jetty.Server.main(Server.java:460)
... 7 more
Caused by: org.apache.commons.logging.LogConfigurationException: org.apache.commons.logging.LogConfigurationException: No suitable Log constructor [Ljava.lang.Class;#15311bd for org.apache.commons.logging.impl.Log4JLogger (Caused by java.lang.NoClassDefFoundError: org/apache/log4j/Category) (Caused by org.apache.commons.logging.LogConfigurationException: No suitable Log constructor [Ljava.lang.Class;#15311bd for org.apache.commons.logging.impl.Log4JLogger (Caused by java.lang.NoClassDefFoundError: org/apache/log4j/Category))
at org.apache.commons.logging.impl.LogFactoryImpl.newInstance(LogFactoryImpl.java:543)
at org.apache.commons.logging.impl.LogFactoryImpl.getInstance(LogFactoryImpl.java:235)
at org.apache.commons.logging.impl.LogFactoryImpl.getInstance(LogFactoryImpl.java:209)
at org.apache.commons.logging.LogFactory.getLog(LogFactory.java:351)
at org.springframework.util.SystemPropertyUtils.(SystemPropertyUtils.java:42)
... 14 more
Caused by: org.apache.commons.logging.LogConfigurationException: No suitable Log constructor [Ljava.lang.Class;#15311bd for org.apache.commons.logging.impl.Log4JLogger (Caused by java.lang.NoClassDefFoundError: org/apache/log4j/Category)
at org.apache.commons.logging.impl.LogFactoryImpl.getLogConstructor(LogFactoryImpl.java:413)
at org.apache.commons.logging.impl.LogFactoryImpl.newInstance(LogFactoryImpl.java:529)
... 18 more
Caused by: java.lang.NoClassDefFoundError: org/apache/log4j/Category
at java.lang.Class.getDeclaredConstructors0(Native Method)
at java.lang.Class.privateGetDeclaredConstructors(Class.java:2389)
at java.lang.Class.getConstructor0(Class.java:2699)
at java.lang.Class.getConstructor(Class.java:1657)
at org.apache.commons.logging.impl.LogFactoryImpl.getLogConstructor(LogFactoryImpl.java:410)
... 19 more
Caused by: java.lang.ClassNotFoundException: org.apache.log4j.Category
at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
at java.lang.ClassLoader.loadClass(ClassLoader.java:252)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320)
... 24 more
[shutdown output]
I've run the app with java -verbose:class, and according to that output, org.apache.log4j.Category is loaded from the log4j JAR in my /WEB-INF/lib, just before the first exception is thrown.
Now, the Java versions on the two machines are slightly different. Both the machines have Sun's java, the Linux machine has 1.6.0_10, while the Windows machine has 1.6.0_08, or maybe 07 or 06, I can't remember the exact number right now, and don't have the machine at hand. But even though the minor versions of the Javas are slightly different, the code shouldn't break like this. Does anyone understand what's wrong here?
You must understand that a classloader can't see everything; they can only see what a parent classloader has loaded or what they have loaded themselves. So if you have two classloaders, say one for Jetty and another for your webapp, your webapp can see log4j (since the JAR is the WEB-INF/lib) but Jetty's classloader can't.
If you manage to make a class available to Jetty (for example something in the DB layer) which uses log4j but which ends up running in the context (and classloader) of Jetty, you will get an error.
To debug this, set a breakpoint in org.springframework.web.util.Log4jWebConfigurer.initLogging(). If you can, copy the source of this class into your project (don't forget to delete it afterwards) and add this line:
ClassLoader cl = Thread.currentThread().getContextClassLoader();
Have a look at the cl object in your debugger. That should give you some information who created it. My guess is that this is the classloader from Jetty.
[EDIT] Note that you get in a different mess if you have log4j in both classloaders: In this case, you will have two classes with the same name which create objects which are not assignment compatible! So make sure there is only a single instance of this jar or that instances of log4j will never be passed between the two contexts (which is usually not possible).
This seems like a classic classloader problem. It could be due to another web app being loaded first which also uses log4j but a version that is different to the one used by the app you are testing. The classloader uses the first version of the class it finds. The server class loading policy can usually be changed in the config files. Sorry I am a bit rusty on this but maybe it can point you in the correct direction.
Make sure there are no other installed apps on the web server,
Make sure the log4j being loaded is the correct version,
Make sure you don't have a log4j lurking somewhere in the classpath of the server.
HTH
You're using the same WAR on both machines? Have you checked if the WAR files are identical (no transfer errors occured)?
Some random things to consider:
(1) Check if there are any other versions of log4j floating around on the linux instance, outside of the web-app directories?
(2) Is apache commons logging being used at all? You might want to consider SLF4J instead?
(3) Did the JAR/WAR become corrupt in some way - was it FTP'ed in ASCII or Binary?
(4) Print out the classloader hierarchy in each case, just to see if there are any discrepancies?
Even though the original problem was solved for the asker, I'll point out that a common source of problems when running the same code on Windows vs Linux (or Unix) is case-sensitivity issues. Windows ignores case while Linux or Unix is case-sensitive. This has bitten me more than once.
So if you specify a jar or directory on the classpath, but it isn't the right case then it will fail on Linux but succeed on Windows. This can also be the source of FileNotFoundExceptions.
Had the same problem and found an easy solution/workaround:
In Eclipse in Preferences > Java > Installed JREs, select the JRE > Edit and Add External JARs... and browse to your log4j.jar.
The other workaround is to add log4j.jar to every launch definition in Classpath tab.