This website uses Cookies. Click Accept to agree to our website's cookie use as described in our Privacy Policy. Click Preferences to customize your cookie settings.
Accept
Reject
Preferences
Log in to ask a question
Get hands-on experience with 20+ free Google Cloud products and $300 in free credit for new customers.
Log in to ask a question

Apigee Java callout for XML Digital Signature Tests Failing

Posted on 02-09-2022 01:55 AM
rraghuna
Bronze 4
Bronze 4
Reply posted on --/--/---- --:-- AM

Hello ,

Went through the github GitHub - DinoChiesa/Apigee-Java-XMLDSIG: a Java callout for Apigee that computes or validates XML Di...

Even for the github code :

https://github.com/DinoChiesa/Apigee-Java-WsSec-Signature-2

Also maven tests are failing with the same error

The  maven tests are  not running.  looks like old :jmockit is being used. 

I Tried with Java 8 & 11 . Same error

Can someone update the code to work with Java 8 and above . So that things wont fai while running maven tests 

 

 

 T E S T S
-------------------------------------------------------
Running TestSuite
Configuring TestNG with: org.apache.maven.surefire.testng.conf.TestNG652Configurator@5cb9f472
java.lang.IllegalStateException: JMockit requires a Java 5+ VM
	at mockit.internal.startup.AgentInitialization.initializeAccordingToJDKVersion(AgentInitialization.java:31)
	at mockit.internal.startup.Startup.initializeIfPossible(Startup.java:239)
	at mockit.integration.testng.Initializer.<init>(Initializer.java:27)
	at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
	at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:77)
	at java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
	at java.base/java.lang.reflect.Constructor.newInstanceWithCaller(Constructor.java:499)
	at java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:480)
	at java.base/java.util.ServiceLoader$ProviderImpl.newInstance(ServiceLoader.java:789)
	at java.base/java.util.ServiceLoader$ProviderImpl.get(ServiceLoader.java:729)
	at java.base/java.util.ServiceLoader$3.next(ServiceLoader.java:1403)
	at org.testng.TestNG.addServiceLoaderListeners(TestNG.java:961)
	at org.testng.TestNG.initializeConfiguration(TestNG.java:896)
	at org.testng.TestNG.run(TestNG.java:1031)
	at org.apache.maven.surefire.testng.TestNGExecutor.run(TestNGExecutor.java:77)
	at org.apache.maven.surefire.testng.TestNGDirectoryTestSuite.executeMulti(TestNGDirectoryTestSuite.java:159)
	at org.apache.maven.surefire.testng.TestNGDirectoryTestSuite.execute(TestNGDirectoryTestSuite.java:99)
	at org.apache.maven.surefire.testng.TestNGProvider.invoke(TestNGProvider.java:106)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:568)
	at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
	at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
	at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
	at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115)
	at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75)
org.apache.maven.surefire.util.SurefireReflectionException: java.lang.reflect.InvocationTargetException; nested exception is java.lang.reflect.InvocationTargetException: null
java.lang.reflect.InvocationTargetException
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:568)
	at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
	at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
	at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
	at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115)
	at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75)
Caused by: java.util.ServiceConfigurationError: org.testng.ITestNGListener: Provider mockit.integration.testng.Initializer could not be instantiated
	at java.base/java.util.ServiceLoader.fail(ServiceLoader.java:586)
	at java.base/java.util.ServiceLoader$ProviderImpl.newInstance(ServiceLoader.java:813)
	at java.base/java.util.ServiceLoader$ProviderImpl.get(ServiceLoader.java:729)
	at java.base/java.util.ServiceLoader$3.next(ServiceLoader.java:1403)
	at org.testng.TestNG.addServiceLoaderListeners(TestNG.java:961)
	at org.testng.TestNG.initializeConfiguration(TestNG.java:896)
	at org.testng.TestNG.run(TestNG.java:1031)
	at org.apache.maven.surefire.testng.TestNGExecutor.run(TestNGExecutor.java:77)
	at org.apache.maven.surefire.testng.TestNGDirectoryTestSuite.executeMulti(TestNGDirectoryTestSuite.java:159)
	at org.apache.maven.surefire.testng.TestNGDirectoryTestSuite.execute(TestNGDirectoryTestSuite.java:99)
	at org.apache.maven.surefire.testng.TestNGProvider.invoke(TestNGProvider.java:106)
	... 9 more
