Apigee Java callout for XML Digital Signature Tests Failing

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 484
1 ACCEPTED SOLUTION

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

3 REPLIES 3

You need to build with java8

I have seen the error you cited when attempting to build with Java11.  I have never seen that error when building with Java8. 

Attached here is an example build log from this morning for the wssec callout.  It will work the same way for the xml dsig callout.  

Thanks. I tried to run maven build inside the Spring Tool Suite and it was failing with the above error.  But now, when i executed from command prompt , its failing with below error. 

Running TestSuite
Configuring TestNG with: org.apache.maven.surefire.testng.conf.TestNG652Configurator@d25a40
Exception: java.lang.IllegalStateException: source variable resolves to null
=========================================================
Exception: java.lang.IllegalStateException: private-key resolves to an empty string
=========================================================
=========================================================
=========================================================
=========================================================
=========================================================
Exception: java.lang.IllegalStateException: source variable resolves to null
=========================================================
Exception: java.lang.IllegalStateException: public-key resolves to an empty string
=========================================================
Exception: java.lang.IllegalStateException: Didn't find an RSA Public Key
expected error: Didn't find an RSA Public Key
=========================================================
=========================================================

 

 

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.