I am trying easyMock test few classes / interface methods. Methods with parameters, trying to capture the parameter, but getting one or other error. If I manage to only record one expectation, it doesn't even capture anything in the parameter pipe, where if i use the following approach, I am getting error as follows the code.
#Test
public void testFireChannelInitializer() throws Exception
{
expect(c.pipeline()).andReturn(pipeline).times(1);
channelListener.fireChannelInitializer(EasyMock.capture(pipe), serverHandler);
EasyMock.replay(c, pipeline, channelListener);
initializer.initChannel(c);
verifyAll();
assertEquals(4, pipe.getValues().size());
assertTrue(pipe.getValues().get(0) instanceof LoggingHandler);
assertTrue(pipe.getValues().get(0) instanceof ObjectEncoder);
assertTrue(pipe.getValues().get(0) instanceof ObjectDecoder);
assertTrue(pipe.getValues().get(0) instanceof ServerHandler);
}
Results in Error
testFireChannelInitializer(com.obolus.generic.impl.DefaultChannelListenerTest)
Time elapsed: 3.812 sec <<< ERROR! java.lang.IllegalStateException: 2
matchers expected, 1 recorded. This exception usually occurs when
matchers are mixed with raw values when recording a method: foo(5,
eq(6)); // wrong You need to use no matcher at all or a matcher for
every single param: foo(eq(5), eq(6)); // right foo(5, 6); // also
right at
org.easymock.internal.ExpectedInvocation.createMissingMatchers(ExpectedInvocation.java:51)
at
org.easymock.internal.ExpectedInvocation.(ExpectedInvocation.java:40)
at org.easymock.internal.RecordState.invoke(RecordState.java:78) at
org.easymock.internal.MockInvocationHandler.invoke(MockInvocationHandler.java:40)
at
org.easymock.internal.ObjectMethodsFilter.invoke(ObjectMethodsFilter.java:94)
at
org.easymock.internal.ClassProxyFactory$MockMethodInterceptor.intercept(ClassProxyFactory.java:97)
at
com.obolus.generic.impl.DefaultChannelListener$$EnhancerByCGLIB$$2da02970.fireChannelInitializer()
at
com.obolus.generic.impl.DefaultChannelListenerTest.testFireChannelInitializer(DefaultChannelListenerTest.java:63)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483) at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263) at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231) at
org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60) at
org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229) at
org.junit.runners.ParentRunner.access$000(ParentRunner.java:50) at
org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222) at
org.junit.runners.ParentRunner.run(ParentRunner.java:300) at
org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:242)
at
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:137)
at
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483) 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)
Any idea whats wrong or How to use easy mock? No good documentation or examples around.
The easymock website has a user guide but they redid their website recently and the guide isn't as complete as it used to be.
I think your problem might be you have to do a capture AND an argument matcher.
From the user guide:
Matches any value but captures it in the Capture parameter for later access. You can do and(someMatcher(...), capture(c)) to capture a parameter from a specific call to the method. You can also specify a CaptureType telling that a given Capture should keep the first, the last, all or no captured values.
So you might need to do an and( capture(..), paramMatcher)
Also EasyMock has an annoying API "feature" where if you use one argument matcher in a method call, then all the arguments must also be wrapped in matchers even if it's eq(). I think that's what your exception is complaining about. So I think those are your two problems.
I'm not sure what your method signature looks like so I will assume it's
void fireChannelInitializer(Object, ServerHandler);
after using static imports to import EasyMock.*
channelListener.fireChannelInitializer(
and(capture(pipe), isA(Object.class)), //captures the argument to `pipe` Capture object
eq(serverHandler));
Related
I'm using Payara 5.184 and Java 1.8.241 on Linux (Ubuntu 19.10). I'm also using Liquibase as my database schema change management. A field named myDataSource is being injected as follows:
#Resource(mappedName = "java:global/ds")
private DataSource myDataSource;
When the method createDataSource() from Liquibase is invoked I noticed that the variable myDataSource is null, what makes me understand that the resource is not being properly injected. This error seems to happen only on Linux, as my other colleagues that run Windows did not have any problems so far. We're using exactly the same versions of Payara/Java. Is there any specific step that needs to be done on Linux? Here it is the stacktrace found on Payara logs.
Exception during lifecycle processing
org.glassfish.deployment.common.DeploymentException: CDI deployment failure:Exception List with 2 exceptions:
Exception 0 :
org.jboss.weld.exceptions.WeldException: WELD-000049: Unable to invoke public void liquibase.integration.cdi.CDILiquibase.onStartup() on liquibase.integration.cdi.CDILiquibase#911a89a
at org.jboss.weld.injection.producer.DefaultLifecycleCallbackInvoker.invokeMethods(DefaultLifecycleCallbackInvoker.java:85)
at org.jboss.weld.injection.producer.DefaultLifecycleCallbackInvoker.postConstruct(DefaultLifecycleCallbackInvoker.java:66)
at org.jboss.weld.injection.producer.BasicInjectionTarget.postConstruct(BasicInjectionTarget.java:122)
at liquibase.integration.cdi.CDIBootstrap$1.create(CDIBootstrap.java:95)
at liquibase.integration.cdi.CDIBootstrap$1.create(CDIBootstrap.java:38)
at org.jboss.weld.contexts.AbstractContext.get(AbstractContext.java:96)
at org.jboss.weld.bean.ContextualInstanceStrategy$DefaultContextualInstanceStrategy.get(ContextualInstanceStrategy.java:100)
at org.jboss.weld.bean.ContextualInstance.get(ContextualInstance.java:50)
at org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:102)
at org.jboss.weld.bean.proxy.ProxyMethodHandler.getInstance(ProxyMethodHandler.java:131)
at liquibase.integration.cdi.CDILiquibase$Proxy$_$$_WeldClientProxy.toString(Unknown Source)
at liquibase.integration.cdi.CDIBootstrap.afterDeploymentValidation(CDIBootstrap.java:111)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:95)
at org.jboss.weld.injection.MethodInvocationStrategy$SpecialParamPlusBeanManagerStrategy.invoke(MethodInvocationStrategy.java:144)
at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:330)
at org.jboss.weld.event.ExtensionObserverMethodImpl.sendEvent(ExtensionObserverMethodImpl.java:123)
at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:308)
at org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:286)
at javax.enterprise.inject.spi.ObserverMethod.notify(ObserverMethod.java:124)
at org.jboss.weld.util.Observers.notify(Observers.java:166)
at org.jboss.weld.event.ObserverNotifier.notifySyncObservers(ObserverNotifier.java:285)
at org.jboss.weld.event.ObserverNotifier.notify(ObserverNotifier.java:273)
at org.jboss.weld.event.ObserverNotifier.fireEvent(ObserverNotifier.java:177)
at org.jboss.weld.event.ObserverNotifier.fireEvent(ObserverNotifier.java:171)
at org.jboss.weld.bootstrap.events.AbstractContainerEvent.fire(AbstractContainerEvent.java:53)
at org.jboss.weld.bootstrap.events.AbstractDeploymentContainerEvent.fire(AbstractDeploymentContainerEvent.java:35)
at org.jboss.weld.bootstrap.events.AfterDeploymentValidationImpl.fire(AfterDeploymentValidationImpl.java:28)
at org.jboss.weld.bootstrap.WeldStartup.validateBeans(WeldStartup.java:499)
at org.jboss.weld.bootstrap.WeldBootstrap.validateBeans(WeldBootstrap.java:93)
at org.glassfish.weld.WeldDeployer.processApplicationLoaded(WeldDeployer.java:517)
at org.glassfish.weld.WeldDeployer.event(WeldDeployer.java:428)
at org.glassfish.kernel.event.EventsImpl.send(EventsImpl.java:131)
at org.glassfish.internal.data.ApplicationInfo.load(ApplicationInfo.java:333)
at com.sun.enterprise.v3.server.ApplicationLifecycle.prepare(ApplicationLifecycle.java:497)
at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:540)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:549)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:545)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:360)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:544)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$3.run(CommandRunnerImpl.java:575)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$3.run(CommandRunnerImpl.java:567)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:360)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:566)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1475)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1300(CommandRunnerImpl.java:111)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1857)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1733)
at com.sun.enterprise.v3.admin.AdminAdapter.doCommand(AdminAdapter.java:564)
at com.sun.enterprise.v3.admin.AdminAdapter.onMissingResource(AdminAdapter.java:251)
at org.glassfish.grizzly.http.server.StaticHttpHandlerBase.service(StaticHttpHandlerBase.java:166)
at com.sun.enterprise.v3.services.impl.ContainerMapper$HttpHandlerCallable.call(ContainerMapper.java:520)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:217)
at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:182)
at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:156)
at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:218)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:95)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:260)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:177)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:109)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:88)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:53)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:524)
at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:89)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:94)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:33)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:114)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:569)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:549)
at java.lang.Thread.run(Thread.java:748)
Caused by: java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.jboss.weld.injection.producer.DefaultLifecycleCallbackInvoker.invokeMethods(DefaultLifecycleCallbackInvoker.java:83)
... 74 more
Caused by: java.lang.NullPointerException
at liquibase.integration.cdi.CDILiquibase.performUpdate(CDILiquibase.java:126)
at liquibase.integration.cdi.CDILiquibase.onStartup(CDILiquibase.java:116)
... 79 more
EDIT: Added stacktrace
EDIT 2: Problem solved! It ended up being something not related with Liquibase at all. The queue size of the PayaraExecutorService was too small, which leads me to think that some tasks submissions were rejected. Apparently this is a known issue of Payara 5.184, and a related issue had already been opened on Github (https://github.com/payara/Payara/issues/3495). Once I increased the size of the queue to a large number everything started working as expected.
I think you need to use lookup to inject the resource.
Compare this bug report: https://github.com/payara/Payara/issues/4413
Currently refactoring some PySpark code and this specific snippet is causing me issues whereas it has ran fine before:
zip_table=spark.read.format("org.apache.spark.sql.execution.datasources.csv.CSVFileFormat").schema(schemas.zip_schema).load(path_to_file,header=True)
zip_pandas = zip_table.toPandas()
running into:
Py4JJavaError: An error occurred while calling o167.get.
: java.util.NoSuchElementException: spark.sql.execution.pandas.respectSessionTimeZone
at org.apache.spark.sql.internal.SQLConf$$anonfun$getConfString$2.apply(SQLConf.scala:1175)
at org.apache.spark.sql.internal.SQLConf$$anonfun$getConfString$2.apply(SQLConf.scala:1175)
at scala.Option.getOrElse(Option.scala:121)
at org.apache.spark.sql.internal.SQLConf.getConfString(SQLConf.scala:1175)
at org.apache.spark.sql.RuntimeConfig.get(RuntimeConfig.scala:74)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at py4j.reflection.MethodInvoker.invoke(MethodInvoker.java:244)
at py4j.reflection.ReflectionEngine.invoke(ReflectionEngine.java:357)
at py4j.Gateway.invoke(Gateway.java:280)
at py4j.commands.AbstractCommand.invokeMethod(AbstractCommand.java:132)
at py4j.commands.CallCommand.execute(CallCommand.java:79)
at py4j.GatewayConnection.run(GatewayConnection.java:214)
at java.lang.Thread.run(Thread.java:748)
Other Spark Dataframes are successfully able to call toPandas() while others such as this return the same error.
The file in question is not particularly big and should be able to fit in the driver no problem. Also, I know it may be better to just load it into Pandas directly and not convert from Spark, but there is further logic in the code that requires both Spark/Pandas dataframes (and a later re-architecture of this work will address this issue).
I'm using the default JSSE provider in Java 6 (SunJSSE) like so,
SSLContext sslCtx = SSLContext.getInstance("TLS");
Can I call the method sslCtx.createSSLEngine() safely from multiple threads?
Update 1:
The code that's calling createSSLEngine() in this manner is run on the server-side only. Basically, a thread calls this method for every client that connects to the server.
The call to SSLContext.createSSLEngine() seems to be thread-safe. At least based on the fact that the application has not failed with any race-condition-related error.
In trying to find a definitive answer, I downloaded the source code of OpenJDK6 b27 and took a look at it. I’m assuming, of course, that this is the same code that is inside Oracle’s JRE 6.
When SSLContext.createSSLEngine() is called, it in its turn calls the abstract method engineCreateSSLEngine() on whatever implementation it has of the javax.net.ssl.SSLContextSpi class. In this case the implementation is sun.security.ssl.SSLContextImpl. The implementation of the engineCreateSSLEngine() method provided by SSLContextImpl simply returns a new instance of sun.security.ssl.SSLEngineImpl by calling the SSLEngineImpl(SSLContextImpl ctx) constructor.
Inspecting the code, I couldn’t find anything that suggested a possible thread-unsafe operation.
I can also agree with Elliot concerning the thread-safeness of SSLContext.createSSLEngine() in OpenJDK8 (based on analysing the code and performing simple tests).
I added this answer, because there exist situations when you HAVE to re-use SSLContexts (if you do not like wrapper classes or cannot use synchronisation): When connecting to a Wildfly application server EJB using SSL encryption, the jboss-remoting EndpointImpl decides to open a new connection based on a ConnectionKey that contains the SSLContext instance. So if you always specify a new SSLContext for each EJB call, always a new connection is used. The sad thing is, that the connection is considered "shared", so it is not closed after the call (but never re-used, due to the differing ConnectionKeys). After some time, you will only get many of those:
Caused by: java.net.SocketException: No buffer space available
at sun.nio.ch.Net.socket0(Native Method) ~[?:1.8.0_91]
at sun.nio.ch.Net.socket(Net.java:411) ~[?:1.8.0_91]
at sun.nio.ch.Net.socket(Net.java:404) ~[?:1.8.0_91]
at sun.nio.ch.SocketChannelImpl.<init>(SocketChannelImpl.java:105) ~[?:1.8.0_91]
at sun.nio.ch.SelectorProviderImpl.openSocketChannel(SelectorProviderImpl.java:60) ~[?:1.8.0_91]
at java.nio.channels.SocketChannel.open(SocketChannel.java:145) ~[?:1.8.0_91]
at org.xnio.nio.WorkerThread.openTcpStreamConnection(WorkerThread.java:250) ~[xnio-nio-3.6.2.Final.jar:3.6.2.Final]
at org.xnio.XnioIoThread.internalOpenTcpStreamConnection(XnioIoThread.java:247) ~[xnio-api-3.6.2.Final.jar:3.6.2.Final]
at org.xnio.XnioIoThread.openStreamConnection(XnioIoThread.java:226) ~[xnio-api-3.6.2.Final.jar:3.6.2.Final]
at org.xnio.XnioWorker.openStreamConnection(XnioWorker.java:398) ~[xnio-api-3.6.2.Final.jar:3.6.2.Final]
at org.jboss.remoting3.remote.RemoteConnectionProvider.createSslConnection(RemoteConnectionProvider.java:246) ~[jboss-remoting-5.0.0.
at org.jboss.remoting3.remote.HttpUpgradeConnectionProvider.createSslConnection(HttpUpgradeConnectionProvider.java:136) ~[jboss-remot
at org.jboss.remoting3.remote.RemoteConnectionProvider.connect(RemoteConnectionProvider.java:206) ~[jboss-remoting-5.0.0.Final.jar:5.
at org.jboss.remoting3.EndpointImpl.lambda$connect$6(EndpointImpl.java:618) ~[jboss-remoting-5.0.0.Final.jar:5.0.0.Final]
at java.security.AccessController.doPrivileged(Native Method) ~[?:1.8.0_91]
at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:617) ~[jboss-remoting-5.0.0.Final.jar:5.0.0.Final]
at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:536) ~[jboss-remoting-5.0.0.Final.jar:5.0.0.Final]
at org.jboss.remoting3.ConnectionInfo$None.getConnection(ConnectionInfo.java:83) ~[jboss-remoting-5.0.0.Final.jar:5.0.0.Final]
at org.jboss.remoting3.ConnectionInfo.getConnection(ConnectionInfo.java:56) ~[jboss-remoting-5.0.0.Final.jar:5.0.0.Final]
at org.jboss.remoting3.EndpointImpl.doGetConnection(EndpointImpl.java:487) ~[jboss-remoting-5.0.0.Final.jar:5.0.0.Final]
at org.jboss.remoting3.EndpointImpl.getConnectedIdentity(EndpointImpl.java:433) ~[jboss-remoting-5.0.0.Final.jar:5.0.0.Final]
at org.jboss.remoting3.UncloseableEndpoint.getConnectedIdentity(UncloseableEndpoint.java:51) ~[jboss-remoting-5.0.0.Final.jar:5.0.0.F
at org.jboss.remoting3.Endpoint.getConnectedIdentity(Endpoint.java:122) ~[jboss-remoting-5.0.0.Final.jar:5.0.0.Final]
at org.jboss.ejb.protocol.remote.RemoteEJBReceiver.lambda$getConnection$2(RemoteEJBReceiver.java:185) ~[jboss-ejb-client-4.0.9.Final.
at java.security.AccessController.doPrivileged(Native Method) ~[?:1.8.0_91]
at org.jboss.ejb.protocol.remote.RemoteEJBReceiver.getConnection(RemoteEJBReceiver.java:185) ~[jboss-ejb-client-4.0.9.Final.jar:4.0.9
at org.jboss.ejb.protocol.remote.RemoteEJBReceiver.processInvocation(RemoteEJBReceiver.java:128) ~[jboss-ejb-client-4.0.9.Final.jar:4
at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:454) ~[jboss-ejb-client-4.0.9.Final.ja
Re-using a static SSLContext fixes this.
I know this question has been asked in various forms before, but I've checked all the answers and I think we've excluded them all.
Error:
java.lang.NoClassDefFoundError: com/lgc/infra/geometry/Coord1Val
at com.lgc.infra.geometry.Coords.coord(Coords.java:89)
at com.lgc.infra.geometry.Coords.<clinit>(Coords.java:24)
at com.geoteric.lfd.eos.ReallyBasicTest.make_a_simple_coord(ReallyBasicTest.java:17)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
at org.junit.runners.Suite.runChild(Suite.java:128)
at org.junit.runners.Suite.runChild(Suite.java:24)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
at org.junit.runner.JUnitCore.run(JUnitCore.java:157)
at com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:78)
at com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:212)
at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:68)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at com.intellij.rt.execution.application.AppMain.main(AppMain.java:140)
Caused by: java.lang.ClassNotFoundException: com.lgc.infra.geometry.Coord1Val
at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
... 37 more
Code:
package com.geoteric.lfd.eos;
import com.lgc.infra.geometry.Coord3;
import com.lgc.infra.geometry.Coords;
import org.junit.Test;
import static org.hamcrest.CoreMatchers.equalTo;
import static org.junit.Assert.assertThat;
/**
* Created by TClarke on 27/03/2015.
*/
public class ReallyBasicTest {
#Test
public void make_a_simple_coord()
{
Coord3 c3 = Coords.coord(1.0f, 2.0f, 3.0f);
assertThat(c3.getX(), equalTo(1.0));
}
}
Path to ClassFile:
D:\ffa_dev\link-for-decisionspace\ext\dssdk\com_lgc_dsp-core_sdk.jar!\com\lgc\infra\geometry\Coords.class
Screenshot of Module Structure:
Screenshot of Test Runner Config:
Related Code functions fine when built into real project. So, any advice on what I might have missed?
I think your .iml is not updated. Have you tried re creating your project/module .iml files. If its maven project you can recreate it by command
mvn idea:idea
After .iml is updated refresh the project and re run the test
This got upvoted, so I'll let you know what we eventually worked out.
We were writing a plugin using the API for another application. When you deploy the plugin, it gains access to all the definitions in the application. However, the unit tests are running in isolation, so the particular classes that are only defined through interfaces and factories cannot be built.
For this example:
Coord3 c3 = Coords.coord(1.0f, 2.0f, 3.0f);
Both Coord3 and Coords are defined. But com/lgc/infra/geometry/Coord1Val, which is used in Coords, is never actually defined in our library path (the API jar was clearly built with it there, but it wasn't supplied).
There are multiple potential workarounds, hopefully smart people stumbling upon this question will comment with some of them. The one we went with is to wrap Coords in a mockable factory that returns mock(Coord3.class), so that the parts that demonstrate this issue are encapsulated away.
I have some tests that recently failed with the following reason: No X11 DISPLAY variable was set, but this program performed an operation which requires it.
Here's the complete stack trace:
testGetDialog(simple.marauroa.application.core.IAddApplicationDialogProviderTest) Time elapsed: 112 sec <<< ERROR!
java.awt.HeadlessException:
No X11 DISPLAY variable was set, but this program performed an operation which requires it.
at java.awt.GraphicsEnvironment.checkHeadless(GraphicsEnvironment.java:159)
at java.awt.Window.<init>(Window.java:431)
at java.awt.Frame.<init>(Frame.java:403)
at java.awt.Frame.<init>(Frame.java:368)
at javax.swing.SwingUtilities$SharedOwnerFrame.<init>(SwingUtilities.java:1733)
at javax.swing.SwingUtilities.getSharedOwnerFrame(SwingUtilities.java:1810)
at javax.swing.JDialog.<init>(JDialog.java:253)
at javax.swing.JDialog.<init>(JDialog.java:187)
at javax.swing.JDialog.<init>(JDialog.java:135)
at simple.marauroa.application.core.IAddApplicationDialogProviderTest$IAddApplicationDialogProviderImpl.getDialog(IAddApplicationDialogProviderTest.java:97)
at simple.marauroa.application.core.IAddApplicationDialogProviderTest.testGetDialog(IAddApplicationDialogProviderTest.java:49)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30)
at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252)
at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141)
at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
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)
In the mentioned line of code is just this:
return new JDialog();
I guess is related to the Jenkins environment not having something enabled. How can this get fixed?
I can disable that test, but why should I?
You need to run your build inside a virtual (headless) graphical environment, using XVNC (or XVFB). See wiki.cloudbees.com/bin/view/DEV/Testing+GUI+applications.
Edit 20/01/2016:
The link above no longer takes you to a page with relevant information. This link shows the page as it was at the time: https://web.archive.org/web/20120717015714/http://wiki.cloudbees.com/bin/view/DEV/Testing+GUI+applications
You might also consider refactoring your code a bit to use a mock service so that tests do not need to load AWT. This will likely make tests faster and more reliable, as well as minimizing the chance that they will fail in novel environments such as a CI server.