I'm trying to mock a Teaser class (public interface) using mockito core 3.8 and I'm not able to do it.
I've JAVA 11 and this is the following error:
org.mockito.exceptions.base.MockitoException:
Mockito cannot mock this class: interface com.adobe.cq.wcm.core.components.models.Teaser.
Mockito can only mock non-private & non-final classes.
If you're not sure why you're getting this error, please report to the mailing list.
Java : 11
JVM vendor name : Oracle Corporation
JVM vendor version : 11.0.12+8-LTS-237
JVM name : Java HotSpot(TM) 64-Bit Server VM
JVM version : 11.0.12+8-LTS-237
JVM info : mixed mode
OS name : Windows 10
OS version : 10.0
Underlying exception : java.lang.IllegalStateException: Type not found: com.adobe.cq.wcm.core.components.internal.jackson.ComponentDataModelSerializer
What's happening here?
I finally got a solution for this.
The problem was that I didn't had wcm core components dependency on my project. Since AEMaaCS includes that dependency as a package, we didn't need to include the dependency in our project.
I ended up adding the dependency but just for the scope=test.
I have a VS2017 solution that contains a .NET Core 2.0 console project that references a .NET Standard 2.0 class library, as well as a number of other NuGet packages. The solution builds fine on my development machine.
When I try to run NuGet restore on the TFS build server with NuGet 4.0.0 or 4.1.0, I get the following error:
Package (mypackagename) 1.0.0 is not compatible with netcoreapp2.0 (.NETCoreApp,Version=v2.0). Package (mypackagename) 1.0.0 supports:
- net35 (.NETFramework,Version=v3.5)
- netstandard2.0 (.NETStandard,Version=v2.0)
This error message is similar to that described in Nuget restore fails for ASP.NET Core 2.0 project on build server so I tried the solution suggested there, which is to use NuGet 4.3.0 or later. I've tried all released versions from 4.3.0 to 4.6.2, and this time I get the following error from NuGet restore:
2018-04-17T15:45:15.2611952Z Value cannot be null.
2018-04-17T15:45:15.2611952Z Parameter name: key
2018-04-17T15:45:15.2611952Z System.ArgumentNullException: Value cannot be null.
2018-04-17T15:45:15.2611952Z Parameter name: key
2018-04-17T15:45:15.2611952Z at System.Collections.Concurrent.ConcurrentDictionary`2.GetOrAdd(TKey key, Func`2 valueFactory)
2018-04-17T15:45:15.2611952Z at NuGet.Commands.RestoreCommandProvidersCache.GetOrCreate(String globalPackagesPath, IReadOnlyList`1 fallbackPackagesPaths, IReadOnlyList`1 sources, SourceCacheContext cacheContext, ILogger log)
2018-04-17T15:45:15.2611952Z at NuGet.Commands.DependencyGraphSpecRequestProvider.Create(String projectNameToRestore, ExternalProjectReference project, HashSet`1 projectReferenceClosure, RestoreArgs restoreArgs, DependencyGraphSpec projectDgSpec)
2018-04-17T15:45:15.2611952Z at NuGet.Commands.DependencyGraphSpecRequestProvider.GetRequestsFromItems(RestoreArgs restoreContext, DependencyGraphSpec dgFile)
2018-04-17T15:45:15.2611952Z at NuGet.Commands.DependencyGraphSpecRequestProvider.CreateRequests(RestoreArgs restoreContext)
2018-04-17T15:45:15.2611952Z at NuGet.Commands.RestoreRunner.<CreatePreLoadedRequests>d__11.MoveNext()
2018-04-17T15:45:15.2611952Z --- End of stack trace from previous location where exception was thrown ---
Any suggestions as to how I can get this working?
I fixed this by setting "Clean = True" in the "Get Sources" task of my Team Build.
After doing this, I could use a recent version of NuGet (4.6.2), which no longer throws the ArgumentNullException above.
I suspect a bug in NuGet, where it gets confused by files left around from a previous build.
I'm trying to compile my application source using JDK 8, Groovy 2.4.4, Spock 1.0-groovy-2.4, Gradle 1.11 (my firm hass custom plugins built on top of this)
gradle -version
Groovy: 1.8.6
Ant: Apache Ant(TM) version 1.9.2 compiled on July 8 2013
Ivy: 2.2.0
JVM: 1.7.0_51 (Oracle Corporation 24.51-b03)
OS: Windows 7 6.1 amd64
In my build environment, I need to retain my JAVA_HOME to Java 7 for other projects.
JAVA_HOME = C:\Program Files\Java\jdk1.7.0_51
JAVA8_HOME = C:\Program Files\Java\jdk1.8.0_60
Due to this, in my build.gradle, I explicitly tell Gradle to use JDK 8
tasks.withType(JavaCompile) {
options.fork = true;
options.forkOptions.executable = "${System.env.JAVA8_HOME}/bin/javac"
}
tasks.withType(Test) {
executable = "${System.env.JAVA8_HOME}/bin/java"
}
compileJava{
sourceCompatibility = 1.8
targetCompatibility = 1.8
}
The source files compile successfully, however when it reached unit tests (written in Spock), it fails with the below error.
Caused by: java.lang.UnsupportedClassVersionError: org/model/SDA : Unsupported major.minor version 52.0
I confirmed that SDA.class is compiled using JDK 8.
javap -verbose SDA.class | findstr "major"
major version: 52
Any reason why only during unit tests I get the above error? Does that mean unit test is being run on JDK 7?
So if you're really into hacks there is something you can do. It does involve overriding some of the Gradle internals - so it may not work on any version of Gradle other than 1.11. There may also be unexpected side-effects.
import org.gradle.internal.Factory
import org.gradle.process.internal.WorkerProcessBuilder
import org.gradle.api.internal.tasks.compile.daemon.CompilerDaemonStarter
tasks.withType(GroovyCompile) {
options.fork = true
options.forkOptions.executable = "${System.env.JAVA8_HOME}/bin/javac"
doFirst {
def compilerFactory = compiler.compiler.compilerFactory
def clientsManager = compilerFactory.compilerDaemonManager.clientsManager
def oldDaemonStarter = clientsManager.compilerDaemonStarter
if (!(oldDaemonStarter.workerFactory instanceof CustomWorkerProcessFactory)) {
println "HACK, installing custom daemon worker"
clientsManager.compilerDaemonStarter = new CompilerDaemonStarter(
new CustomWorkerProcessFactory(oldDaemonStarter.workerFactory),
oldDaemonStarter.startParameter)
}
}
}
class CustomWorkerProcessFactory implements Factory<WorkerProcessBuilder> {
Factory<WorkerProcessBuilder> delegate
CustomWorkerProcessFactory(Factory<WorkerProcessBuilder> delegate) {
this.delegate = delegate
}
public WorkerProcessBuilder create() {
def newWorker = delegate.create()
newWorker.javaCommand.executable("${System.env.JAVA8_HOME}/bin/java")
newWorker
}
}
Add this to your gradle.properties:
org.gradle.java.home=/path/to/java8
Or when you launch gradle, you can specify it as a jvm parameter:
gradle -Dorg.gradle.java.home=/path/to/java8 task1 task2
A similar question was asked here, but it was specific to .NET 3.5. Specifically, I'm looking for the following:
What is the correct way to determine which .NET Framework versions and service packs are installed?
Is there a list of registry keys that can be used?
Are there any dependencies between Framework versions?
The registry is the official way to detect if a specific version of the Framework is installed.
Which registry keys are needed change depending on the Framework version you are looking for:
Framework Version Registry Key
------------------------------------------------------------------------------------------
1.0 HKLM\Software\Microsoft\.NETFramework\Policy\v1.0\3705
1.1 HKLM\Software\Microsoft\NET Framework Setup\NDP\v1.1.4322\Install
2.0 HKLM\Software\Microsoft\NET Framework Setup\NDP\v2.0.50727\Install
3.0 HKLM\Software\Microsoft\NET Framework Setup\NDP\v3.0\Setup\InstallSuccess
3.5 HKLM\Software\Microsoft\NET Framework Setup\NDP\v3.5\Install
4.0 Client Profile HKLM\Software\Microsoft\NET Framework Setup\NDP\v4\Client\Install
4.0 Full Profile HKLM\Software\Microsoft\NET Framework Setup\NDP\v4\Full\Install
Generally you are looking for:
"Install"=dword:00000001
except for .NET 1.0, where the value is a string (REG_SZ) rather than a number (REG_DWORD).
Determining the service pack level follows a similar pattern:
Framework Version Registry Key
------------------------------------------------------------------------------------------
1.0 HKLM\Software\Microsoft\Active Setup\Installed Components\{78705f0d-e8db-4b2d-8193-982bdda15ecd}\Version
1.0[1] HKLM\Software\Microsoft\Active Setup\Installed Components\{FDC11A6F-17D1-48f9-9EA3-9051954BAA24}\Version
1.1 HKLM\Software\Microsoft\NET Framework Setup\NDP\v1.1.4322\SP
2.0 HKLM\Software\Microsoft\NET Framework Setup\NDP\v2.0.50727\SP
3.0 HKLM\Software\Microsoft\NET Framework Setup\NDP\v3.0\SP
3.5 HKLM\Software\Microsoft\NET Framework Setup\NDP\v3.5\SP
4.0 Client Profile HKLM\Software\Microsoft\NET Framework Setup\NDP\v4\Client\Servicing
4.0 Full Profile HKLM\Software\Microsoft\NET Framework Setup\NDP\v4\Full\Servicing
[1] Windows Media Center or Windows XP Tablet Edition
As you can see, determining the SP level for .NET 1.0 changes if you are running on Windows Media Center or Windows XP Tablet Edition. Again, .NET 1.0 uses a string value while all of the others use a DWORD.
For .NET 1.0 the string value at either of these keys has a format of #,#,####,#. The last # is the Service Pack level.
While I didn't explicitly ask for this, if you want to know the exact version number of the Framework you would use these registry keys:
Framework Version Registry Key
------------------------------------------------------------------------------------------
1.0 HKLM\Software\Microsoft\Active Setup\Installed Components\{78705f0d-e8db-4b2d-8193-982bdda15ecd}\Version
1.0[1] HKLM\Software\Microsoft\Active Setup\Installed Components\{FDC11A6F-17D1-48f9-9EA3-9051954BAA24}\Version
1.1 HKLM\Software\Microsoft\NET Framework Setup\NDP\v1.1.4322
2.0[2] HKLM\Software\Microsoft\NET Framework Setup\NDP\v2.0.50727\Version
2.0[3] HKLM\Software\Microsoft\NET Framework Setup\NDP\v2.0.50727\Increment
3.0 HKLM\Software\Microsoft\NET Framework Setup\NDP\v3.0\Version
3.5 HKLM\Software\Microsoft\NET Framework Setup\NDP\v3.5\Version
4.0 Client Profile HKLM\Software\Microsoft\NET Framework Setup\NDP\v4\Version
4.0 Full Profile HKLM\Software\Microsoft\NET Framework Setup\NDP\v4\Version
[1] Windows Media Center or Windows XP Tablet Edition
[2] .NET 2.0 SP1
[3] .NET 2.0 Original Release (RTM)
Again, .NET 1.0 uses a string value while all of the others use a DWORD.
Additional Notes
for .NET 1.0 the string value at either of these keys has a format of #,#,####,#. The #,#,#### portion of the string is the Framework version.
for .NET 1.1, we use the name of the registry key itself, which represents the version number.
Finally, if you look at dependencies, .NET 3.0 adds additional functionality to .NET 2.0 so both .NET 2.0 and .NET 3.0 must both evaulate as being installed to correctly say that .NET 3.0 is installed. Likewise, .NET 3.5 adds additional functionality to .NET 2.0 and .NET 3.0, so .NET 2.0, .NET 3.0, and .NET 3. should all evaluate to being installed to correctly say that .NET 3.5 is installed.
.NET 4.0 installs a new version of the CLR (CLR version 4.0) which can run side-by-side with CLR 2.0.
Update for .NET 4.5
There won't be a v4.5 key in the registry if .NET 4.5 is installed. Instead you have to check if the HKLM\Software\Microsoft\NET Framework Setup\NDP\v4\Full key contains a value called Release. If this value is present, .NET 4.5 is installed, otherwise it is not. More details can be found here and here.
There is an official Microsoft answer to this question at the following knowledge base article:
Article ID: 318785 - Last Review: November 7, 2008 - Revision: 20.1
How to determine which versions of the .NET Framework are installed and whether service packs have been applied
Unfortunately, it doesn't appear to work, because the mscorlib.dll version in the 2.0 directory has a 2.0 version, and there is no mscorlib.dll version in either the 3.0 or 3.5 directories even though 3.5 SP1 is installed ... why would the official Microsoft answer be so misinformed?
The Framework 4 beta installs to a differing registry key.
using System;
using System.Collections.ObjectModel;
using Microsoft.Win32;
class Program
{
static void Main(string[] args)
{
foreach(Version ver in InstalledDotNetVersions())
Console.WriteLine(ver);
Console.ReadKey();
}
public static Collection<Version> InstalledDotNetVersions()
{
Collection<Version> versions = new Collection<Version>();
RegistryKey NDPKey = Registry.LocalMachine.OpenSubKey(#"SOFTWARE\Microsoft\NET Framework Setup\NDP");
if (NDPKey != null)
{
string[] subkeys = NDPKey.GetSubKeyNames();
foreach (string subkey in subkeys)
{
GetDotNetVersion(NDPKey.OpenSubKey(subkey), subkey, versions);
GetDotNetVersion(NDPKey.OpenSubKey(subkey).OpenSubKey("Client"), subkey, versions);
GetDotNetVersion(NDPKey.OpenSubKey(subkey).OpenSubKey("Full"), subkey, versions);
}
}
return versions;
}
private static void GetDotNetVersion(RegistryKey parentKey, string subVersionName, Collection<Version> versions)
{
if (parentKey != null)
{
string installed = Convert.ToString(parentKey.GetValue("Install"));
if (installed == "1")
{
string version = Convert.ToString(parentKey.GetValue("Version"));
if (string.IsNullOrEmpty(version))
{
if (subVersionName.StartsWith("v"))
version = subVersionName.Substring(1);
else
version = subVersionName;
}
Version ver = new Version(version);
if (!versions.Contains(ver))
versions.Add(ver);
}
}
}
}
I wanted to detect for the presence of .NET version 4.5.2 installed on my system, and I found no better solution than ASoft .NET Version Detector.
Snapshot of this tool showing different .NET versions:
Enumerate the subkeys of HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup\NDP. Each subkey is a .NET version. It should have Install=1 value if it's present on the machine, an SP value that shows the service pack and an MSI=1 value if it was installed using an MSI. (.NET 2.0 on Windows Vista doesn't have the last one for example, as it is part of the OS.)
For a 64-bit OS, the path would be:
HKEY_LOCAL_MACHINE\SOFTWARE\wow6432Node\Microsoft\NET Framework Setup\NDP\
Update for .NET 4.5.1
Now that .NET 4.5.1 is available the actual value of the key named Release in the registry needs to be checked, not just its existence. A value of 378758 means that .NET Framework 4.5.1 is installed. However, as described here this value is 378675 on Windows 8.1.
There is a GUI tool available, ASoft .NET Version Detector, which has always proven highly reliable. It can create XML files by specifying the file name of the XML output on the command line.
You could use this for automation. It is a tiny program, written in a non-.NET dependent language and does not require installation.
I was needing to find out just which version of .NET framework I had on my computer, and all I did was go to the control panel and select the "Uninstall a Program" option. After that, I sorted the programs by name, and found Microsoft .NET Framework 4 Client Profile.
Here is a PowerShell script to obtain installed .NET framework versions
function Get-KeyPropertyValue($key, $property)
{
if($key.Property -contains $property)
{
Get-ItemProperty $key.PSPath -name $property | select -expand $property
}
}
function Get-VersionName($key)
{
$name = Get-KeyPropertyValue $key Version
$sp = Get-KeyPropertyValue $key SP
$install = Get-KeyPropertyValue $key Install
if($sp)
{
"$($_.PSChildName) $name SP $sp"
}
else{
"$($_.PSChildName) $name"
}
}
function Get-FrameworkVersion{
dir "hklm:\SOFTWARE\Microsoft\NET Framework Setup\NDP\" |? {$_.PSChildName -like "v*"} |%{
if( $_.Property -contains "Version")
{
Get-VersionName $_
}
else{
$parent = $_
Get-ChildItem $_.PSPath |%{
$versionName = Get-VersionName $_
"$($parent.PSChildName) $versionName"
}
}
}
}
$v4Directory = "hklm:\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full"
if(Test-Path $v4Directory)
{
$v4 = Get-Item $v4Directory
$version = Get-KeyPropertyValue $v4 Release
switch($version){
378389 {".NET Framework 4.5"; break;}
378675 {".NET Framework 4.5.1 installed with Windows 8.1 or Windows Server 2012 R2"; break;}
378758 {".NET Framework 4.5.1 installed on Windows 8, Windows 7 SP1, or Windows Vista SP2"; break;}
379893 {".NET Framework 4.5.2"; break;}
{ 393295, 393297 -contains $_} {".NET Framework 4.6"; break;}
{ 394254, 394271 -contains $_} {".NET Framework 4.6.1"; break;}
{ 394802, 394806 -contains $_} {".NET Framework 4.6.2"; break; }
}
}
It was written based on How to: Determine Which .NET Framework Versions Are Installed. Please use THE Get-FrameworkVersion() function to get information about installed .NET framework versions.
Using the Signum.Utilities library from SignumFramework (which you can use stand-alone), you can get it nicely and without dealing with the registry by yourself:
AboutTools.FrameworkVersions().ToConsole();
//Writes in my machine:
//v2.0.50727 SP2
//v3.0 SP2
//v3.5 SP1
See How to: Determine Which .NET Framework Versions Are Installed (MSDN).
MSDN proposes one function example that seems to do the job for version 1-4. According to the article, the method output is:
v2.0.50727 2.0.50727.4016 SP2
v3.0 3.0.30729.4037 SP2
v3.5 3.5.30729.01 SP1
v4
Client 4.0.30319
Full 4.0.30319
Note that for "versions 4.5 and later" there is another function.
In Windows 7 (it should work for Windows 8 also, but I haven't tested it):
Go to a command prompt
Steps to go to a command prompt:
Click Start Menu
In Search Box, type "cmd" (without quotes)
Open cmd.exe
In cmd, type this command
wmic /namespace:\\root\cimv2 path win32_product where "name like '%%.NET%%'" get version
This gives the latest version of NET Framework installed.
One can also try Raymond.cc Utilties for the same.
I am trying to use JMockit so that I can Mock out a final method in a 3rd party jar file.
When I tried a very simple test I got the the com.sun.tools.attach.AttachNotSupportedException and after some searching around I found here that this is caused by the IBM JDK6.0 not supporting the Attach feature, and then it was suggested that the fix was to put this in my VM args:
-javaagent:C:/jars/jmockit.jar
When I did this, and re-ran, I then get the below exception.
java.lang.NoSuchMethodError: org/junit/runner/Description.getAnnotation(Ljava/lang/Class;)Ljava/lang/annotation/Annotation;
at mockit.integration.junit4.internal.RunNotifierDecorator.fireTestRunStarted(RunNotifierDecorator.java:26)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:88)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
at java.lang.reflect.Method.invoke(Method.java:613)
at mockit.internal.util.MethodReflection.invokeWithCheckedThrows(MethodReflection.java:95)
at mockit.internal.annotations.MockMethodBridge.callMock(MockMethodBridge.java:76)
at mockit.internal.annotations.MockMethodBridge.invoke(MockMethodBridge.java:41)
at org.junit.runner.notification.RunNotifier.fireTestRunStarted(RunNotifier.java)
at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:48)
at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)
I am using JUnit4, and the JRE which comes with RAD8.5 for Websphere 8.5 development which is the IBM JRE6.0. Here are the exact JVM details:
C:\IBM\WebSphere\AppServer\java\jre\bin>.\java -version
java version "1.6.0"
Java(TM) SE Runtime Environment (build pwa6460_26sr3-20120810_01(SR3))
IBM J9 VM (build 2.6, JRE 1.6.0 Windows 7 amd64-64 20120809_118944 (JIT enabled, AOT enabled)
J9VM - R26_Java626_SR3_20120809_1152_B118944
JIT - r11.b01_20120808_24925
GC - R26_Java626_SR3_20120809_1152_B118944
J9CL - 20120809_118944)
JCL - 20120713_01
My code is a simple empty test and so far does not use any of the features of JMockit. Here it is:
public class TestJMockit {
#Test
public void testJMockit() {
boolean isTrue = true;
assertTrue(isTrue);
}
}
I am using version 1.2 of the jmockit.jar file which is the latest version at the time of writing this.
Does anyone know if it is possible at all to use JMockit on an IBM version of a JRE or is it simply impossible?
Has anyone else encountered this error before and know of a fix for it?