Caused by: java.lang.IllegalStateException: JMockit requires a Java 5+ VM
	at mockit.internal.startup.AgentInitialization.initializeAccordingToJDKVersion(AgentInitialization.java:31)
	at mockit.internal.startup.Startup.initializeIfPossible(Startup.java:239)
	at mockit.integration.testng.Initializer.<init>(Initializer.java:27)
	at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
	at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:77)
	at java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
	at java.base/java.lang.reflect.Constructor.newInstanceWithCaller(Constructor.java:499)
	at java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:480)
	at java.base/java.util.ServiceLoader$ProviderImpl.newInstance(ServiceLoader.java:789)
	... 18 more

 

 

 

 

 

Solved Solved
0 3 657
Topic Labels
Jump to Solution
0 Likes
1 ACCEPTED SOLUTION

Posted on --/--/---- --:-- AM
dchiesa1
Staff
In response to rraghuna
Reply posted on --/--/---- --:-- AM

I'm not sure what you are showing me.  It looks like a filtered view of the actual test output. 

The tests within the source distribution for the WS-Sec callout as well as the XML DSIG callout include tests for a variety  of different  failure cases, in which the callout code throws exceptions.  This might be, missing arguments, invalid arguments, inconsistent arguments,  and so on.  One good example of this is "private-key resolves to an empty string".  For signing, the configuration of the callout must provide a private key.  One possible configuration error is that the configuration specifies a private-key property that points to a context variable that does not exist. There is a test that verifies that the callout handles this configuration error gracefully: it throws a fault (exception), and returns a reasonable, human readable string that explains the error. There are many other examples.

For diagnostic purposes, the test code may print out notice of the exceptions in those error cases. In some cases the test code prints out stack traces!  None of those things are indications of test failures. 

I guess you have a log scanner that is looking in the full test output for keywords like "Exception" and "error".  That's not going to give you an accurate assessment of the success or failure of the test run, with these callouts.  The tests for these callouts are not designed with the convention that the words "Exception" and "error" must never appear in the test log.  I advise you to look at the summary of the test run, which is at the bottom of the output. It will look something like this: 

 

...
[INFO] Tests run: 53, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 6.345 s - in TestSuite
[INFO] 
[INFO] Results:
[INFO] 
[INFO] Tests run: 53, Failures: 0, Errors: 0, Skipped: 0
[INFO] 
[INFO] 
[INFO] --- maven-dependency-plugin:2.8:copy-dependencies (copy-dependencies) @ apigee-wssecdsig ---
...
[INFO] 
[INFO] --- maven-jar-plugin:3.2.0:jar (default-jar) @ apigee-wssecdsig ---
[INFO] Building jar: /Users/dchiesa/dev/java/callouts/wssec-signature-2/callout/target/apigee-wssecdsig-20220204.jar
[INFO] 
[INFO] --- maven-antrun-plugin:1.3:run (ant2) @ apigee-wssecdsig ---
[INFO] Executing tasks
     [copy] Copying 1 file to /Users/dchiesa/dev/java/callouts/wssec-signature-2/bundle/apiproxy/resources/java
[INFO] Executed tasks
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  15.479 s
[INFO] Finished at: 2022-02-09T06:47:45-08:00
[INFO] ------------------------------------------------------------------------

 

You can see the summary line that tells you how many tests have run, how many have failed, how many were skipped, etc.  

For a successful build and test run, you will see 0 failures, 0 errors, 0 skipped, and a non-zero number of tests run.  In this case it's over 50 test cases. That's indicates a successful run, even though there might have been exceptions logged during the test run.   

 

View solution in original post

Jump to Solution
3 REPLIES 3
Top Solution Authors
View all