Getting Error in EntityManagerWrapper.getNonTxEMsFromCurrentInvocation(EntityManagerWrapper.java:276) - ejb

I am having my application deployed in EJBContainer in glassfish server. I am calling one method using Callable and future in session bean, and in this method i'm using EntityManager for some transaction but getting an NullPointerException for whenever any call to EntityManager is there. Below is the error stack trace::
Severe: java.lang.NullPointerException
at com.sun.enterprise.container.common.impl.EntityManagerWrapper.getNonTxEMsFromCurrentInvocation(EntityManagerWrapper.java:276)
at com.sun.enterprise.container.common.impl.EntityManagerWrapper.getNonTxEMFromCurrentInvocation(EntityManagerWrapper.java:260)
at com.sun.enterprise.container.common.impl.EntityManagerWrapper._getDelegate(EntityManagerWrapper.java:213)
at com.sun.enterprise.container.common.impl.EntityManagerWrapper.createQuery(EntityManagerWrapper.java:455)
at LogisticsEngineSessionBean.getAllPackSerialsForProcess(LogisticsEngineSessionBean.java:3137)
at LogisticsEngineSessionBean.processSalesOutLines(LogisticsEngineSessionBean.java:3462)
at LogisticsEngineSessionBean.lambda$updateSKULocationStatusOnSell$0(LogisticsEngineSessionBean.java:2972)
at LogisticsEngineSessionBean$$Lambda$7/1138463255.call(Unknown Source)
at java.util.concurrent.ForkJoinTask$AdaptedCallable.exec(ForkJoinTask.java:1424)
at java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:289)
at java.util.concurrent.ForkJoinPool$WorkQueue.runTask(ForkJoinPool.java:1056)
at java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1689)
at java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:157)
Please suggest whether it is because i'm trying to do multi threading or any alternate for this is available. I'm using EclipseLink JPA. This NullPointerException is not within my Code,it is coming in EntityManager which is working fine when i'm not doing MultiThreading. And EntityManager Object is not null, Please read the question properly before giving downvote.

Related

Kryo for JavaFX

In the past, I have successfully used Kryo in a swing application.
However, when I tried to upgrade to a JavaFX application, I could not even register a class.
This is true even for classes that were successfully registered in the Swing application.
The serializer I am using is Compatible Field Serializer, as I want to deal with scheme evolution. Is this a known issue? Is there a simple workaround?
Some of the error messages are below:
java.lang.reflect.InvocationTargetException
Caused by: java.lang.IllegalArgumentException
Caused by: java.lang.reflect
Caused by: java.lang.reflect.InaccessibleObjectException
Unable to make field private java.lang.String com.example.demo2.Person.gedId accessible:
module com.example.demo2 does not "opens com.example.demo2"
to module com.esotericsoftware.kryo.kryo5
Unable to create serializer "com.esotericsoftware.kryo.kryo5.serializers.CompatibleFieldSerializer" for class:

Object reference not set to an instance of an object. in asp.net with the try trans_rollback

Object reference not set to an instance of an object.
Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.
Exception Details: System.NullReferenceException: Object reference not set to an instance of an object.
Source Error:
public void Trans_Rollback()
{
trans.Rollback();
con.Close();
}
Looks like you disposed 'trans' or 'con' variable (or both) before calling 'TransRollback()'.
If you're using NHibernate, take a look to the querying part. If you use using statement with any of these variables you need to call your rollback method before statement parenthesis closes, since it means disposing object using were used with.
If that's not your case - provide more information, maybe at least framework you're using for accessing database. And context you calling your rollback method from.

Grails 3.3.10: running integration tests Error creating bean with name 'com.cabolabs.security.UserController'

