I have a problem with LeanFT. When i try to start it from intellij idea (LeanFT> Enable LeanFT) i have error:
null
java.lang.NullPointerException
at com.hp.lft.sdk.internal.ServerLauncher.runLauncherProcess(ServerLauncher.java:66)
at com.hp.lft.sdk.internal.ServerLauncher.launch(ServerLauncher.java:44)
at com.hpe.lft.sdkUtilities.serverLaunch.ServerLaunchUtils.launchIfNeeded(ServerLaunchUtils.java:24)
at com.hpe.lft.sdkUtilities.PluginServiceBase.launchServer(PluginServiceBase.java:129)
at com.hpe.lft.sdkUtilities.PluginServiceBase.enableOrDisablePlugin(PluginServiceBase.java:105)
at com.hpe.lft.actions.EnableLeanFTAction$1.run(EnableLeanFTAction.java:20)
at com.intellij.openapi.application.impl.ApplicationImpl$1.run(ApplicationImpl.java:305)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
Even if runtime engine start manually.
What can cause this problem?
I recently came across this same problem and it was to do with the LeanFT runtime unable to load NodeJS. Looking into it further my npm path was missing from the Windows environment variables. After adding the path to my npm installation it worked fine.
You may have a similar problem, but to find out the actual cause, I advise you to check the LeanFT runtime log file, which can be found here:
Configuration file:
<LeanFT installation folder>\bin\LFTRuntime.log.config.xml
Path to the log level:
log4net > root
(Change from "INFO" to "debug")
Log output:
%localappdata%\Hewlett-Packard\LeanFT\Logs\HP.LeanFT.log
More details on LeanFT logs can be found on this HP support page.
This could be multiple reasons...
1) Mostly LeanFT runtime agent issue. If you start LeanFT and disconnect from net, then LeanFT will not work properly as licensee server unavailability even after you connect net. Manually initiating LeanFT runtime also will not work. Either restarting Eclipse/intellij and restarting LeanFT run time will solve. Or restarting laptop/system while connected to net will solve this problem.
2) This problem arises when incompatible versions between LeanFT SDK's are used in script, IE/Chrome add-ons and Lean FT Runtime agent versions. Make sure everything is same version, like 14.0.2... Including minor versions.
Related
I'm running a small java application on TomCat 9.0.56 for class that has to connect to a database. I'm using jdbc (ojdbc8 - 19.3.0.0). It was working fine untill it started displaying the following error:
16-Jan-2022 21:03:42.631 SEVERE [RMI TCP Connection(3)-127.0.0.1] org.apache.catalina.core.StandardContext.listenerStart Error configuring application listener [oracle.ucp.jdbc.UCPServletContextListener] java.lang.NoSuchMethodException: oracle.ucp.jdbc.UCPServletContextListener.<init>()
I'm new to tomcat and I'm not sure how to fix this. I have re-installed everything but it hasn't worked again. Any idea?
IDE - IntelliJ 2021.2.3
JDK - 17.0.1
I am sure you must be using Oracle JDBC and UCP binaries from 21.1 release instead of 19.3 release. You can check and validate the ojdbc and ucp jar version using below command:
java -jar ucp.jar
java -jar ojdbc8.jar
The issue you have described above is a known issue with ucp 21.1 release jars. In order to fix the issue, you can simply switch to ucp/jdbc 21.3 release. Please make sure to upgrade both ucp.jar and ojdbc8.jar to 21.3, not just one. Also, make sure to remove all duplicate jars(if any) from the class-path.
Here is a related thread for the same issue:
Ojdbc8 jars upgrade to 21.1.0.0 throws Nosuchmethod exception UCPservletContextListener init
Weirdly, uninstalling and deleting all tomcat versions previously used and installing a new one and setting up a new configuration made the error stop happening and the app is running nicely again.
I had done this before with no results, but this time it did work.
I recently upgraded my MacOSX system to Catalina and several files were placed automatically into "Relocated items" folder on my Desktop. I recently tried to run the following code which had previously worked:
qualimap bamqc -bam Sample1_sorted.bam -c -outdir QualiMap/Sample1_sorted
and received the following error:
Java HotSpot(TM) 64-Bit Server VM warning: Ignoring option MaxPermSize; support was removed in 8.0
Error: Unable to initialize main class org.bioinfo.ngs.qc.qualimap.main.NgsSmartMain
Caused by: java.lang.NoClassDefFoundError: org/apache/commons/cli/ParseException
I have seen many other posts related to this error but am unsure how to even go about trying some of the suggested solutions. I do not work directly with some of the applications/files mentioned in these forums, such as JAVA, Maven, AppAssembler, and the pom.xml file (I could not even find that file). As a result, I wished to ask about this error from the perspective of a biologist using qualimap.
How can I fix this error (with little knowledge of the above applications/files)? I can certainly work with these applications/files, but I would probably need more detailed/basic/low-level advice on how to access and modify them. Thank you!
It seems what qualimap is a java application someone else wrote. I would raise a ticket with whomever wrote this app.
I have a Java-web application running on Tomcat 9. It works fine on a Windowns machine. But after deploying this app on a Debian Linux server I've encountered java.lang.StackOverflow exceptions on some particular pages. Here is the beginning of the stacktrace log:
27-Dec-2017 08:54:43.746 SEVERE [https-jsse-nio-9443-exec-3]
org.apache.catalina.core.ApplicationDispatcher.invoke Servlet.service() for
servlet [jsp] threw exception
java.lang.StackOverflowError
at java.io.UnixFileSystem.canonicalize0(Native Method)
at java.io.UnixFileSystem.canonicalize(UnixFileSystem.java:172)
at java.io.File.getCanonicalPath(File.java:618)
at org.apache.catalina.webresources.AbstractFileResourceSet.file(AbstractFileResourceSet.java:90)
Please, see full stacktrace here:
https://pastebin.com/0AmFDY8F
As far as I understand, the exception occurs while compiling the JSP page source by Jasper and it's somehow related to the resolving of Linux paths / directories. Could anybody please help me to figure out what the exact problem is? I didn't create any symbolic links, if the problem can be related to this.
According to your stack trace, the problem is caused by not being able to find a specific path as resolved by your Spring framework:
org.springframework.security.web.servletapi.SecurityContextHolderAwareRequestFilter.doFilter(SecurityContextHolderAwareRequestFilter.java:154)
...
Caused by: java.io.IOException: JSPException including path '/struct/context/tutorials.jsp'.
The Spring framework is likely using the canonical paths to resolve the file, and it fails perhaps because there is some quirk in the framework related to the type of Unix system you are deploying to.
Please reference this in the Spring documentation:
https://docs.spring.io/spring-boot/docs/current/reference/html/deployment-install.html#deployment-install-supported-operating-systems
The default script supports most Linux distributions and is tested on CentOS and Ubuntu. Other platforms, such as OS X and FreeBSD, will require the use of a custom embeddedLaunchScript.
Notice that Debian was not listed. Hopefully this puts you on the right path.
If I'm chasing a red herring here, I'm sorry - but you haven't given us much to go on.
Finally I've found what caused the StackOverflow exception. I have a recursive JSP tag call to render nested options for a <select> tag. After removing the recursion, the exception disappeared. Sure, it's just a workaround, so I'm still wondering why it works fine on Windows and doesn't on Linux.
Recently, we were facing some issues related to timesten configuration and as per Oracle's suggestion we gave a system reboot to verify the changes.
Post system reboot we found that one of our internal GUI ( related to the application ) didn't came up automatically. Although we restarted the JBOSS process manually post-reboot , process came UP well but GUI doesn't.
I went through the JBOSS startup.log as well but found to see so many errors there like:
error installing to real name=vfsfile jboss
org.jboss.deployers.spi.DeploymentException: Error deploying: jboss:service=Hypersonic,database=localDB
ERROR [AbstractKernelController] Error installing to Start: name=jboss:database=localDB,service=Hypersonic state=Create mode=Manual requiredState=Installed
log4j error: setFile(null,true) call failed.
java.sql.SQLException: The database is already in use by another process: org.hsqldb.persist.NIOLockFile
........and many more
Literally, i have gone through every possible workaround available on internet with no success. Please pardon my question's framing methodology if it's sounds too be least technical.
I am new to JBOSS so need your help in resolving this issue.
Environment is Solaris 10 and JBOSS version is "jboss-5.1.0.GA"
I've got a problem regarding running tests in gradle. I know that in other machines my gradle config works but in mine unfortunately not. We have got junit test and testNG and both of them, when try to execute, produces stacktrace like this:
Could not write standard input into: Gradle Worker 1.
java.io.IOException: The pipe is being closed
at java.io.FileOutputStream.writeBytes(Native Method)
at java.io.FileOutputStream.write(FileOutputStream.java:318)
at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82)
at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:140)
at org.gradle.process.internal.streams.ExecOutputHandleRunner.run(ExecOutputHandleRunner.java:53)
at org.gradle.internal.concurrent.DefaultExecutorFactory$StoppableExecutorImpl$1.run(DefaultExecutorFactory.java:66)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:722)
Which continuously will produce this error with different number (Gradle Worker 2, Gradle Worker 3, etc). Has anybody ever faced similar problem?
I'm using gradle 1.6.
EDIT: I forgot to tell that I'm using gradle wrapper
EDIT: After changing to version 1.12 I'm receiving error:
Caused by: org.gradle.api.InvalidUserDataException: Could not create task '(custome taks name)': Unknown argument(s) in task definition: [mustRunAfter]
11:20:17.990 [ERROR] [org.gradle.BuildExceptionReporter] at org.gradle.api.internal.project.taskfactory.TaskFactory.validateArgs(TaskFactory.java:147)
11:20:17.991 [ERROR] [org.gradle.BuildExceptionReporter] at org.gradle.api.internal.project.taskfactory.TaskFactory.checkTaskArgsAndCreateDefaultValues(TaskFactory.java:134)
11:20:17.991 [ERROR] [org.gradle.BuildExceptionReporter] at org.gradle.api.internal.project.taskfactory.TaskFactory.createTask(TaskFactory.java:72)
EDIT: Ok I think I have found what cause this problem - it was Antivirus. When I disable it script moves a little bit forward but ended with:
org.gradle.messaging.remote.internal.ConnectException: Could not connect to server [e42b57ea-ced6-4bb6-9369-3186ab4983d6 port:63631, addresses:[/127.0.0.1, /0:0:0:0:0:0:0:1]]. Tried addresses: [/127.0.0.1, /0:0:0:0:0:0:0:1].
at org.gradle.messaging.remote.internal.inet.TcpOutgoingConnector.connect(TcpOutgoingConnector.java:62)
at org.gradle.messaging.remote.internal.hub.MessageHubBackedClient.getConnection(MessageHubBackedClient.java:35)
at org.gradle.process.internal.child.ActionExecutionWorker.execute(ActionExecutionWorker.java:54)
at org.gradle.process.internal.child.ActionExecutionWorker.execute(ActionExecutionWorker.java:35)
at org.gradle.process.internal.child.ImplementationClassLoaderWorker.execute(ImplementationClassLoaderWorker.java:85)
at org.gradle.process.internal.child.ImplementationClassLoaderWorker.execute(ImplementationClassLoaderWorker.java:41)
at org.gradle.process.internal.child.SystemApplicationClassLoaderWorker.call(SystemApplicationClassLoaderWorker.java:43)
at org.gradle.process.internal.child.SystemApplicationClassLoaderWorker.call(SystemApplicationClassLoaderWorker.java:32)
at org.gradle.process.internal.launcher.BootstrapClassLoaderWorker.call(BootstrapClassLoaderWorker.java:46)
at org.gradle.process.internal.launcher.BootstrapClassLoaderWorker.call(BootstrapClassLoaderWorker.java:32)
at jarjar.org.gradle.process.internal.launcher.GradleWorkerMain.run(GradleWorkerMain.java:32)
at jarjar.org.gradle.process.internal.launcher.GradleWorkerMain.main(GradleWorkerMain.java:37)
Caused by: java.net.ConnectException: Connection refused: connect
Searching with google on this error gives me nothing (only some old gradle 1.1 errors info). Anybody faced this kind of problem?
Whew, after whole day struggling with gradle I think I've finally found what cause problems. Guilty of that was antivirus - COMODO. After uninstalling it and installing another one, everything started to working fine. So all Gradle Users - please be careful with COMODO because even disabled, it could cause problems when using Gradle . Be aware :)
I faced the similar issue while running the test classes. I can able to build the project, but I couldn't able to run, so after some research I found one of the solution, which is to remove the some of the workerThread-jar from the .gradle/cache folder. I tried and it worked for me. You can use below commands to solve this.
In terminal I invoked gradle test --info command,
In response, I receive the logs, where I searched the for the
Gradle worker Daemon
key, to fetch the location of my gradle-worker.jar. Typically in windows you can find this under the following location C:\Users\.gradle\caches\\workerMain\gradle-worker.jar.
To fix this, one approach is to remove the the workerMain folder itself, and run the test classes.
You really don't need to disable or remove COMODO Antivirus. Just do the following steps:
Go to COMODO Client Panel
Open the Advanced Tasks option under the Task menu.
See all active tasks and select the Gradle process that is being blocked.
Right click on the task and 'Add to Trusted Files'
I got this same error, except it said Gradle Worker 2. I restarted my command line (powershell) and then tried to build again with gradle and it worked. I had changed my environment variables to point to the Java version the project was expecting and had not thought to restart- not sure if that had anything to do with it.
None of the other answers here were helpful in my case.
What I had to do was disable the coroutine agent.
Open Settings (File - Settings)
Select Kotlin under Build... - Debugger - Data Views
Check the box "Disable coroutine agent"
Alternatively, go to your build.gradle file and upgrade the version used for the coroutines dependencies.