[JBoss JIRA] (WFLY-3386) Nullpointer exception on AbstractSessionBeanStore.getLockStore from within Activiti CDI
by Andries Ehlers (JIRA)
[ https://issues.jboss.org/browse/WFLY-3386?page=com.atlassian.jira.plugin.... ]
Andries Ehlers edited comment on WFLY-3386 at 5/26/14 2:52 PM:
---------------------------------------------------------------
Stuart/Jozef,
Not sure if the following will help or just re-affirm your above conclusions. Regarding the stacktrace: The next line in the stacktrace would be our would be our application code executing the startTask() method on the Activiti BusinessProcess class.
Our application uses a JAX-RS resource as an entry-point, thus the only CDI scope present at that time is a RequestScope. We don't explicitly start a conversation scope or anything of the sorts.
Its a basic scenario of a JAX-RS resource with an injected Facade (stateless session bean). The session bean calls startTask() on an injected BusinessProcess instance.
If you refer to the Javadoc of BusinessProcess.java (see link below), you'll notice the following comment "...in the absence of a conversation, (non faces request, i.e. when processing a JAX-RS, JAX-WS, JMS, remote EJB or plain Servlet requests), the {@link BusinessProcess} bean associates with the current Request (see {@link RequestScoped @RequestScoped})....."
This is our scenario.
Link: http://svn.codehaus.org/activiti/activiti/trunk/modules/activiti-cdi/src/...
Hope this helps.
was (Author: andriese):
Stuart/Jozef,
Not sure if the following will help or just re-affirm your above conclusions. Regarding the stacktrace: The next line in the stacktrace would be our would be our application code executing the startTask() method on the Activiti BusinessProcess class.
Our application uses a JAX-RS as an entry-point, thus the only CDI scope present at that time is a RequestScope. We don't explicitly start a conversation scope or anything of the sorts.
Its a basic scenario of a JAX-RS resource with an injected Facade (stateless session bean). The session bean calls startTask() on an injected BusinessProcess instance.
If you refer to the Javadoc of BusinessProcess.java (see link below), you'll notice the following comment "...in the absence of a conversation, (non faces request, i.e. when processing a JAX-RS, JAX-WS, JMS, remote EJB or plain Servlet requests), the {@link BusinessProcess} bean associates with the current Request (see {@link RequestScoped @RequestScoped})....."
This is our scenario.
Link: http://svn.codehaus.org/activiti/activiti/trunk/modules/activiti-cdi/src/...
Hope this helps.
> Nullpointer exception on AbstractSessionBeanStore.getLockStore from within Activiti CDI
> ---------------------------------------------------------------------------------------
>
> Key: WFLY-3386
> URL: https://issues.jboss.org/browse/WFLY-3386
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: CDI / Weld
> Affects Versions: 8.0.0.Final
> Environment: CentOS, Mac (Mountain Lion).
> Reporter: Andries Ehlers
> Assignee: Jozef Hartinger
>
> Background:
> The actual exception seems to be very close the one in issue: WFLY-3001 but we are not using JSF at all, but Activiti CDI.
> Not sure if this is a Wildfly or Activiti issue - it could very well be that there is a bug in Activiti with how it manages the CDI scopes. Unfortunately we're at a loss and seeing that the nullpointer is thrown from within a weld AbstractSessionBeanStore, I decided to post it here. Please advise.
> Error:
> We use Activiti CDI within Wildfly 8.0.0.Final. We randomly encounter an issue (sometimes immediately after a redeploy, other times after a few hours of inactivity on the server) the following issue. When Activiti attempts to retrieve the ContextBeanInstance from its ConversationScopedAssociationProxy, a NullPointer exception is thrown while attempting to retrieve the lock store within Weld (see below).
> -----------------------------
> 2014-05-21 10:05:34,430 INFO [stdout] (default task-12) java.lang.NullPointerException: null
> 2014-05-21 10:05:34,430 INFO [stdout] (default task-12) at org.jboss.weld.context.beanstore.http.AbstractSessionBeanStore.getLockStore(AbstractSessionBeanStore.java:113) ~[weld-core-impl-2.1.2.Final.jar!/:2014-01-09 09:23]
> 2014-05-21 10:05:34,430 INFO [stdout] (default task-12) at org.jboss.weld.context.beanstore.AttributeBeanStore.lock(AttributeBeanStore.java:210) ~[weld-core-impl-2.1.2.Final.jar!/:2014-01-09 09:23]
> 2014-05-21 10:05:34,430 INFO [stdout] (default task-12) at org.jboss.weld.context.AbstractContext.get(AbstractContext.java:90) ~[weld-core-impl-2.1.2.Final.jar!/:2014-01-09 09:23]
> 2014-05-21 10:05:34,431 INFO [stdout] (default task-12) at org.jboss.weld.context.PassivatingContextWrapper$AbstractPassivatingContextWrapper.get(PassivatingContextWrapper.java:76) ~[weld-core-impl-2.1.2.Final.jar!/:2014-01-09 09:23]
> 2014-05-21 10:05:34,431 INFO [stdout] (default task-12) at org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:98) ~[weld-core-impl-2.1.2.Final.jar!/:2014-01-09 09:23]
> 2014-05-21 10:05:34,431 INFO [stdout] (default task-12) at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:78) ~[weld-core-impl-2.1.2.Final.jar!/:2014-01-09 09:23]
> 2014-05-21 10:05:34,431 INFO [stdout] (default task-12) at org.activiti.cdi.impl.context.DefaultContextAssociationManager$ConversationScopedAssociation$Proxy$_$$_WeldClientProxy.getTask(Unknown Source) ~[activiti-cdi-5.15.jar:na]
> 2014-05-21 10:05:34,431 INFO [stdout] (default task-12) at org.activiti.cdi.impl.context.DefaultContextAssociationManager.getTask(DefaultContextAssociationManager.java:237) ~[activiti-cdi-5.15.jar:na]
> 2014-05-21 10:05:34,432 INFO [stdout] (default task-12) at org.activiti.cdi.BusinessProcess.startTask(BusinessProcess.java:332) ~[activiti-cdi-5.15.jar:na]
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
12 years, 1 month
[JBoss JIRA] (WFLY-3386) Nullpointer exception on AbstractSessionBeanStore.getLockStore from within Activiti CDI
by Andries Ehlers (JIRA)
[ https://issues.jboss.org/browse/WFLY-3386?page=com.atlassian.jira.plugin.... ]
Andries Ehlers commented on WFLY-3386:
--------------------------------------
Stuart/Jozef,
Not sure if the following will help or just re-affirm your above conclusions. Regarding the stacktrace: The next line in the stacktrace would be our would be our application code executing the startTask() method on the Activiti BusinessProcess class.
Our application uses a JAX-RS as an entry-point, thus the only CDI scope present at that time is a RequestScope. We don't explicitly start a conversation scope or anything of the sorts.
Its a basic scenario of a JAX-RS resource with an injected Facade (stateless session bean). The session bean calls startTask() on an injected BusinessProcess instance.
If you refer to the Javadoc of BusinessProcess.java (see link below), you'll notice the following comment "...in the absence of a conversation, (non faces request, i.e. when processing a JAX-RS, JAX-WS, JMS, remote EJB or plain Servlet requests), the {@link BusinessProcess} bean associates with the current Request (see {@link RequestScoped @RequestScoped})....."
This is our scenario.
Link: http://svn.codehaus.org/activiti/activiti/trunk/modules/activiti-cdi/src/...
Hope this helps.
> Nullpointer exception on AbstractSessionBeanStore.getLockStore from within Activiti CDI
> ---------------------------------------------------------------------------------------
>
> Key: WFLY-3386
> URL: https://issues.jboss.org/browse/WFLY-3386
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: CDI / Weld
> Affects Versions: 8.0.0.Final
> Environment: CentOS, Mac (Mountain Lion).
> Reporter: Andries Ehlers
> Assignee: Jozef Hartinger
>
> Background:
> The actual exception seems to be very close the one in issue: WFLY-3001 but we are not using JSF at all, but Activiti CDI.
> Not sure if this is a Wildfly or Activiti issue - it could very well be that there is a bug in Activiti with how it manages the CDI scopes. Unfortunately we're at a loss and seeing that the nullpointer is thrown from within a weld AbstractSessionBeanStore, I decided to post it here. Please advise.
> Error:
> We use Activiti CDI within Wildfly 8.0.0.Final. We randomly encounter an issue (sometimes immediately after a redeploy, other times after a few hours of inactivity on the server) the following issue. When Activiti attempts to retrieve the ContextBeanInstance from its ConversationScopedAssociationProxy, a NullPointer exception is thrown while attempting to retrieve the lock store within Weld (see below).
> -----------------------------
> 2014-05-21 10:05:34,430 INFO [stdout] (default task-12) java.lang.NullPointerException: null
> 2014-05-21 10:05:34,430 INFO [stdout] (default task-12) at org.jboss.weld.context.beanstore.http.AbstractSessionBeanStore.getLockStore(AbstractSessionBeanStore.java:113) ~[weld-core-impl-2.1.2.Final.jar!/:2014-01-09 09:23]
> 2014-05-21 10:05:34,430 INFO [stdout] (default task-12) at org.jboss.weld.context.beanstore.AttributeBeanStore.lock(AttributeBeanStore.java:210) ~[weld-core-impl-2.1.2.Final.jar!/:2014-01-09 09:23]
> 2014-05-21 10:05:34,430 INFO [stdout] (default task-12) at org.jboss.weld.context.AbstractContext.get(AbstractContext.java:90) ~[weld-core-impl-2.1.2.Final.jar!/:2014-01-09 09:23]
> 2014-05-21 10:05:34,431 INFO [stdout] (default task-12) at org.jboss.weld.context.PassivatingContextWrapper$AbstractPassivatingContextWrapper.get(PassivatingContextWrapper.java:76) ~[weld-core-impl-2.1.2.Final.jar!/:2014-01-09 09:23]
> 2014-05-21 10:05:34,431 INFO [stdout] (default task-12) at org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:98) ~[weld-core-impl-2.1.2.Final.jar!/:2014-01-09 09:23]
> 2014-05-21 10:05:34,431 INFO [stdout] (default task-12) at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:78) ~[weld-core-impl-2.1.2.Final.jar!/:2014-01-09 09:23]
> 2014-05-21 10:05:34,431 INFO [stdout] (default task-12) at org.activiti.cdi.impl.context.DefaultContextAssociationManager$ConversationScopedAssociation$Proxy$_$$_WeldClientProxy.getTask(Unknown Source) ~[activiti-cdi-5.15.jar:na]
> 2014-05-21 10:05:34,431 INFO [stdout] (default task-12) at org.activiti.cdi.impl.context.DefaultContextAssociationManager.getTask(DefaultContextAssociationManager.java:237) ~[activiti-cdi-5.15.jar:na]
> 2014-05-21 10:05:34,432 INFO [stdout] (default task-12) at org.activiti.cdi.BusinessProcess.startTask(BusinessProcess.java:332) ~[activiti-cdi-5.15.jar:na]
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
12 years, 1 month
[JBoss JIRA] (WFLY-3386) Nullpointer exception on AbstractSessionBeanStore.getLockStore from within Activiti CDI
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-3386?page=com.atlassian.jira.plugin.... ]
Stuart Douglas reassigned WFLY-3386:
------------------------------------
Assignee: Jozef Hartinger (was: Stuart Douglas)
I think we should add an explicit null check and better error message for this case.
> Nullpointer exception on AbstractSessionBeanStore.getLockStore from within Activiti CDI
> ---------------------------------------------------------------------------------------
>
> Key: WFLY-3386
> URL: https://issues.jboss.org/browse/WFLY-3386
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: CDI / Weld
> Affects Versions: 8.0.0.Final
> Environment: CentOS, Mac (Mountain Lion).
> Reporter: Andries Ehlers
> Assignee: Jozef Hartinger
>
> Background:
> The actual exception seems to be very close the one in issue: WFLY-3001 but we are not using JSF at all, but Activiti CDI.
> Not sure if this is a Wildfly or Activiti issue - it could very well be that there is a bug in Activiti with how it manages the CDI scopes. Unfortunately we're at a loss and seeing that the nullpointer is thrown from within a weld AbstractSessionBeanStore, I decided to post it here. Please advise.
> Error:
> We use Activiti CDI within Wildfly 8.0.0.Final. We randomly encounter an issue (sometimes immediately after a redeploy, other times after a few hours of inactivity on the server) the following issue. When Activiti attempts to retrieve the ContextBeanInstance from its ConversationScopedAssociationProxy, a NullPointer exception is thrown while attempting to retrieve the lock store within Weld (see below).
> -----------------------------
> 2014-05-21 10:05:34,430 INFO [stdout] (default task-12) java.lang.NullPointerException: null
> 2014-05-21 10:05:34,430 INFO [stdout] (default task-12) at org.jboss.weld.context.beanstore.http.AbstractSessionBeanStore.getLockStore(AbstractSessionBeanStore.java:113) ~[weld-core-impl-2.1.2.Final.jar!/:2014-01-09 09:23]
> 2014-05-21 10:05:34,430 INFO [stdout] (default task-12) at org.jboss.weld.context.beanstore.AttributeBeanStore.lock(AttributeBeanStore.java:210) ~[weld-core-impl-2.1.2.Final.jar!/:2014-01-09 09:23]
> 2014-05-21 10:05:34,430 INFO [stdout] (default task-12) at org.jboss.weld.context.AbstractContext.get(AbstractContext.java:90) ~[weld-core-impl-2.1.2.Final.jar!/:2014-01-09 09:23]
> 2014-05-21 10:05:34,431 INFO [stdout] (default task-12) at org.jboss.weld.context.PassivatingContextWrapper$AbstractPassivatingContextWrapper.get(PassivatingContextWrapper.java:76) ~[weld-core-impl-2.1.2.Final.jar!/:2014-01-09 09:23]
> 2014-05-21 10:05:34,431 INFO [stdout] (default task-12) at org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:98) ~[weld-core-impl-2.1.2.Final.jar!/:2014-01-09 09:23]
> 2014-05-21 10:05:34,431 INFO [stdout] (default task-12) at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:78) ~[weld-core-impl-2.1.2.Final.jar!/:2014-01-09 09:23]
> 2014-05-21 10:05:34,431 INFO [stdout] (default task-12) at org.activiti.cdi.impl.context.DefaultContextAssociationManager$ConversationScopedAssociation$Proxy$_$$_WeldClientProxy.getTask(Unknown Source) ~[activiti-cdi-5.15.jar:na]
> 2014-05-21 10:05:34,431 INFO [stdout] (default task-12) at org.activiti.cdi.impl.context.DefaultContextAssociationManager.getTask(DefaultContextAssociationManager.java:237) ~[activiti-cdi-5.15.jar:na]
> 2014-05-21 10:05:34,432 INFO [stdout] (default task-12) at org.activiti.cdi.BusinessProcess.startTask(BusinessProcess.java:332) ~[activiti-cdi-5.15.jar:na]
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
12 years, 1 month
[JBoss JIRA] (WFLY-3386) Nullpointer exception on AbstractSessionBeanStore.getLockStore from within Activiti CDI
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-3386?page=com.atlassian.jira.plugin.... ]
Stuart Douglas commented on WFLY-3386:
--------------------------------------
Looking at this stack trace and the relevant code it kinda looks like Activiti is trying to use some kind of conversation scope from outside the scope of a web request, or possibly after the request has been committed? I can't say for sure as it does not include the full stack trace.
Weld could handle this case better, but it appears the root cause is Activiti trying to use the session when it is not available.
> Nullpointer exception on AbstractSessionBeanStore.getLockStore from within Activiti CDI
> ---------------------------------------------------------------------------------------
>
> Key: WFLY-3386
> URL: https://issues.jboss.org/browse/WFLY-3386
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: CDI / Weld
> Affects Versions: 8.0.0.Final
> Environment: CentOS, Mac (Mountain Lion).
> Reporter: Andries Ehlers
> Assignee: Stuart Douglas
>
> Background:
> The actual exception seems to be very close the one in issue: WFLY-3001 but we are not using JSF at all, but Activiti CDI.
> Not sure if this is a Wildfly or Activiti issue - it could very well be that there is a bug in Activiti with how it manages the CDI scopes. Unfortunately we're at a loss and seeing that the nullpointer is thrown from within a weld AbstractSessionBeanStore, I decided to post it here. Please advise.
> Error:
> We use Activiti CDI within Wildfly 8.0.0.Final. We randomly encounter an issue (sometimes immediately after a redeploy, other times after a few hours of inactivity on the server) the following issue. When Activiti attempts to retrieve the ContextBeanInstance from its ConversationScopedAssociationProxy, a NullPointer exception is thrown while attempting to retrieve the lock store within Weld (see below).
> -----------------------------
> 2014-05-21 10:05:34,430 INFO [stdout] (default task-12) java.lang.NullPointerException: null
> 2014-05-21 10:05:34,430 INFO [stdout] (default task-12) at org.jboss.weld.context.beanstore.http.AbstractSessionBeanStore.getLockStore(AbstractSessionBeanStore.java:113) ~[weld-core-impl-2.1.2.Final.jar!/:2014-01-09 09:23]
> 2014-05-21 10:05:34,430 INFO [stdout] (default task-12) at org.jboss.weld.context.beanstore.AttributeBeanStore.lock(AttributeBeanStore.java:210) ~[weld-core-impl-2.1.2.Final.jar!/:2014-01-09 09:23]
> 2014-05-21 10:05:34,430 INFO [stdout] (default task-12) at org.jboss.weld.context.AbstractContext.get(AbstractContext.java:90) ~[weld-core-impl-2.1.2.Final.jar!/:2014-01-09 09:23]
> 2014-05-21 10:05:34,431 INFO [stdout] (default task-12) at org.jboss.weld.context.PassivatingContextWrapper$AbstractPassivatingContextWrapper.get(PassivatingContextWrapper.java:76) ~[weld-core-impl-2.1.2.Final.jar!/:2014-01-09 09:23]
> 2014-05-21 10:05:34,431 INFO [stdout] (default task-12) at org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:98) ~[weld-core-impl-2.1.2.Final.jar!/:2014-01-09 09:23]
> 2014-05-21 10:05:34,431 INFO [stdout] (default task-12) at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:78) ~[weld-core-impl-2.1.2.Final.jar!/:2014-01-09 09:23]
> 2014-05-21 10:05:34,431 INFO [stdout] (default task-12) at org.activiti.cdi.impl.context.DefaultContextAssociationManager$ConversationScopedAssociation$Proxy$_$$_WeldClientProxy.getTask(Unknown Source) ~[activiti-cdi-5.15.jar:na]
> 2014-05-21 10:05:34,431 INFO [stdout] (default task-12) at org.activiti.cdi.impl.context.DefaultContextAssociationManager.getTask(DefaultContextAssociationManager.java:237) ~[activiti-cdi-5.15.jar:na]
> 2014-05-21 10:05:34,432 INFO [stdout] (default task-12) at org.activiti.cdi.BusinessProcess.startTask(BusinessProcess.java:332) ~[activiti-cdi-5.15.jar:na]
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
12 years, 1 month
[JBoss JIRA] (WFLY-3393) JSP 2 different tags called with same tag instance
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-3393?page=com.atlassian.jira.plugin.... ]
Stuart Douglas commented on WFLY-3393:
--------------------------------------
Do you have a reproducer of some kind for this issue?
> JSP 2 different tags called with same tag instance
> --------------------------------------------------
>
> Key: WFLY-3393
> URL: https://issues.jboss.org/browse/WFLY-3393
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Web (Undertow)
> Affects Versions: 8.1.0.CR2
> Reporter: roy mizrachi
> Assignee: Stuart Douglas
>
> When working with JSP tags on struts i can see that sometimes 2 diffrent tags with same type is called with the same instance.
> Example:
> JSP
> <jcv:text id="email" maxlength="255" property="valueObject.Email"/>
> <br>
> <jcv:text id="phone" maxlength="255" property="valueObject.Phone"/>
> TLD
> <tag>
> <name>text</name>
> <tagclass>tti.jcore.views.form.tag.JViewsTextTag</tagclass>
> ...
> </tag>
> I can see that the public int doStartTag() called for both with the same instance.
>
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
12 years, 1 month
[JBoss JIRA] (WFLY-3266) Exception are hidden by retry and end in a EJBCLIENT000032 Exception - the underlying client or server side cause is swallowed
by Wolf-Dieter Fink (JIRA)
[ https://issues.jboss.org/browse/WFLY-3266?page=com.atlassian.jira.plugin.... ]
Wolf-Dieter Fink commented on WFLY-3266:
----------------------------------------
Another issue is the client side serialization or client side check.
If one of the parameter is not Serializable this is complete hidden:
May 26, 2014 4:37:37 PM org.jboss.ejb.client.EJBInvocationHandler sendRequestWithPossibleRetries
DEBUG: Retrying invocation org.jboss.ejb.client.EJBClientInvocationContext@3e125554 which failed on node: redhat due to:
org.jboss.ejb.client.RequestSendFailedException: org.jboss.as.quickstarts.ejb.remote.stateless.InputPojo
at org.jboss.ejb.client.remoting.RemotingConnectionEJBReceiver.processInvocation(RemotingConnectionEJBReceiver.java:234)
at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:181)
at org.jboss.ejb.client.EJBObjectInterceptor.handleInvocation(EJBObjectInterceptor.java:58)
at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:183)
at org.jboss.ejb.client.EJBHomeInterceptor.handleInvocation(EJBHomeInterceptor.java:83)
at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:183)
at org.jboss.ejb.client.TransactionInterceptor.handleInvocation(TransactionInterceptor.java:42)
at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:183)
at org.jboss.ejb.client.ReceiverInterceptor.handleInvocation(ReceiverInterceptor.java:125)
at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:183)
at org.jboss.ejb.client.EJBInvocationHandler.sendRequestWithPossibleRetries(EJBInvocationHandler.java:253)
at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:198)
at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:181)
at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:144)
at com.sun.proxy.$Proxy0.test(Unknown Source)
at org.jboss.as.quickstarts.ejb.remote.client.RemoteEJBClient.invokeStatelessBean(RemoteEJBClient.java:63)
at org.jboss.as.quickstarts.ejb.remote.client.RemoteEJBClient.main(RemoteEJBClient.java:47)
Caused by: java.io.NotSerializableException: org.jboss.as.quickstarts.ejb.remote.stateless.InputPojo
at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:891)
at org.jboss.marshalling.AbstractObjectOutput.writeObject(AbstractObjectOutput.java:62)
at org.jboss.marshalling.AbstractMarshaller.writeObject(AbstractMarshaller.java:119)
at org.jboss.ejb.client.remoting.MethodInvocationMessageWriter.writeMessage(MethodInvocationMessageWriter.java:101)
at org.jboss.ejb.client.remoting.RemotingConnectionEJBReceiver.processInvocation(RemotingConnectionEJBReceiver.java:231)
... 16 more
Caused by: an exception which occurred:
in object org.jboss.as.quickstarts.ejb.remote.stateless.InputPojo@241f0670
If there is a check/customized serialization which failed, like the following class:
public class InputPojo implements Serializable {
private void writeObject(ObjectOutputStream out) throws IOException {
// test to ensure that this Exception is found as cause
throw new IllegalStateException("mandatory things missing - this is a test failure");
}
}
The Exception is:
Caused by: java.lang.IllegalStateException: String parameter 'value' not set
at org.jboss.as.quickstarts.ejb.remote.stateless.InputPojo.writeObject(InputPojo.java:45)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.jboss.marshalling.reflect.SerializableClass.callWriteObject(SerializableClass.java:180)
at org.jboss.marshalling.river.RiverMarshaller.doWriteSerializableObject(RiverMarshaller.java:1007)
at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:885)
at org.jboss.marshalling.AbstractObjectOutput.writeObject(AbstractObjectOutput.java:62)
at org.jboss.marshalling.AbstractMarshaller.writeObject(AbstractMarshaller.java:119)
at org.jboss.ejb.client.remoting.MethodInvocationMessageWriter.writeMessage(MethodInvocationMessageWriter.java:101)
at org.jboss.ejb.client.remoting.RemotingConnectionEJBReceiver.processInvocation(RemotingConnectionEJBReceiver.java:231)
> Exception are hidden by retry and end in a EJBCLIENT000032 Exception - the underlying client or server side cause is swallowed
> ------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-3266
> URL: https://issues.jboss.org/browse/WFLY-3266
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: EJB
> Affects Versions: 8.0.0.Final
> Reporter: Wolf-Dieter Fink
> Assignee: David Lloyd
> Priority: Critical
>
> In case of large parameter input for EJB invocations the ejb-client throw the Exception below.
> The underlying OutOfMemory is complete hidden, neither in the server.log nor in the ejb-client with TRACE a hint will be found.
> java.lang.IllegalStateException: EJBCLIENT000032: Cannot retry a request which hasn't previously been completed
> at org.jboss.ejb.client.EJBClientInvocationContext.retryRequest(EJBClientInvocationContext.java:200)
> at org.jboss.ejb.client.EJBInvocationHandler.sendRequestWithPossibleRetries(EJBInvocationHandler.java:256)
> at org.jboss.ejb.client.EJBInvocationHandler.sendRequestWithPossibleRetries(EJBInvocationHandler.java:265)
> at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:198)
> at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:181)
> at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:144)
> at com.sun.proxy.$Proxy6.uploadData(Unknown Source)
> at de.info.biene.konsens.TestServiceWithAPITest.testUploadData(TestServiceWithAPITest.java:81)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
> at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> 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:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> 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)
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
12 years, 1 month
[JBoss JIRA] (WFLY-3266) Exception are hidden by retry and end in a EJBCLIENT000032 Exception - the underlying client or server side cause is swallowed
by Wolf-Dieter Fink (JIRA)
[ https://issues.jboss.org/browse/WFLY-3266?page=com.atlassian.jira.plugin.... ]
Wolf-Dieter Fink updated WFLY-3266:
-----------------------------------
Summary: Exception are hidden by retry and end in a EJBCLIENT000032 Exception - the underlying client or server side cause is swallowed (was: If large parameters are given to an EJB method invocation the client show a EJBCLIENT000032 Exception - the OutOfMemoryError is swallowed by remote protocol)
> Exception are hidden by retry and end in a EJBCLIENT000032 Exception - the underlying client or server side cause is swallowed
> ------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-3266
> URL: https://issues.jboss.org/browse/WFLY-3266
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: EJB
> Affects Versions: 8.0.0.Final
> Reporter: Wolf-Dieter Fink
> Assignee: David Lloyd
> Priority: Critical
>
> In case of large parameter input for EJB invocations the ejb-client throw the Exception below.
> The underlying OutOfMemory is complete hidden, neither in the server.log nor in the ejb-client with TRACE a hint will be found.
> java.lang.IllegalStateException: EJBCLIENT000032: Cannot retry a request which hasn't previously been completed
> at org.jboss.ejb.client.EJBClientInvocationContext.retryRequest(EJBClientInvocationContext.java:200)
> at org.jboss.ejb.client.EJBInvocationHandler.sendRequestWithPossibleRetries(EJBInvocationHandler.java:256)
> at org.jboss.ejb.client.EJBInvocationHandler.sendRequestWithPossibleRetries(EJBInvocationHandler.java:265)
> at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:198)
> at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:181)
> at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:144)
> at com.sun.proxy.$Proxy6.uploadData(Unknown Source)
> at de.info.biene.konsens.TestServiceWithAPITest.testUploadData(TestServiceWithAPITest.java:81)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
> at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> 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:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> 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)
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
12 years, 1 month
[JBoss JIRA] (WFLY-1197) Port the legacy jmx-console to AS7
by Carolina Contiu (JIRA)
[ https://issues.jboss.org/browse/WFLY-1197?page=com.atlassian.jira.plugin.... ]
Carolina Contiu commented on WFLY-1197:
---------------------------------------
Is there any work around for this issue? I'm getting the 'JBAS019905: Should not get called' exception.
> Port the legacy jmx-console to AS7
> ----------------------------------
>
> Key: WFLY-1197
> URL: https://issues.jboss.org/browse/WFLY-1197
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: JMX
> Reporter: Dimitris Andreadis
> Assignee: Darran Lofthouse
> Labels: JMX, as7, jmx-console, management_security,, management_sso
> Attachments: jmx-console.war, jmx-console.war
>
>
> I've seen a few people asking for a port of the old jmx-console to AS7, for monitoring purposes, until equivalent functionality is available through the new GWT-based console.
> I've ported the old console in this branch:
> https://github.com/dandreadis/jboss-as/commits/jmx-console
> It only includes a new top-level directory 'jmx-console'. The directory is not build by default, and when you build it manually it does not alter the server configuration in any way, you need to manually copy the resulting target/jboss-as-jmx-console-VERSION.war to the server deployment directory (and rename it to jmx-console.war)
> If there is interest, it could be included in the AS7 distro in some top level 'legacy' directory so it is not deployed by default?
> The resulting .war is attached on this JIRA, in case someone wants to use it. It work just as well on AS 7.0.2 and the latest AS 7.1.x development branch.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
12 years, 1 month
[JBoss JIRA] (WFLY-3403) Upgrade to PicketBox 4.0.21.Beta4
by Peter Skopek (JIRA)
Peter Skopek created WFLY-3403:
----------------------------------
Summary: Upgrade to PicketBox 4.0.21.Beta4
Key: WFLY-3403
URL: https://issues.jboss.org/browse/WFLY-3403
Project: WildFly
Issue Type: Component Upgrade
Security Level: Public (Everyone can see)
Components: Security
Reporter: Peter Skopek
Assignee: Peter Skopek
Fix For: 9.0.0.Alpha1
Upgrade to new release of PicketBox.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
12 years, 1 month