I'm trying to create an integration test for a service and keep receiving a controller, that is totally disconnected from the service test, can't be created. Spending a day or so on everything that might cause the issue, and failing miserably, decided to create a project from scratch and start adding line by line.
So I did:
grails create-app test
grails create-domain-class com.cabolabs.security.User
added username and password String fields
grails generate-app com.cabolabs.security.User
grails create-service com.cabolabs.cloud.BalanceUpdate
grails create-integration-test com.cabolabs.cloud.BalanceUpdate
grails test-app com.cabolabs.cloud.BalanceUpdate -integration
That runs OK, the test fails because of the default code, that is not important.
Then I started to add references to services in the UserController, and the BalanceUpdateService, like mailService from the mail plugin.
The test worked as before.
Then I added this line, which I have extensively used in many controllers of my original project:
def config = grailsApplication.config
With that line, the whole thing felt apart and got the error:
org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'com.cabolabs.security.UserController': Instantiation of bean failed; nested exception is org.springframework.beans.BeanInstantiationException: Failed to instantiate [com.cabolabs.security.UserController]: Constructor threw exception; nested exception is java.lang.IllegalStateException: No thread-bound request found: Are you referring to request attributes outside of an actual web request, or processing a request outside of the originally receiving thread? If you are actually operating within a web request and still receive this message, your code is probably running outside of DispatcherServlet/DispatcherPortlet: In this case, use RequestContextListener or RequestContextFilter to expose the current request.
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.instantiateBean(AbstractAutowireCapableBeanFactory.java:1160)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBeanInstance(AbstractAutowireCapableBeanFactory.java:1104)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:511)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:481)
at org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:312)
at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:230)
at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:308)
at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:197)
at org.springframework.context.support.AbstractApplicationContext.getBean(AbstractApplicationContext.java:1080)
at org.spockframework.spring.SpringMockTestExecutionListener.beforeTestMethod(SpringMockTestExecutionListener.java:54)
at org.spockframework.spring.AbstractSpringTestExecutionListener.beforeTestMethod(AbstractSpringTestExecutionListener.java:23)
at org.springframework.test.context.TestContextManager.beforeTestMethod(TestContextManager.java:269)
at org.spockframework.spring.SpringTestContextManager.beforeTestMethod(SpringTestContextManager.java:54)
at org.spockframework.spring.SpringInterceptor.interceptSetupMethod(SpringInterceptor.java:45)
at org.spockframework.runtime.extension.AbstractMethodInterceptor.intercept(AbstractMethodInterceptor.java:28)
at org.spockframework.runtime.extension.MethodInvocation.proceed(MethodInvocation.java:87)
at org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:114)
at org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:57)
at org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:66)
at org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
at org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
at org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
at org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
at org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
at org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:109)
at org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
at org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
at org.gradle.internal.remote.internal.hub.MessageHubBackedObjectConnection$DispatchWrapper.dispatch(MessageHubBackedObjectConnection.java:147)
at org.gradle.internal.remote.internal.hub.MessageHubBackedObjectConnection$DispatchWrapper.dispatch(MessageHubBackedObjectConnection.java:129)
at org.gradle.internal.remote.internal.hub.MessageHub$Handler.run(MessageHub.java:404)
at org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:63)
at org.gradle.internal.concurrent.StoppableExecutorImpl$1.run(StoppableExecutorImpl.java:46)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
Caused by: org.springframework.beans.BeanInstantiationException: Failed to instantiate [com.cabolabs.security.UserController]: Constructor threw exception; nested exception is java.lang.IllegalStateException: No thread-bound request found: Are you referring to request attributes outside of an actual web request, or processing a request outside of the originally receiving thread? If you are actually operating within a web request and still receive this message, your code is probably running outside of DispatcherServlet/DispatcherPortlet: In this case, use RequestContextListener or RequestContextFilter to expose the current request.
at org.springframework.beans.BeanUtils.instantiateClass(BeanUtils.java:154)
at org.springframework.beans.factory.support.SimpleInstantiationStrategy.instantiate(SimpleInstantiationStrategy.java:89)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.instantiateBean(AbstractAutowireCapableBeanFactory.java:1152)
... 34 more
Caused by: java.lang.IllegalStateException: No thread-bound request found: Are you referring to request attributes outside of an actual web request, or processing a request outside of the originally receiving thread? If you are actually operating within a web request and still receive this message, your code is probably running outside of DispatcherServlet/DispatcherPortlet: In this case, use RequestContextListener or RequestContextFilter to expose the current request.
at org.springframework.web.context.request.RequestContextHolder.currentRequestAttributes(RequestContextHolder.java:131)
at grails.web.api.WebAttributes$Trait$Helper.currentRequestAttributes(WebAttributes.groovy:45)
at grails.web.api.WebAttributes$Trait$Helper.getGrailsAttributes(WebAttributes.groovy:54)
at grails.web.api.WebAttributes$Trait$Helper.getGrailsApplication(WebAttributes.groovy:134)
at org.springframework.beans.BeanUtils.instantiateClass(BeanUtils.java:142)
... 36 more
My question is, how can I have the config injected to my controllers and make the integration tests work? Thanks.
I just created a project from scratch and added line by line, it seems adding this to the controller, makes the test for the service fail (which are not connected in any way): def config = grailsApplication.config
Since I used that in many controllers, I tested changing it to Holders.config and that actually worked. I'll report this as a bug to Grails Core.

