I'm working on a spring boot project and until recently it was fine but now i can't run unit tests. It gives the error:
'int org.jvnet.winp.Native.setPriority(int, int)'
I've searched but found nothing, what might couse the error?
(btw it runs the project itself just not the unit tests)
Edit: i just realized it works if i open the app by idea.bat file but not when i open with the exe file.
I opened a ticked at jetbrains, and turns out it was cousing by a third party security tool.
Related
I've cloned the sample project which JetBrains uses for demonstration purposes (https://github.com/JetBrains/intellij-samples.git) from GitHub since I had an issue with JUnit and wanted to see whether those issues persist when using an official project (to make sure that I haven't messed something up). Unfortunately the issue persists and after hours of research on Google, StackOverflow or last but not least the JetBrains Support Board I can't manage to get this issue resolved.
I can't get JUnit to work with the sample project as well as my own projects. Whenever I add JUnit to my classpath (using Maven), it imports all the required libraries. After that, literally everything works perfectly fine except for the #Test annotation. I can use other annotations like org.junit.jupiter.api.Disabled (#Disabled) or org.junit.jupiter.api.ParameterizedTest (#ParameterizedTest) but whenever I try to use the org.junit.jupiter.api.Test (#Test) annotation I get a "Cannot resolve symbol 'Test'" error.
When hovering above the #Test annotation it suggests to add JUnit4 or JUnit5 to the classpath. If I select that option I still get the same error and when hovering above the #Test annotation afterwards it still suggests the same thing. I've already tried to do "Maven > Reload Project", "File > Invalidate Caches / Restart", reinstalling IntelliJ Ultimate and importing the JUnit API manually by adding it as an external Java library to the project without using Maven or Gradle. I also made sure that the directory in which I am trying to use the #Test annotation in is a "Test Source Folder". However, once again, all the other JUnit annotations work perfectly fine. Only #Test is not working and throws a "Cannot resolve symbol 'Test'" error.
I am using the following versions:
IntelliJ: 2020.3.2 (Ultimate Edition) [latest]
Java: 1.8 "1.8.0_144"
JUnit: 5.7.1 (But I've also tried to use plenty of other versions [from 4.0 to 5.8] instead without success.)
OS: Windows 10 Home 64 bit
I've tried setting up JUnit with Eclipse using Maven and it immediately worked so I am not sure whether this has something to do with IntelliJ specifically. At this point I start to run out of ideas as to why everything except the #Test annotation is working perfectly fine. I've already tried plenty of suggestions from aforementioned sites, hence I really hope that we can get this issue resolved here.
I've appended a screenshot of one of the classes where this issue occurs. All of the code as well as the pom.xml file / etc is the same as in https://github.com/JetBrains/intellij-samples. I haven't modified any of the files locally and only tried "Maven > Reload Project" as well as "File > Invalidate Caches / Restart" with the sample project. If you need any further info in order to have a look at this issue make sure to let me know.
Thanks in advance.
Max
Attachments:
Screenshot of test/com.jetbrains.code.JavaAt25Test
Please see if deleting the system directory helps while the IDE is not running. It looks like file system cache related issue. Should be fixed in 2021.1 release.
The issue is not reproducible in 2020.3.2 with the clean system directory:
As of today, I can no longer create projects with unit tests in Xcode. Normally it looks like this:
As of today it looks like this:
How to I get back the option to create unit tests? I can kind of manually create unit tests, but they don't work with CMD-U, can't find objects unless they're explicitly imported, and cause either linker errors or EXC_BAD_INSTRUCTION when run.
Figured it out. You can create a project with unit tests for any kind of project type EXCEPT "Command Line Tool".
So if you want to have unit tests with your command line tool, best to create it as a framework project with unit tests, then add source files to both the framework (for the unit tests) and to your command line tool. Awkward and clunky, but it works.
I have observed an inconsistent way properties are being read in Eclipse. I have a very simple Springboot web project with typical property files. Here is my project layout:
Notice the two property files: testapplication.properties and application.properties. They are identical at this point, the intention is to use them for test and non test environments.
When I try to run this application in Eclipse, I am getting an error about missing expected property values, for example:
Could not resolve placeholder 'min.thread.count' in value "${min.thread.count}"
When I run the same setup using gradle's bootRun task, it works fine.
When I run the same setup in InteliJ it works fine.
If I rename the testapplication.properties to application.properties the application runs fine in Eclipse. As such it is using property form test folder.
In addition, I am pretty sure when I started Eclipse this morning I was able to run the application with a proper application.properties and testapplication.properties files. I was working on a unit test and renamed the testapplication.properties to application.properties, did some work, then renamed it back to testapplication.properties the application refused to start. I have attempted to replicate it: shut down eclipse with two different property files (application and testapplication), start it again and run application. However, at this moment I have the same issue (complaining about missing property value).
As you can see this i weird behaviour. As it stands I find that I cannot use Eclipse as I am not sure what it will do. I've switch to community edition of InteliJ as it seems to be working correctly. But as a long time fan of Eclipse I am heartbroken :)
Does anyone have any clue what could be causing this?
EDIT:
I have checkin in my test project here:
https://github.com/twolak2003/CamelSpringBootEureka.git in branch PropertyFileIssue. Simply clone, switch to PropertyFileIssue branch, import to eclipse as gradle project.
It is a simple vanilla spring cloud boot project running a eureka server and eureka client. For the purpose of this issue we'll just concentrate on eureka-service.
I am using latest Eclipse Oxygen. I did notice the same issue in Eclise Neon. I switched to Oxygen hoping the issue will go away. Only plugin is the Spring IDE. Using Java 8 to run this.
Test 1: Start the EurekaService/src/main/hello.java as Java application.
It starts fine and will read the src/main/resources/application.property file.
Test 2: Rename the EurekaService/src/main/test/resources/restapplication.properties to EurekaService/src/main/test/resources/application.properties. Start the EurekaService application again.
Findings: It starts fine as well BUT it uses property file in the /src/test/resources. This to me is issue as well, it should not be using /test/ for running the application.
Test 3: Now rename the /src/test/resources/application.properties to /src/test/resources/testapplication.properties again. (this is repeat of test1). Once again run EurekaService/src/main/hello as java application.
Finding Despite this being a repeat of test1 the test failed due to "Could not resolve placeholder 'tomek.prop' in value "${tomek.prop}"".
Am I doing something really stupid or is there an issue?
For now with heavy heart I am switching to InteliJ to keep my project going. The behaviour of Eclipse is just too unpredictable for me to stomach for now :(
So far I don't have a correct answer for this other than stop using Eclipse :). But there is workaround.
DO NOT use more than one application.property file.
If you need test properties to override actual properties then name your file as anything else but "application.property". Otherwise you'll get unpredictable behaviour and your Eclipse runtime get's confused.
Running Eclipse Indigo, Tomcat 7 on Windows - running the web application on the ROOT context with eclipse wtp plugin I am getting this intermittent problem where eclipse cannot find the compiled JSP. It occurs when first accessing the JSP and cannot be resolved except by stopping the Tomcat server and cleaning the Work directory and the project directory. The compile version is there in the eclipse directory structure:
.metadata\.plugins\org.eclipse.wst.server.core\tmp0\work\Catalina\localhost\_\org\apache\jsp\WEB_002dINF\...
but it still produces this error.
After some research I found this related thread which seems to suggest the problem only occurs when the application is deployed on ROOT.
http://comments.gmane.org/gmane.comp.jakarta.tomcat.user/208071
And a bug has been entered:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=334977
Has anyone had a similar issue to this and knows a solution?
Hi please try to configure value as per first screen shot and change location as per second screenshot and try if that works for you.
I am using NHibernate against an Oracle database with the NHibernate.Driver.OracleDataClientDriver driver class. I have an integration test that pulls back expected data properly when executed through the IDE using TestDriven.net. However, when I run the unit test through the NUnit GUI or Console, NHibernate throws an exception saying it cannot find the Oracle.DataAccess assembly. Obviously, this prevents me from running my integration tests as part of my CI process.
NHibernate.HibernateException : The
IDbCommand and IDbConnection
implementation in the assembly
Oracle.DataAccess could not be found.
Ensure that the assembly
Oracle.DataAccess is located in the
application directory or in the Global
Assembly Cache. If the assembly is in
the GAC, use
element in the application
configuration file to specify the full
name of the assembly.*
I have tried making the assembly available in two ways, by copying it into the bin\debug folder and by adding the element in the config file. Again, both methods work when executing through TestDriven in the IDE. Neither work when executing through NUnit GUI/Console.
The NUnit Gui log displays the following message.
21:42:26,377 ERROR [TestRunnerThread]
ReflectHelper [(null)]- Could not load
type
Oracle.DataAccess.Client.OracleConnection,
Oracle.DataAccess.
System.BadImageFormatException: Could
not load file or assembly
'Oracle.DataAccess,
Version=2.111.7.20, Culture=neutral,
PublicKeyToken=89b483f429c47342' or
one of its dependencies. An attempt
was made to load a program with an
incorrect format.
File name: 'Oracle.DataAccess,
Version=2.111.7.20, Culture=neutral,
PublicKeyToken=89b483f429c47342' --->
System.BadImageFormatException: Could
not load file or assembly
'Oracle.DataAccess' or one of its
dependencies. An attempt was made to
load a program with an incorrect
format.
File name: 'Oracle.DataAccess'
I am running NUnit 2.4.8, TestDriven.net 2.24 and VS2008sp1 on Windows 7 64bit. Oracle Data Provider v2.111.7.20, NHibernate v2.1.0.4.
Has anyone run into this issue, better yet, fixed it?
Sly, Thanks for the reply. However, the NUnit test runner was using the correct configuration file as I was testing by pulling a known value out of the expected configuration file.
I am assuming this has something to do with my configuration, specifically with either Windows 7 in general or the 64bit version. I went ahead and installed/configured the Oracle client on the build server (W2k3 Server). I moved the test onto the build server and ran the same scenarios described above and the tests worked as expected in all cases.
I followed this up by running through the scenarios on two of the other developer workstations (Win XP 32bit with same toolset versions) and the tests worked as expected in all cases.
I'm perplexed but satisfied for now. I can run my integration tests through the IDE and can execute them on the build server through our CI automation. Only problem now is I can't test the automation build project on my development workstation.
I was getting this error when I tried to run an application which used Oracle.DataAccess.dll (odp.net version 2.111.7.20). I was shipping the oracle 11g instant client alongside the application. On 64 bit servers it would fail. However, the client assemblies I was shipping were 32 bit so I compiled a version of the app with the CPU flag set 32-bit and now it works fine. This is because the server runs the entire component within the wow64 emulator when you tell it the app is 32bit explicitly.
I had a similar problem when configuring NHibernate. The thing is that most of test runners are using app.config that is placed with your tests dll. But some versions of NUnit don't. Thats why your system stays in not configured state for the tests. You can try to configure NHibernate mannually from the test. Hope it helps
I may have just solved a similar/same problem on my local machine by going into the build settings for the test project and changing platform target from "any cpu" to "x86"