Kafka Listeners are getting active before spring boot application startup for Spring Kafka 2.2.3.RELEASE

We are using Spring-Kafka 2.2.3.RELEASE in our spring boot application (Spring Boot 2.1.2.RELEASE) and we have some kafka consumers defined in the application as,
#Component
#RefreshScope
#ConditionalOnProperty(prefix = "ord", value = "order-event.messaging.consumer.enabled", havingValue = "true")
public class OrderEventListener {
#KafkaListener(id = "orderEventListener", topics = "#{'${order.consumer.topic}'}")
public void consumeMessageEvent(OrderEvent messageEvent,ConsumerRecord<String, ?> record) {
// do some further processing.
}
}
Now lets jump to the question,
So when I start the application, so on application startup itself, it activates this consumer and tries to connect to broker but broker is not up and running in my system and after timeout, it throws the error
Error creating bean with name 'scopedTarget.orderEventListener'
and shows 'Application run failed' and terminate the process.
Why it requires broker to be up and running at the startup of the
application?
Previously we were using Spring Kafka 1.1.8.RELEASE, and it used to work without starting the broker and application used to start up normally.
Is that the expected behavior ? So the behavior got changed from version 1.1.8 to 2.2.3 ?
Additional Logs,
org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'scopedTarget.orderEventListener' Initialization of bean failed; nested exception is org.apache.kafka.common.errors.TimeoutException: Timeout expired while fetching topic metadata
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:584) ~[spring-beans-5.1.4.RELEASE.jar:5.1.4.RELEASE]
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:498) ~[spring-beans-5.1.4.RELEASE.jar:5.1.4.RELEASE]
at org.springframework.beans.factory.support.AbstractBeanFactory.lambda$doGetBean$1(AbstractBeanFactory.java:356) ~[spring-beans-5.1.4.RELEASE.jar:5.1.4.RELEASE]
at org.springframework.cloud.context.scope.GenericScope$BeanLifecycleWrapper.getBean(GenericScope.java:390) ~[spring-cloud-context-2.1.0.RELEASE.jar:2.1.0.RELEASE]
at org.springframework.cloud.context.scope.GenericScope.get(GenericScope.java:184) ~[spring-cloud-context-2.1.0.RELEASE.jar:2.1.0.RELEASE]
at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:353) ~[spring-beans-5.1.4.RELEASE.jar:5.1.4.RELEASE]
at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:199) ~[spring-beans-5.1.4.RELEASE.jar:5.1.4.RELEASE]
at org.springframework.context.support.AbstractApplicationContext.getBean(AbstractApplicationContext.java:1083) ~[spring-context-5.1.4.RELEASE.jar:5.1.4.RELEASE]
at org.springframework.cloud.context.scope.refresh.RefreshScope.eagerlyInitialize(RefreshScope.java:130) ~[spring-cloud-context-2.1.0.RELEASE.jar:2.1.0.RELEASE]
at org.springframework.cloud.context.scope.refresh.RefreshScope.start(RefreshScope.java:121) ~[spring-cloud-context-2.1.0.RELEASE.jar:2.1.0.RELEASE]
at org.springframework.cloud.context.scope.refresh.RefreshScope.onApplicationEvent(RefreshScope.java:115) ~[spring-cloud-context-2.1.0.RELEASE.jar:2.1.0.RELEASE]
at org.springframework.cloud.context.scope.refresh.RefreshScope.onApplicationEvent(RefreshScope.java:71) ~[spring-cloud-context-2.1.0.RELEASE.jar:2.1.0.RELEASE]
at org.springframework.context.event.SimpleApplicationEventMulticaster.doInvokeListener(SimpleApplicationEventMulticaster.java:172) ~[spring-context-5.1.4.RELEASE.jar:5.1.4.RELEASE]
at org.springframework.context.event.SimpleApplicationEventMulticaster.invokeListener(SimpleApplicationEventMulticaster.java:165) ~[spring-context-5.1.4.RELEASE.jar:5.1.4.RELEASE]
at org.springframework.context.event.SimpleApplicationEventMulticaster.multicastEvent(SimpleApplicationEventMulticaster.java:139) ~[spring-context-5.1.4.RELEASE.jar:5.1.4.RELEASE]
at org.springframework.context.support.AbstractApplicationContext.publishEvent(AbstractApplicationContext.java:398) ~[spring-context-5.1.4.RELEASE.jar:5.1.4.RELEASE]
at org.springframework.context.support.AbstractApplicationContext.publishEvent(AbstractApplicationContext.java:355) ~[spring-context-5.1.4.RELEASE.jar:5.1.4.RELEASE]
at org.springframework.context.support.AbstractApplicationContext.finishRefresh(AbstractApplicationContext.java:882) ~[spring-context-5.1.4.RELEASE.jar:5.1.4.RELEASE]
at org.springframework.boot.web.servlet.context.ServletWebServerApplicationContext.finishRefresh(ServletWebServerApplicationContext.java:163) ~[spring-boot-2.1.2.RELEASE.jar:2.1.2.RELEASE]
at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:549) ~[spring-context-5.1.4.RELEASE.jar:5.1.4.RELEASE]
at org.springframework.boot.web.servlet.context.ServletWebServerApplicationContext.refresh(ServletWebServerApplicationContext.java:142) ~[spring-boot-2.1.2.RELEASE.jar:2.1.2.RELEASE]
at org.springframework.boot.SpringApplication.refresh(SpringApplication.java:775) [spring-boot-2.1.2.RELEASE.jar:2.1.2.RELEASE]
at org.springframework.boot.SpringApplication.refreshContext(SpringApplication.java:397) [spring-boot-2.1.2.RELEASE.jar:2.1.2.RELEASE]
at org.springframework.boot.SpringApplication.run(SpringApplication.java:316) [spring-boot-2.1.2.RELEASE.jar:2.1.2.RELEASE]
at org.springframework.boot.SpringApplication.run(SpringApplication.java:1260) [spring-boot-2.1.2.RELEASE.jar:2.1.2.RELEASE]
at org.springframework.boot.SpringApplication.run(SpringApplication.java:1248) [spring-boot-2.1.2.RELEASE.jar:2.1.2.RELEASE]
at oal.oracle.apps.ic.coll.ordsbx.Application.main(Application.java:59) [classes/:?]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:1.8.0_161]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[?:1.8.0_161]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:1.8.0_161]
at java.lang.reflect.Method.invoke(Method.java:498) ~[?:1.8.0_161]
at org.springframework.boot.devtools.restart.RestartLauncher.run(RestartLauncher.java:49) [spring-boot-devtools-2.1.2.RELEASE.jar:2.1.2.RELEASE]
Caused by: org.apache.kafka.common.errors.TimeoutException: Timeout expired while fetching topic metadata
It is due to a change to the underlying kafka-clients library (since 2.0.0).
Previously, it would block forever, giving the application no control at all, which was unacceptable for many users.
Now, the operation will time out if the broker is not available.
I am not sure why it is failing during bean creation - it should only occur when the container is start()ed later in the application lifecycle. But I see you are using devtools so I am not sure it that is exacerbating the problem - edit the question to show the complete stack trace (you should never truncate stack traces here, since we can't see the complete story).
Normally, this can be avoided by setting autoStartup to false and then starting the container(s) yourself later, in a loop, waiting for the broker to exist.

EJB Timer IllegalArgumentException

I have an EJB3.0 timer which runs great.During application deployment i see this error in my WL logs,
An exception occurred while registering the MBean null.java.lang.IllegalArgumentException: Registered more than one instance with the same objectName : com.bea:ServerRuntime=admin,Name=weblogic.ejb.timer"
And during undeployment this
An unexpected error was encountered while attempting to remove any EJB Timers from the persistent store for the EJB 'TimerBean(Application: )
I don't use persistence store mechanism.I trigger the timer with servlet context.
We use WL 10.3.1,How can i overcome/catch this exception so,that it wouldn't be displayed during build process.
Thanks
The WLS ejb timers are persisted to a default store. The error messages seem to be related to it. Its likely that the ejb timer from a previous deployment is interfering. Does a server restart resolve this issue? You may want to try your app on WLS 10.3.4 to see if the issue has been resolved.

Resources